Beiträge von chrisiwien

  • RS 1000 Gen 8 - Loopback Request - curl error 28

    Hallo Steini! Uff, nein, ich habe auf Debian 9 und PHP 7.3 upgegraded - die neue Apache-Version erfreut auch.


    PHP 5.6 ist aber noch am Server "installiert", zur PHP-Ausführung wird aber definitiv der 7.3 FPM-Proxy verwendet.


    Demnach wäre die verbleibende Installation von PHP 5.6 ja nicht problematisch. Trotzdem: stellt die verbleibende Installation von PHP 5.6 ein Sicherheitsrisiko dar? Wie kann ich diese sicher entfernen? Gibt es da Abhängigkeiten die ich überprüfen sollte?


    Witzig ist, dass mit den apt-get updates/upgrades (deb https://packages.sury.org/php/ stretch main) jetzt schon ein Ornder (mit kaum was drin) für PHP 7.4 angelegt wurde.


    Jedenfalls danke für Deinen Zuspruch - das ist auch an alle anderen Poster gerichtet! Lösungswege teile ich gerne - da ich auch intensiv aus den Beiträgen anderer User lerne.

  • RS 1000 Gen 8 - Loopback Request - curl error 28

    Hm, ich habe an der "Von-Haus-Aus-Konfiguration" von netcup bislang wenig gegeändert, d.h. in meiner ports.conf ist "listen 80" zu finden. Wie gesagt habe ich den Loopback mit curl http://www.website-am-selben-server.com geprüft. Ob das ausreicht um den Loopback zu bestätigen weiß ich nicht.


    Mit selinux habe ich bislang keine Erfahrungen, ich muss mal andere Dinge in Punkto Server auf die Reihe bekommen...;-)


    Habe in einem anderen Forum gelesen dass bei den neuen Distributionen der Loopback schon vom Start weg aktiviert ist. Blöd wenn man dann Einstellungen vornimmt und versehentlich loopback-relevante unabsichtlich ändert, da fliegt man ev. drüber...

  • RS 1000 Gen 8 - Loopback Request - curl error 28

    Dieses Problem ist stark von der Konfiguration des jeweiligen Webservers abhängig, allgemein kann man leider wenig dazu sagen.


    In meinem Fall lag das Problem an der PHP-FPM-Konfiguration. Ich habe einen RS 2000 bei netcup gemietet.


    Als Verwaltungstool verwende ich das vorinstallierte Froxlor. Dort scheinen die PHP-FPM-Einstellungen unter "PHP-Konfigurationen" von Haus aus ungenügend zu sein:


    Standardeinstellungen:

    pm = static (Prozess Manager Control (PM))

    pm.max_children = 1 (Anzahl der Kind-Prozesse:)

    pm.max_requests = 0 (Requests pro Kindprozess bevor Neuerstellung (respawning))


    Ich habe mit dem curl error 28 (timeout) über Wochen verteilt gekämpft, auch mit unerwarteten "503 Service Unavailable"-Fehlern (die auch mit PHP-FPM zu tun hatten).


    Der Loopback war auf diesem Server von Haus aus aktiv. Getestet via curl http://www.website-am-gleichen-server.com. Der Befehl wird in der Shell problemlos ohne Timeout ausgeführt.


    Wenn ich allerdings (auch via dem Wordpress-Health-Check) den curl über Wordpress (und phpcurl) aufgerufen habe, kam der Timeout-Fehler.


    Nächster Schritt war, ein eigenes - unabhängig von Wordpress - curl-php-Loopback-Script aus dem Webspace heraus zu testen. Auch da kam der Timeout-Fehler, ich habe dann versuchsweise die Timout-Zeit erhöht.


    Aufmerksam geworden bin ich dann, als ich - während der curl auf die Beendingung der Timeout-Zeit gewartet hat - in einem anderen Tab auf der Website surfen wollte. Ging nicht - da eben nur ein PHP-FPM-Kind-Prozess erlaubt war - der mit dem curl-Request zu tun hatte. Erst als der curl-Request mit einem Timeout beendet wurde konnte ich wieder surfen. Daher kamen wohl auch die 503-Fehler (das werde ich aber noch weiter beobachten müssen).


    Meine neuen Einstellungen für PHP-FPM in froxlor:

    pm = static

    (scheint ok zu sein, siehe https://www.kinamo.be/en/suppo…sses-for-php-fpm-on-nginx und https://haydenjames.io/php-fpm…m-static-max-performance/)

    pm.max_children = 10 (Anzahl der Kind-Prozesse:)

    pm.max_requests = 200 (Requests pro Kindprozess bevor Neuerstellung (respawning))


    Der curl error 28 (timeout) ist sofort verschwunden, keine REST-API oder Loopback-Fehlermeldungen in WordPress, Dateien lassen sich wieder mit dem integrierten Editor bearbeiten und speichern (Fehlermeldung "Kommunikation mit der Website, um auf fatale Fehler zu prüfen, nicht möglich, daher wurde die PHP-Änderung rückgängig gemacht. Du wirst deine veränderte PHP-Datei mit anderen Mitteln hochladen müssen, wie per SFTP".


    Die neuen Werte für pm.max_children und pm.max_requests habe ich (noch) nicht anhand der Infos in den Links berechnet. Die Informationen in den Links zeigen ja auch, dass diese Werte u.U. im Betrieb laufend angepasst werden müssen.


    PHP-FPM ist eine Art Proxy, der mit dem Apache-Server zusammenarbeitet - das erfordert zusätzliche Konfigurationsarbeit. Nicht so wie bei mod_php, das als in Apache integriertes Modul arbeitet.