Eigene PHP Versionen (Fehler)

isp_geek2

New Member
Hi,

wir haben hier ein sehr merkwürdiges Problem.
Eventuell kann jemand helfen.

Wir haben ein Multiserver-System, das mit Deban 8, ispconfig 3.1.11 lief.
Dort hatten wir mehrere eigene PHP Versionen angelegt (php5.6, php7.0, php7.1, php7.2, php7.3).

Nachdem wir alle unsere Server (Master wie auch Slaves) auf Debian 10 und ispconfig 3.2.2 gebracht haben und alles soweit gut läuft,
haben wir das Problem das neu angelegte PHP Versionen (php7.4 und php8.0) nach dem man diese über das Admin-Panel einer Webseite zuweist, von ispconfig nicht mit den richtigen Pfaden in der /var/www/php-fcgi-scripts/webXXX/*.php-fcgi-starter versehen werden. Die Pfade sind leer ( PHPRC="" bzw. exec \ ).
Apache wirft natürlich einen 500 Internal Server Error aus.

Das tritt nur bei den neu angelegten PHP Versionen auf.
Die alten PHP Versionen können ohne Probleme weiterhin zugewiesen werden und alles läuft so wie es sein sollte.
Pfade wurden natürlich mehrmals überprüft.

Interessanterweise tritt der Fehler ebenfalls nicht auf, wenn wir die default PHP Version eines Servers manuell zuweisen (update-alternatives --config php und update-alternatives --config php-cgi ).

Somit vermuten wir das dieses Problem an ispconfig liegt.

Hat jemand eine Idee?

Schöne Grüße
Ron
 

Till

Administrator
Prüf mal alle einstellungen unter System > server config, Du musst die Pfade dort für Debian 10 anpassen, und dann prüf auch die Einstellungen der zusätzlichen PHP Versionen.
 

isp_geek2

New Member
Vielen Dank für den Tip!
Das brachte uns immerhin ein Stück weiter.

Aber generell scheint die Struktur der Datenbanken zwischen Master und Slave inkonsistent gewesen zu sein.
Dank Debug-Modus haben wir feststellen können, das in der dbispconfig > server_php des betroffenen Slaves die Spalte 'php_fpm_socket_dir' fehlte. Nachdem wir das berichtigt hatten, funktionierte der Datenabgleich.
Die neuen PHP Versionen lassen sich jetzt ohne Probleme zuweisen.
 

matz

Active Member
Da der Titel von diesem Thread eher allgemeiner Natur ist, frage ich auch mal nach meinem Problem. Ich ging nach dieser Anleitung vor, es hat soweit geklappt. Bei mir läuft Debian 10 mit Nginx only, ISPC ist aktuell.

Zwei der Websites sind komplett geschützt, der Schutz liegt jeweils auf dem "/"-Ordner. Beide Seiten laufen mit Wordpress 5.6.2 und PHP 7.4 (nach der Umstellung). Nun passiert das:

Man begibt sich auf die Seite, das Anmelde-Popup kommt, Zugangsdaten ok, loggt sich dann im Administrationsbereich ein (wp-admin) und nach einigen Aktionen (z.B. Zustand der Seite überprüfen) kommt erneut das Anmelde-Popup, nur dass die Anmeldung jetzt fehlschlägt.

Ich weiß nicht wo ich das zuordnen kann (ISPC? WordPress? Nginx?) aber vor der Umstellung auf PHP 7.4 gab's keine Probleme. ISPC läuft mit der Default-PHP-Version (7.3).

Meine fpm-Einstellungen für PHP 7.4 sehen so aus:
911


Irgendein Lösungsansatz? Ich suche schon seit gestern und mir fällt nichts mehr ein...

Ok. Kleiner Nachtrag, gerade aufgefallen. Rufe ich die Websiteüberprüfung auf, steh das im access.log:
Code:
"GET /wp-json/wp-site-health/v1/tests/authorization-header?_locale=user HTTP/2.0" 401 (...)
Man beachte hier den user "user". Wo der wohl herkommt???
In error.log liest man dann das über den "user":
Code:
[error] 29963#29963: *2768 user "user" was not found in "/var/www/clients/client7/web32/web/.htpasswd"

Somit wäre die Frage der Fehlerquelle geklärt. Ich muss wohl den WordPress-Leuten auf die Füße treten...
 
Zuletzt bearbeitet:

Till

Administrator
Ein Passwortschutz der Webseite hat nichts direkt mit PHP zu tun, ist ganz andere Ebene bevor überhaupt an PHP übergeben wird. Schau mal ins access.log der Seite, was da genau passiert, also was abgerufen wird und wohin Du ggf. umgeleitet wirst.
 

matz

Active Member
Jep... Ich habe es gerade lokalisiert. Scheint tatsächlich an der neuen Wordpress-Version zu liegen, Logauszüge siehst du in der Ergänzung des vorherigen Beitrags. User ist wohl der gerade eingeloggte Benutzer.
 

Till

Administrator
Hmm, jo, wenn wp versucht selbst per ajax zuzugreifen, dann muss es in die http authentifizierung laufen. wenn man es nicht abschalten kann dann bliebe ggf. nurd en seitenschutz in ISPConfig abzuschalten und ihn manuell im nginx direktiven Feld zu konfigurieren, aber so dass es die ajax url ausnimmt vom Passwortschutz.
 

matz

Active Member
Sieht ganz so aus. Das ist aber eine andere Baustelle. Es kamen halt zwei Sachen zeitlich zu dicht zusammen: WP-Update und PHP-Umstellung. Das war verwirrend...
 

Till

Administrator
Von daher, besser immer einen neuen Thraed aufmachen wenn die Fehlermeldung oder den Fehler den Du hast nicht 100% mit dem Fehler in einem bestehenden Thread übereinstimmt :)
 

Werbung

Top