Externer PHP Application Server mit PHP-FPM sowie mod_fcgid [Gelöst]

[jmar83]

Hallo zusammen

Es geht darum dass wir ein paar ältere Webserver am laufen habe bei denen PHP > v7.0 nicht mehr offiziell unterstützt wird. Nun habe ich erfahren, dass man über PHP-FPM sowie mod_fcgid die beiden Teile Webserver UND PHP-Engine aufsplitten kann - der PHP-Server wäre dann ein reiner Application Server und würde nicht mehr auf der gleichen Maschine/IP/OS laufen wie der Webserver.

ALLE (!!) Anleitungen schlagen fehl... das Ganze scheint praktisch betrachtet eher ein schlechter Witz zu sein - oder hat das schon mal jemand hingekriegt?

Ständig "File not Found" - es scheint irgendwie so zu sein, dass der Dateipfad vom Webserver an den PHP-FPM-App-Server weitergegeben wird und PHP-FPM-App-Server dann versucht den Dateipfad LOKAL (also bei sich selbst) aufzurufen - völlig sinnlos sowas, dabei geht's in diesem Szenario um ALLES ANDERE (!!) als den PHP-Dateipfad auf dem PHP-FPM-App-Server lokal aufzurufen:

Es geht vielmehr darum, dass der Webserver (Maschine A) den Inhalt der darauf vorliegenden PHP-Datei per REMOTE_IP:9000 auf den PHP-FPM-Application-Server (Maschine B) weiterreicht und der PHP-FPM-Application-Server das Ganze interpretiert und dann das Ergebnis wieder am den Webserver (Maschine A) zurückgibt.

Weiss jemand, wie das genau geht? Besten Dank für eure Feedback(s)...

[jmar83]

Wie sieht's mit "libapache2-mod-fastcgi" anstelle von "libapache2-mod-fcgid" aus? Wird der Remote PHP-FPM application Server davon auch unterstützt - theoretisch zumindest? Oder eher nicht?
https://github.com/berenddeboer/libapac ... i/issues/1

[jmar83]

Maschine A = Alter Windows Server mit PHP 7.0
Maschine B = Allerneustes Debian 11 mit installiertem php7.4-fpm-Paket und

-OHNE allowedips-Eintrag (=ALLE ZUGELASSEN) in der Datei www.pool unter /etc/php/fpm/...

SOWIE

- BIND = 0.0.0.0 (also nicht nur localhost / 127.0.01)


-> Externes telnet auf den PHP-FPM-App-Server mit "telnet IP_ADRESSE 9000" gibt zumindest Antwort.

[TRex]

https://serversforhackers.com/c/php-fpm ... -directive

Probiers mal mit nginx, dann kannst du wenigstens sicher sein, dass der FPM-Server richtig konfiguriert ist. Dem Artikel nach soll das wohl tun.

[heisenberg]

Habe ich da wirklich Windows-Webserver mit PHP gelesen? Würg! Kotz! Wer tut sich dass denn an?

2 Möglichkeiten, um damit zu arbeiten:

• Du installierst eine/mehrere alte Debianversionen mit entsprechend alten PHP-Versionen auf separaten VMs.
• Du nutzt Docker und installierst pro unterschiedlich benötigter Anwendung einen Container. Vermutlich brauchst Du auch entsprechende Datenbankcontainer, weil die alten PHP-Versionen nicht mit den neuen MySQL-/MariaDB-Versionen zurecht kommen. Auf der Hostebene ist ein Webserver(meine Empfehlung wäre auch nginx), der als ReverseProxy die Schnittstelle zwischen Domains und Containern ist.

[Mozie]

Hallo,

Du schreibst:

Ständig "File not Found" - es scheint irgendwie so zu sein, dass der Dateipfad vom Webserver an den PHP-FPM-App-Server weitergegeben wird und PHP-FPM-App-Server dann versucht den Dateipfad LOKAL (also bei sich selbst) aufzurufen - völlig sinnlos sowas, dabei geht's in diesem Szenario um ALLES ANDERE (!!) als den PHP-Dateipfad auf dem PHP-FPM-App-Server lokal aufzurufen:

