php-fcgi Bug in ISPConfig 3.1.11

[t0mc@]

Hallo zusammen,

habe diesen Bug in ISPConfig 3.1.11 gefunden:
Wenn ein neuer Client angelegt wird und diesem eine neue Webseite mit PHP-FCGI Unterstützung zugeordnet wird, funktioniert keinerlei PHP - basiertes Script, es kommt immer nur ein "HTTP 500 - Internal Server Error" zurück.
Im Apache error.log der Seite ist dann das hier zu lesen:

[Tue May 22 15:13:18.446702 2018] [fcgid:warn] [pid 19493] (104)Connection reset by peer: [client 85.197.12.163:42220] mod_fcgid: error reading data from FastCGI server [Tue May 22 15:13:18.446765 2018] [core:error] [pid 19493] [client 85.197.12.163:42220] End of script output before headers: index.php

Ich konnte herausfinden, dass das FCGI - Wrapper Script für diesen neuen Kunden, welches unter "/var/www/php-fcgi-scripts/..." für die entsprechende Webseite angelegt wurde, offenbar gar nicht erst gestartet werden konnte; zumindest war kein entsprechender Prozess zu finden. Das Script hat als Owner den user der Webseite (web<nr>) und als Primäre Gruppe die Clientgruppe ("client<nr>"), die Rechte stehen auf 550. Das heißt also, dass nur der Owner bzw. ein Mitglied der Primären Gruppe das Script ausführen darf:

/var/www/php-fcgi-scripts/web105# ls -al total 12 dr-xr-x--- 2 web105 client11 4096 Mai 22 20:42 . drwxr-xr-x 19 root root 4096 Mai 22 20:42 .. -r-xr-x--- 1 web105 client11 580 Mai 22 20:42 .php-fcgi-starter

Das führte mich letztendlich dazu, dass der Benutzer "www-data", unter dem der Apache Prozess ja läuft, in der Primären Gruppe des Kunden fehlt, so dass der Apache das Wrapper Script nicht ausführen durfte:

~# cat /etc/group [...] client5:x:5014:www-data client8:x:5015:www-data client10:x:5016:www-data client11:x:5017:


Ich habe den Benutzer "www-data" dann manuell in die Primäre Gruppe des Kunden aufgenommen und nach einem Apache neustart hat es dann funktioniert:

~# cat /etc/group [...] client5:x:5014:www-data client8:x:5015:www-data client10:x:5016:www-data client11:x:5017:www-data

Hier scheint seit einer der letzten ISPConfig Versionen also ein Bug rein gekommen zu sein, denn bei den "älteren" Kunden auf dem Server war der Benutzer "www-data" richtigerweise in den entsprechenden "Kunden"-Gruppen. Offenbar wird bei neuen Kunden / Webseiten der Benutzer "www-data" nicht mehr in die entsprechende Gruppe hinzugefügt.

Ich würde gerne einen Issue unter

https://git.ispconfig.org/ispconfig/ispconfig3/issues

einstellen, aber entweder bin ich blind oder es gibt keine Möglichkeit (mehr), sich dort neu zu registrieren.

Vllt. kann das jmd übernehmen, der dort einen Zugang hat...

Viele Grüße
T0mc@

 

[Till]

Funktioniert einwandfrei hier in ISPConfig 3.1.11, User www-data wird der client Gruppe jeweils hinzugefügt. Da die version 3.1.11 auf einigen hunderttausend Servern seit fast einem halben Jahr läuft, kannst Du solch einen Bug der das anlegen neuer webs unmöglich macht schon rein statistisch ausschließen, er wäre daher eh sofort im BT geschlossen worden.

Es ist also ein Problem deines Servers. Schau doch mal ob user und Gruppe des web servers korrekt unter system > server config > web eingetragen sind.

Und ja,im GIT serer kann man sich nicht mehr anmelden da dort seit einiger zeit massiv Spammer Ihr Unwesen getrieben haben und ich ein paar tausend Konten durchsehen und löschen muss.

 

[t0mc@]

