Beiträge von Madmin

    Mit einem eigenen dezentralen Protokoll (ZOT) und über Plugins diverse andere offene dezentrale Protokolle (ActivityPub, GNUsocial/Mastodon, Dispora).

    Aber dort kann man auch eine Identität auf andere Nodes klonen, und dort funktioniert Alles mit gleichen Einstellungen. Nur auf meinem Node hängt es irgendwie.


    Aber wenn das "normal" ist (andere Software läuft anstandslos auf https), dann wäre das wohl eine Sackgasse. Dezentrale Systeme sind halt schwer zu debuggen, weil die Ursache überall liegen kann...

    In Plesk zu allen Domains/Subdomains meines Webhostings steht bei "Lets Encrypt":

    Code
    "Lets Encrypt - Dieses Zertifikat wird nicht mehr für <domain> verwendet."

    Wenn ich auf "installieren" klicke, kommt zwar eine Bestätigung, dass das Zertifikat installiert wurde - Aber wenn ich wieder in Lets Encrypt reingehe, steht da immer noch diese Meldung. Hat die Subdomain jetzt ein gültiges SSL-Zertifikat oder nicht?


    Zwei Dienste funktionieren trotzdem mit https, aber mein Hubzilla Hub liefert Nachrichten nicht zuverlässig aus. Im Webhosting error.log steht regelmäßig:

    Code
    [<Zeitstempel>] [ssl:warn] [pid <####>] AH01909: hosting<######>.a2e<##>.netcup.net:443:0 server certificate does NOT include an ID which matches the server name

    Ich habe wohl inzwischen verstanden, dass das Zertifikat für die Default-Netcup-Platzhalter-Domain weder ein echtes Problem noch lösbar ist - Aber dadurch ist mir das oben aufgefallen.


    Daher versuche ich zu klären, ob überhaupt ein valides Zertifikat installiert ist.

    Hat jemand schon eine Hubzilla Instanz auf einem Webhosting (vielleicht sogar auch EiWoMiSau) zum Laufen bekommen?


    Mein Hub verbindet sich nicht richtig mit dem Hubzilla Netzwerk, vielleicht gibt es ja einen Trick, oder eine fehlende Hosting-Konfiguration. Für die Fehlersuche wäre es hilfreich zu wissen, ob oder wie Andere es geschafft haben.

    Welche Dateien aus dem Repo sind relevant, müssen ggf. angepasst oder mit Sym-Links wo/wohin flankiert werden, was muss/kann im Webserver/php eingestellt werden, was davon ist mir als Hosting-Kunde möglich und was davon muss der Support tun?

    OK, das ging schnell, danke an tab für die Antwort im anderen Thread zur minimalen Anwendung der Skripte von @killerbees19 (Ebenfalls danke!):


    1. WCP=>Domain=>PHP-Einstellungen: Include-Path angepasst von .:/usr/local/php74/share/php74 auf .:/usr/local/php74/bin (Hier verstehe ich allerdings noch nicht, ob das wirklich nötig ist)

    2. Nextcloud Webskript herunterladen und in das Verzeichnis der Domain oder Subdomain legen, Aufruf im Browser (Ich persönlich installiere ohne Unterverzeichnis in ., sonst halt in Nextcloud)3. data.config.php in .config

    (bzw. je nach Auswahl beim Setup in ./nextcloud/config) hochladen.

    4. Im Browser: Admin-User anlegen und DB konfigurieren.

    5. Ausführen in SSH: cd <Nextcloud dir> (also httpdocs, <Deine Domain oder Subdomain> oder noch mit "/Nextcloud" hintendran - das verzeichnis, in dem occ liegt). Dann: /usr/local/php74/bin/php occ db:add-missing-indices (geht durch das Skript)

    6. Fertig, eine Fehlermeldung in der Nextcloud Admin-Übersicht ist weg.


    Optional:

    7. gemäß KB19 's Screenshot: WCP => Domain bzw. Subdomain => Einstellungen für Apache & nginx:

    Zusätzliche Header von "Standard" auf "Eigenen Wert eingeben" ändern und "Strict-Transport-Security:max-age=155520000;IncludeSubDomains" eintragen.
    8. Fertig, zweite Fehlermeldung in der Nextcloud Admin-Übersicht ist weg.


    Bleiben noch Empfehlungen zu PHP-Memory-Cache und (zukünftig) Auslauf von MySQL-Version "5.7.30", aber wenn ich das richtig sehe, geht es um Leistungserhöhung und Zukunftsfähigkeit - läuft erstmal auch ohne - und ich selbst kann ich daran wenig ändern.


    EDIT: KB19 war schneller (und deutlich Zeichen-effizienter... ^^)

    Bei Fragen einfach hier posten

    Das nehm ich mal beim Wort...


    Ich habe wenig Linux-Erfahrung, bin kein php-Dev, und ich kriege es nicht hin, mit vertretbarem Aufwand selbst herauszufinden, was genau ich von alledem brauche, und was mir eher meine Konfiguration verkompliziert oder zerschießt. Also würde ich mich (wie vielleicht ein paar andere unbedarfte NC-Nutzer hier) für eine halbwegs Freizeit Bit-Jongleur-taugliche Anleitung für ein Webhosting (in meinem Fall EiWoMiSau) zu diesen tollen Lösungen freuen (Für die ich übrigens sehr dankbar bin):


    Welche Dateien aus dem Repo sind relevant, müssen ggf. angepasst oder mit Sym-Links wo/wohin flankiert werden, was muss/kann im Webserver/php eingestellt werden, was davon ist mir als Hosting-Kunde möglich und was davon muss der Support tun?


    Bitte nicht falsch verstehen, ich schätze das Alles sehr, aber ich sitze jetzt seit zwei Stunden vor diesem und anderen Thread und versuche, mir daraus ein Bild zu machen, aber es will sich nicht malen ^^ Bei meinem bisherigen Hoster habe ich das Skript ausgeführt und mich dann einfach über die Installation gefreut (ältere NC-Version, zugegeben). Ihr würdet mir wirklich sehr helfen!

    Achja: Die jetzt schon beim zweiten Netcup-Hosting-Paket offenbar standardmäßige Fehlkonfiguration (?) (Pfad zu PHP im Include_Path: ".:/usr/local/php74/share/php74") habe ich auch schon korrigiert (".:/usr/local/php74/bin") und getestet. Open_Dir ist auf {DOCROOT}. Das Problem bleibt.

    Hm... In der Lösung von killerbees19 ist auch dieser Pfad im Screenshot zu sehen... Wenn es bei ihm funktioniert, ist der wohl doch nicht das Problem.

    Vielleicht sollten die auch mal an das Installationsskript für neue Server ran. Ich würde es dem Support mrlfrn und gleich darauf hinweisen, dass du das jetzt schon bei mehreren Webhostings hattest, es also wohl ein systematisches Problem ist und kein Einzelfall. Vielleicht hilft es ja. Kann eigentlich nur im Interesse des Supports bzw netcup sein, wenn sie das nicht nachträglich für jeden Kunden korrigieren müssen.

    Den Eindruck habe ich auch - Mache ich gleich mal.

    Zitat

    Die Sache mit dem Data-Verzeichnis passiert einfach deswegen, weil der Pfad wegen chroot auf der Konsole anders ist als im Webprozess. Die Lösung von KB19 mit zusätzlicher Konfig-Datei habe ich ja im anderen Thread nochmal gepostet. Bei dir sucht die Nextcloud jetzt das Datenverzeichnis im in der config.php angegebenen Verzeichnis, wo es natürlich dank der Chroot-Umgebung nicht zu finden ist. (...) Nextcloud ist grundsätzlich eher auf Server zugeschnitten und schlägt sich mit solchen Kuriositäten wie Chroot nicht lange rum.

    Danke, das klingt nach der Zusammenfassung für ein Standard-Problem, die ich gesucht habe. Gesehen hatte ich es, mich aber ohne Aussage "Ja, muss so, ist richtig" ;) vor dem Rumbasteln an Code gedrückt (Hinterher sind das die Stellen, an denen man oder Dritte sich wundert, warum das System irgendwie anders als erwartet verhält...).


    Allerdings lief Nextcloud bei meinem Alt-Anbieter in chrooted Webspace völlig mucken-frei - Irgendwas ist hier also anders konfiguriert (für das Nextcloud dann sicher ein geeignetes Indikator-Programm ist :) ).

    Aus anderen Nextcloud-Themen konnte ich leider keine konkrete Lösung ableiten, von daher:

    Ich hatte bisher beim alten Provider eine Nextcloud auf Webhosting über eine externe Domain gut am Laufen (nichts Anspruchvolles, nur Familien-Orga - da geht das).


    Hier (EiWoMiSau) stoße ich mit gleicher Konfiguration bei Neuinstallation von NxCl 20 via Web-Skript auf Probleme. Weiß jemand etwas dazu? Das Problem müsste ja eigentlich bekannt sein, da ich ich sicher nicht der erste bei NC bin, der eine Nextcloud per Webinstaller-Skript auf ein Webhosting-Paket bringen möchte.


    Laut Admin-Übersicht fehlen Spalten in der DB; der dazu empfohlene SSH-occ-Korrektur-Aufruf läuft auch mit php73 nicht durch (Fatal Exception), und offenbar ist das (vorhandene!) Data-Verzeichnis nicht auffindbar ("///data" statt ordentlicher Server-Pfad) und ein /tmp Verzeichnis nicht eingereichtet. Das Skript sorgt ja eigentlich für passende Berechtigungen. Das Data Verzeichnis ist da, mein Hosting-User hat eigentlich alle erforderlichen Berechtigungen (an www-data komme ich ja wohl im Hosting nicht ran), aber offenbar "findet" der Webserver (der Defauit NGINX Proxy auf Apache) einfach den Pfad zum Verzeichnis nicht. Ich muss ihn aber auch nirgends eingeben. Irgendwas ist hier sehr faul, und ich wüsste gern was.


    Achja: Die jetzt schon beim zweiten Netcup-Hosting-Paket offenbar standardmäßige Fehlkonfiguration (?) (Pfad zu PHP im Include_Path: ".:/usr/local/php74/share/php74") habe ich auch schon korrigiert (".:/usr/local/php74/bin") und getestet. Open_Dir ist auf {DOCROOT}. Das Problem bleibt.


    Hat jemand einen Tipp?

    Ergänzung:

    Der Include Path war (offenbar seit Umstellung des Webservers auf php73?) etwas komisch:

    Code
    .:/usr/local/php73/share/php73

    statt

    Code
    .:/usr/local/php73/bin

    Korrigiert - Immerhin geht jetzt fasst alles ...


    ...außer URL rewrite. Habe mich mit der Doku befasst, aber mit {DOCROOT}/ müsste es ja passen.

    Die Hubzilla Doku fordert "no hosting provider restrictions on the use of exec() and proc_open()." Hatte ich mit dem Support vor Order eigentlich als OK geklärt, aber skeptisch in den php-Einstellungen macht mich:

    Code
    disable_functions <*>pcntl_exec<*>(Standard)

    /conf/phpversion ist geändert, und ich warte auf die nächste Stunde zum Reboot.

    Mit Angabe von /usr/local/php73/bin/php hat das Skript aber auch funktioniert - Danke!


    Ggf. muss hier von DocumentRoot auf WebspaceRoot umgestellt werden.

    Done - Die Fehlermeldungen bleiben leider unverändert.

    Aber unabhängig davon irritieren mich einige deiner angegebenen Pfade, denn z.B. /var/www/vhosts/<host>/<domain>/ klingt nicht nach einem typischen Netcup-Webhosting-Aufbau.

    Statt der dreickigen Klammern stehen in der nicht anonymisierten Original-Meldung natürlich der konkrete Host und meine Domain, falls Du das meintest. Und nein, keine Sorge, die Paranoia ist nur leicht überdurchschnittlich, noch nicht pathologisch... :D

    Hallo allerseits,


    ich bin neu bei netcup (erstmal nur mit Webhosting 1000 SE) und stoße bei der Installation meiner Dienste (v.A. Hubzilla) auf ein paar Probleme. Ich habe weder ein Webhosting noch PHP-Forum für den Betrieb gefunden, also wenn ich falsch poste, bitte einfach in's richtige Forum verschieben.


    1) Via SSH erhalte ich Beim Ausführen eines Skripts zur Installation von Erweiterungen die Fehlermeldung:

    Code
    "Fatal error: Array and string offset access syntax with curly braces is no longer supported in <file>.php on line <#>"

    Bash gibt php-Version 8 an, ich denke, das Skript wurde für max. 7.3 geschrieben. Wie kann ich die php-Version (Default für SSH, und Aufruf von Cronjobs) ändern? Ich kenne die Pfade nicht...


    2) Beim Aufruf der Installation (per Web-Adresse) meiner Software erhalte ich Fehlerhinweise zum Web-PHP-Zugriff und url rewrite:

    Code
    Warning: file_exists(): open_basedir restriction in effect. File(/usr/bin/php) is not within the allowed path(s): (/var/www/vhosts/<host>/<domain>/:/tmp/:/var/lib/php/sessions:/var/www/vhosts/<host>/tmp) in /var/www/vhosts/<host>/<domain>/Zotlabs/Module/Setup.php on line <#>
    Code
    PHP-Befehlszeile
    
        Konnte die Kommandozeilen-Version von PHP nicht im PATH des Web-Servers finden.
        Ohne Kommandozeilen-Version von PHP auf dem Server wirst Du nicht in der Lage sein, Hintergrundprozesse via cron auszuführen.
    
        PHP-Pfad zu ausführbarer Datei [/usr/bin/php]
        Gib den vollen Pfad zum PHP-Interpreter an. Du kannst dieses Feld frei lassen und mit der Installation fortfahren.
    Code
    Url rewrite funktioniert   [nein]     (required)
    
    Url rewrite in .htaccess is not working. Check your server configuration.Test: array ( 'return_code' => 0, 'success' => false, 'header' => '', 'body' => '', 'error' => 'SSL: certificate subject name \'Plesk\' does not match target host name \'<domain>\'', 'debug' => array ( 'url' => '<domain>/setup/testrewrite', 'content_type' => NULL, 'http_code' => 0, 'header_size' => 0, 'request_size' => 0, 'filetime' => -1, 'ssl_verify_result' => 1, 'redirect_count' => 0, 'total_time' => 0.011459, 'namelookup_time' => 2.0999999999999999E-5, 'connect_time' => 0.00027099999999999997, 'pretransfer_time' => 0.0, 'size_upload' => 0.0, 'size_download' => 0.0, 'speed_download' => 0.0, 'speed_upload' => 0.0, 'download_content_length' => -1.0, 'upload_content_length' => -1.0, 'starttransfer_time' => 0.0, 'redirect_time' => 0.0, 'redirect_url' => '', 'primary_ip' => '<IP6>', 'certinfo' => array ( ), 'primary_port' => 443, 'local_ip' => '<ip6>', 'local_port' => <port>, 'http_version' => 0, 'protocol' => 2, 'ssl_verifyresult' => 0, 'scheme' => 'HTTPS', ), 'request_target' => 'get /setup/testrewrite', )"

    Kommandozeilen-Zugriff auf PHP, restrictions und URL rewrite mod für lokale .htaccess hatte ich vor Order des Pakets explizit beim Service abgefragt und ein OK bekommen - Was mache ich wo falsch?


    3) Auf der Website wurden unter Details für 1000 SE "Cronjobs" (in der Mehrzahl) beworben - ohne dass irgendwelche Einschränkungen erwähnt würden. Im CCC wird unter Leistungen nur die Möglichkeit für einen einzigen Cronjob angezeigt - Welche Aussage stimmt denn nun?