Und genau diese Funktionsweise ist auch richtig!

Du rufst eine Website auf, dein Webserver versucht dir diese aufgerufene Datei (im Regelfall index.html oder index.php) zurückzugeben. Rufst du eine *.html Datei auf, kann der Webserver dir diese auch direkt zurückgeben, da dein Browser diese interpretieren muss. Rufst du aber eine *.php Datei auf, kann der Webserver diese selbst nicht interpretieren und sendet deshalb eine Aufforderung an den PHP-Interpreter, der diese Datei /var/www/html/xyz.php auszuführen und die Rückgabe dem Webserver zurückzugeben soll. Der PHP-Interpreter versucht nun die Datei auf dem mitgegebenen Pfad des Webservers zu öffnen (im Beispiel /var/www/html/xyz.php), wenn er diese nicht lokal findet, kann er diese auch nicht öffnen.
Der Webserver kann keine Dateien an den PHP-Interpreter weiterreichen, oder was denkst du wie includes in PHP sonst geöffnet werden können? Die werden alle lokal vom PHP-Interpreter versucht zu öffnen und nicht vom Webserver.
Die Web-Daten müssen also dem Webserver und dem Server, auf dem der PHP-Interpreter läuft, zur Verfügung stehen!

Mein Vorschlag:
Auf dem Debian Server läuft ein Proxy (bspw. NGINX, wie bereits von anderen Mitgliedern geschrieben), der die Anfragen an deinen Windows Server weiter reicht. Auf diesem befindet sich ein weiterer Webserver (NGINX oder Apache) und der PHP-Interpreter mit den entsprechenden Webserver Dateien.

Ich hoffe ich habe keinen Mist geschrieben und es verständlich erklärt.
Grüße
Micha

[jmar83]

Hallo Micha

Besten Dank für dein Feedback!

Folgende 2 Fragen bleiben für mich offen:

- Man sieht (sind zwar eher rar) Beispiele bei denen nicht localhost:9000 oder 127.0.0.1:9000 verwendet wird, sondern eine andere IP. (also ein anderer Rechner / dez. PHP-FPM Application Server)

- Was bringt es, über den lok. TCP/IP-Stack zu gehen, wenn das ALLEINE gar nicht ausreicht - für was verwendet man dann 127.0.0.1:9000 oder localhost:9000 - wenn noch andere "Kanäle" (wie Filesystem I/O) notwendig sind. (Wie diese "File not found"-Meldung bezeugt)

Irgendwie ergibt die ganze PHP-FPM-Geschichte mit TCP & localhost für mich deswegen wenig bis keinen Sinn. Ziemlich schräg m.E., eine solche "Architektur" (also in Anführungszeichen)

[Mozie]

Hi,

hier kann ich nur vermuten:

- Man sieht (sind zwar eher rar) Beispiele bei denen nicht localhost:9000 oder 127.0.0.1:9000 verwendet wird, sondern eine andere IP. (also ein anderer Rechner / dez. PHP-FPM Application Server)

• Ich kann mir nur vorstellen, wenn Skripte eine sehr lange Laufzeit haben, werden diese auf unterschiedliche Server verteilt. (wie gesagt ist eine Vermutung)

Hier habe ich lange gegoogelt und habe eine Antwort gefunden

- Was bringt es, über den lok. TCP/IP-Stack zu gehen, wenn das ALLEINE gar nicht ausreicht - für was verwendet man dann 127.0.0.1:9000 oder localhost:9000 - wenn noch andere "Kanäle" (wie Filesystem I/O) notwendig sind. (Wie diese "File not found"-Meldung bezeugt)

• Kurz gesagt: Auf Windows gibt es keine Sockets, da musst du CGI mit TCP/IP verwenden.

• Innerhalb Linux-Umgebungen solltest du Sockets nutzen. Sockets sind schneller als TCP/IP, da hier die CGI Befehle noch extra eingepackt werden müssen

Viele Grüße
Micha

[jmar83]

Vielen vielen Dank!!