Das ist schön für die anderen Server, dass es dort funktioniert ... und auch wenn man es statistisch vllt. annähernd(!) ausschließen kann, habe ich bei unserem Server den reproduzierbaren Beweis, dass dieses Verhalten offenbar - warum auch immer - auftreten kann. Pauschalaussagen helfen bei der Fehlersuche leider nicht wirklich weiter.

Wie man an den "alten" Kunden sieht, hat es offenbar auf diesem Server ja auch schon einmal funktioniert und das einzige, was dort seitdem verändert wurde, sind OS und ISPConfig Updates. Daraus folgt: Irgendetwas muß durch ein Update ins System gekommen sein, welches das Hinzufügen des "www-data" zur Clientgruppe verhindert.

Zu deiner Frage:
Ja, der Benutzer ist korrekt dort eingetragen:

Wenn dem nicht so wäre, vermute ich, würden die Ownerships auf Neu angelegte Web Verzeichnisse nicht stimmen... das tun sie aber.

Wo / wie könnte man das Problem eingrenzen? Kann man irgendwo sehen, was ISPConfig genau treibt, wenn ein neuer Kunde bzw. eine neue Webseite eingerichtet wird?

 

[Till]

Das ist schön für die anderen Server, dass es dort funktioniert ... und auch wenn man es statistisch vllt. annähernd(!) ausschließen kann, habe ich bei unserem Server den reproduzierbaren Beweis, dass dieses Verhalten offenbar - warum auch immer - auftreten kann.

Ich glaube Dir gern, dass Du den Konfiguartionsfehler Deines Servers reproduzieren kannst, das haben Konfiguartionsfehler so an sich dass sie erst dann nicht mehr auftreten wenn der Fehler behoben wurde, dies qaulifiziert Dein Problem nur nicht als Bug. Denn wie ich Dir ja bereits mitgeteilt hatte tritt das Problem auf anderen System nicht auf, wie ich auch extra noch einmal überprüft hatte.

Wenn dem nicht so wäre, vermute ich, würden die Ownerships auf Neu angelegte Web Verzeichnisse nicht stimmen... das tun sie aber.

Es werden keine Ownerships auf diesen User oder die Gruppe von ISPConfig in der Website gesetzt, das Fehlen würde sich also erst einmal nur in dem von Dir geschilderten Fehlern des Users in der client Gruppe niederschlagen. Daher auch meine Frage ob sie geesetzt sind.speicher die Ansicht aus dem screenhshot bitte trotzdem einmal ab und lege danach einen neeuen client an und dann eine neue website.

Wo / wie könnte man das Problem eingrenzen? Kann man irgendwo sehen, was ISPConfig genau treibt, wenn ein neuer Kunde bzw. eine neue Webseite eingerichtet wird?

https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/

 

[t0mc@]

Vielen Dank für das Schubsen auf die Doku bzgl. Debugging.

Habe das gerade probiert:

• Wie du vorgschlagen hast, die Serverkonfig vom Screenshot noch mal unverändert gespeichert
• Log Level per GUI erhöht und auf das Übernehmen der Änderungen gewartet
• cron Eintrag bzgl. server.sh auskommentiert
• Per GUI einen neuen Test Kunden hinzugefügt
• Per GUI diesem Kunden eine neue Dummy Webseite angelegt incl. PHP-FCGI Unterstützung
• server.sh manuell ausgeführt

