RS 1000 Gen 8 - Loopback Request - curl error 28

  • Hallo in die Runde,


    ich dachte, dass ich mein kleines Problem selbst gelöst bekomme aber ich stehe auf dem Schlauch.


    Paypal Bezahlmöglichkeiten funktionieren auf meinem Server nicht. Es wird jedes mal abgebrochen. Zudem kommt der curl error 28 (timeout) Fehler.


    Mittels dem Wordpress Plugin "Health Check" habe ich festgestellt, das der Loopback Request nicht funktioniert.


    Und genau das ist mein Problem - ich bekomme es nicht ans "Laufen".


    Mit folgendes habe ich schon probiert:

    - alle Plugins deaktiviert

    - Alle security header deaktiviert

    - in php allow_url_fopen auf "On"

    - sämtliche Konfigs in der /etc/hosts

    - Änderung des DNS Servers (opendns)

    - verwendung von wp-cron.php aktiviert/deaktiviert (normal wird sie über einen cronjob ausgeführt)


    ..so langsam geht mir der Saft aus :/:wacko:

  • Aus Systemebene. Lediglich Fail2ban hört dort auf den SSH Port. In der Wordpress Installation ist NinjaFirewall aktiv.

  • 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.

  • Ich hatte das/(ein ähnliches?) Problem mal mit meinem Apache. Ursprünglich hat er auf "*" gelauscht, aber irgendwann bin ich umgestiegen und habe immer die feste IP direkt angegeben. Wieso ich das gemacht habe weiß ich nicht mehr (war halt schon immer so .. oO. Und da man nicht "mischen" kann, bleibts halt so). War auch nie ein Problem, bis ich eine Anwendung hatte, die das loopback interface gebraucht hat. Durch eine misratene Fehlermeldung habe ich ewig gebraucht um zu realisieren, dass der Apache nicht (mehr) auf loopback lauscht. Einfach alles explizit angeben (oder alle interfaces nehmen)

    Code
    Listen xx.xx.xx.xx:80
    Listen 127.0.0.1:80

    Kann sowas bei dir sein?


    Ansonsten scheint selinux bei manchen Konfigrationen dazwischen zu funken

  • 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...

  • es gibt immer änderungen!

    und ja leider auch schon hausintern, von anderen konfigurationen anderer Anbieter mal ganz zu schweigen.

    hausintern, da ich jetzt erst selbst 3 systeme hier installiert habe, beginnt es ja schon in der netzwerk cfg

    auf einem debian9 mit plesk sieht die config anderst aus als auf einem debian10 minimal (und ja beide scheinen ok)

    und wenn es hier schon unterschiedliche Lösungen gibt darf man sich über tiefere unterschiede nicht wundern

    jeder der einen Schreibfehler in meinem Post findet, darf ihn Kommentarlos behalten

    P.S. gilt auch für Schignaturen ;)

  • Sorry, ich habe verpeilt, dass bei dir ja jetzt alles läuft und du nur deinen Lösungsweg teilen wolltest. (Danke dafür!)

    Hm, ich habe an der "Von-Haus-Aus-Konfiguration" von netcup bislang wenig gegeändert,

    Das heißt, du hast noch das völlig veraltete Debain8 mit PHP5? Bevor du dich allzu tief einarbeitest und Lösungen für alte Probleme suchst, würde ich zu einem Upgrade raten (Wenn noch nicht viel läuft ist eine Neuinstallation die bessere Wahl)

  • 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.