Posts by moggern

    Eben noch ne die Berechnung der Prozentwerte für busy, idle, iowait und steal hinzugefügt.

    Vielleicht könnte man auch eine DB anlegen und die Auslastung über einen längeren Zeitpunkt tracken? Dann kann man wirklich über einen längeren Zeitraum sehen, wie es auf dem Host aussieht.


    Code
    1. [PHP] Error: Invalid argument supplied for foreach() at /var/www/vhosts/hosting123456.abcde.netcup.net/httpdocs/cloud/apps/serverinfo/lib/OperatingSystems/DefaultOs.php#120
    2. GET /settings/xxx/serverinfo
    3. from 79.140.aaa.bbb by xxx at 2020-04-09T13:27:11+02:00

    Seit ein paar Tagen kommt beim Aufruf der `nestcoud/settings/admin/serverinfo` Seite obiger Fehlermeldung. Blockt da netcup jetzt was?

    Die Statistik funktioniert jedoch nach wie vor.

    Wie kommst du zu deiner negativen Aussage?

    Offenbar interpretiere ich den Load-Wert falsch. Da die Nextcloud zu dem Zeitpunkt gerade unerträglich langsam war, passte das dazu.


    Ab welchem Wert wäre denn meine Annahme gerechtfertigt?

    Seit einiger Zeit habe ich neben ein paar Wollmilchsäuen ein Webhosting 8000, den größten Tarif in der Reihe. Dort läuft u.a. eine Nextcloud, die auch ein wenig Leistung benötigt.


    Beträgt in den Abend- und Nachtstunden die Last 1.4 bis 1.9, kann diese tagsüber schon mal im Bereich 4.5 bis 5 liegen.


    Wie sieht das bei euch aus?

    Kann man da was machen gegen "andere" Mitnutzer, die es übertreiben oder stopft netcup die Server einfach nur randvoll, egal welcher Tarif?

    Ich bin auf PHP 7.3.15 mit FastCGI über Apache. Mehr auswählen kann ich ohnehin nicht. innerhalb des 7.3er Zweigs.

    Ansonsten:


    Deaktiviere mal die intelligente Bearbeitung.

    Hat leider nichts gebracht.

    Wie siehts hier aus?

    Ich war schon bei PHP 7.3.15 und dort gibt es nur FastCGI. Ein Downgrade auf 7.2.28 und Umstellung auf FPM führte bei mir dazu:

    Wir betreiben eine Nextcloud, aktuell noch in v17.0.3 Im dortigen admin Menü werden folgender Fehler/Warnungen ausgeworfen:

    • Der „X-Content-Type-Options“-HTTP-Header ist nicht so konfiguriert, dass er „nosniff“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Der „X-Robots-Tag“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Der „X-Download-Options“-HTTP-Header ist nicht so konfiguriert, dass er „noopen“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Der „X-Permitted-Cross-Domain-Policies“-HTTP-Header ist nicht so konfiguriert, dass er „none“ entspricht. Dies ist ein potentielles Sicherheitsrisiko und es wird empfohlen, diese Einstellung zu ändern.
    • Es wurde kein PHP-Memory-Cache konfiguriert. Zur Erhöhung der Leistungsfähigkeit kann ein Memory-Cache konfiguriert werden. Weitere Informationen findest Du in der Dokumentation.
    • Der "Referrer-Policy" HTTP-Header ist nicht gesetzt auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin". Dadurch können Verweis-Informationen preisgegeben werden. Siehe die W3C-Empfehlung.

    Die Meldung mit dem PHP-Memory-Cache bekomme ich wohl aufgrund des Shared Hostings und den entsprechenden Voreinstellungen nicht weg. Was aber ist mit den anderen Meldungen? Die .htaccess hat gleich im zweiten Block u.a. das hier stehen:


    Wird die Datei ignoriert?


    HSTS läuft ja auch, wobei ich dieses in Plesk über die zusätzlichen Apache Header aktiviert habe:
    pasted-from-clipboard.png


    Für die anderen o.g. Fehler klappt das leider nicht :(


    Hat jemand eine Idee, wo ich noch etwas beeinflussen kann?

    Ich bin schon einen Schritt weiter. Die Tests aus dem lokalen Netz waren erfolgreich, da letztendlich die IP beider Geräte lokal erreichbar ist. Von draußen kennt er natürlich keine 192er Adressen.

    Habt ihr eine Idee wie ich das lösen kann?

    Das LAN wird über einen DynDNS-Namen aufgelöst.

    Ich habe mehrere Webhostings und möchte diese via Backup Manager auf einen lokalen FTP-Server sichern. Leider gibt es bei Eingabe der Zugangsdaten im Backup Manager immer eine Fehlermeldung:

    Quote

    Fehler: Unable to access to the storage: Transport error: unable to list directory: Curl error: (7) Couldn't connect to server: Last FTP request: PASV Last FTP response: 227 Entering Passive Mode (192,168,1,2,217,36)


    Make sure you have entered the correct storage settings. You can check them independently with the command:

    curl -v --ftp-pasv --ssl -k -u ftpuser 'ftp://subdomain.example.com/home/'pasted-from-clipboard.png


    Ich bekomme die Meldung sowohl wenn ich als Server ein Debian 8 mit proftpd verwenden, als auch bei einem Synology NAS mit integriertem FTP Server.

    Logge ich zum Testen via mc (midnight commander) oder Nautilus unter Linux ein klappt die Verbindung sofort.


    Habt ihr eine Idee woran das liegen könnte?

    Vielleicht kannst du im Webhostingpanel verschiedene PHP-Versionen ausprobieren.

    Ich werd verrückt! Das ist es!


    Ich habe von der PHV Version laut 7.2.19 auf "7.2" gewechselt und siehe da, alle Logins funktionieren!


    Vielen Dank an euch!


    Nun ist dort aber das Problem, dass in dieser Version der OpCache fehlt... Man kann es drehen und wenden wie man will. Irgendwas fehlt immer.

    (rsync mit -t)

    rsync geht leider nicht, da das in dem Webhosting 8000 Tarif nicht enthalten ist. Die Zeitstempel sind aber über das tar Archiv erhalten geblieben.

    Verwendest Du dieselbe PHP-Version am alten wie neuen Server?

    Fast: am Server war es 7.2.20, im Hosting ist es 7.2.19


    Bei der Datenbank gibt es noch einen kleinen Unterschied: Alt war es

    mysql Ver 15.1 Distrib 10.1.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

    im Hosting ist es

    mysql Ver 15.1 Distrib 10.0.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2


    Bei den kleinen Unterschieden kann ich mehr schwer vorstellen, dass diese verantwortlich sein sollen.

    Ich habe den Webhosting 8000 Tarif und versuche meine bisher lokal betriebene Nextcloud dort unterzubringen. Dazu habe ich auf dem Server die Cloud angehalten (maintenance mode), die Daten in ein Tar-Archiv gepackt, Nextcloud ebenso, einen MySQL-Dump gemacht und alles rüberkopiert und entsprechend entpackt.

    Leider funktionieren danach die User Passwörter nicht mehr. Setze ich ein Passwort über die Vergessen-Funktion zurück, klappt alles und ich komme in den Account. Das ist natürlich keine Option für die anderen Benutzer.


    Hat jemand eine Idee?