Ergebnis:
# /usr/local/ispconfig/server/server.sh 22.05.2018-23:44 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'. 22.05.2018-23:44 - DEBUG - Found 4 changes, starting update process. 22.05.2018-23:44 - DEBUG - Processed datalog_id 3329 22.05.2018-23:44 - DEBUG - Processed datalog_id 3330 22.05.2018-23:44 - DEBUG - Processed datalog_id 3331 22.05.2018-23:44 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_insert'. 22.05.2018-23:44 - DEBUG - Calling function 'insert' from plugin 'apache2_plugin' raised by event 'web_domain_insert'. 22.05.2018-23:44 - DEBUG - Adding the group: client13 22.05.2018-23:44 - DEBUG - Adding the user: web107 22.05.2018-23:44 - DEBUG - Creating symlink: ln -s /var/www/clients/client13/web107/ /var/www/test.tst 22.05.2018-23:44 - DEBUG - Creating symlink: ln -s /var/www/clients/client13/web107/ /var/www/clients/client13/test.tst 22.05.2018-23:44 - DEBUG - exec: chown -R web107:client13 /var/www/clients/client13/web107/web 22.05.2018-23:44 - DEBUG - exec: chown root:root /var/www/clients/client13/web107/web 22.05.2018-23:44 - DEBUG - Creating fastcgi starter script directory: /var/www/php-fcgi-scripts/web107/ 22.05.2018-23:44 - DEBUG - Creating fastcgi starter script: /var/www/php-fcgi-scripts/web107/.php-fcgi-starter 22.05.2018-23:44 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/test.tst.vhost 22.05.2018-23:44 - DEBUG - Creating symlink: /etc/apache2/sites-enabled/100-test.tst.vhost->/etc/apache2/sites-available/test.tst.vhost 22.05.2018-23:44 - DEBUG - Created AWStats config file: /etc/awstats/awstats.test.tst.conf 22.05.2018-23:44 - DEBUG - Apache status is: running 22.05.2018-23:44 - DEBUG - Calling function 'restartHttpd' from module 'web_module'. 22.05.2018-23:44 - DEBUG - Restarting httpd: systemctl restart apache2.service 22.05.2018-23:44 - DEBUG - Apache restart return value is: 0 22.05.2018-23:44 - DEBUG - Apache online status after restart is: running 22.05.2018-23:44 - DEBUG - Processed datalog_id 3332 22.05.2018-23:44 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock finished.

Unmittelbar danach sieht das Ende der /etc/group so aus:
~# cat /etc/group ... ispapps:x:5003:www-data ispconfig:x:5004:www-data client1:x:5005:www-data client0:x:5006:www-data client2:x:5007:www-data client4:x:5008:www-data client7:x:5010:www-data client6:x:5011:www-data client9:x:5013:www-data bacula:x:129: client5:x:5014:www-data client8:x:5015:www-data client10:x:5016:www-data client11:x:5017: client12:x:5018: client13:x:5019: ~#

Wie man sieht, ist in der neuen Gruppe "client13" der Benutzer "www-data" nicht eingefügt worden. In der Debug Ausgabe oben sieht man, dass die Gruppe von ISPConfig angelegt wird. Dann gehe ich doch davon aus, dass auch ISPConfig den User "www-data" in die Gruppe aufnehmen sollte... in der Debug Ausgabe sehe ich dazu aber keinerlei Hinweis, weder ein shell - Kommando, was dies bewerkstelligen soll, noch irgendeinen Fehler...
BTW: Die Gruppen "client11" und "client12" sind ebenfalls neu angelegte Testkunden von heute, auch hier kein "www-data" als Mitglied...

 

[Till]

Habe gerade mal Im sourcecode nachgesehen, Dein Fehler ist dass Du den Sicherheitslevel verstellt hast. Ändere den mal zurück auf den standard Wert 'high'.

 

[t0mc@]

Du hattest recht, das Setzen des Sicherheitslevels auf "High" hat tatsächlich geholfen. Jetzt wird "www-data" wieder der Clientgruppe zugefügt.

Vielen Dank schon mal für die schnelle Hilfe!

So ganz kann ich aber noch nicht nachvollziehen, wo hier der Sinn liegt... Aus welchem Grund führt das erniedrigen eines Sicherheitslevel auf "Medium" dazu, dass "www-data" nicht mehr einer neuen Clientgruppe zugeordnet wird? Wenn überhaupt hätte ich das bei einem "High" Level erwartet. Aber selbst dann: Das führt ja ganz offenbar dazu, dass PHP-FCGI nicht mehr nutzbar ist (bei Level "Medium" ??!), sogar nur Fehler in Logs zu finden sind und es ansonsten keinerlei Hinweise zu diesem Verhalten gibt.
Ist das wirklich so gewollt? Und wenn das wirklich ein gewolltes Verhalten ist, müßte dann nicht konsequenterweise beim erneuten Setzen des Levels auf "Medium" der "www-data" wieder aus allen Clientgruppen entfernt werden?
Oder verstehe ich hier nur was grundlegend nicht?