Umstellung auf PHP als FastCGI, php.ini, suexec, Plesk Problem

T

tsk

Member
Hallo zusammen,

ich wende mich an Euch Experten, da ich ein Problem mit einer (Um)konfiguration meines vServers (Ubuntu 8.04 mit Plesk 9.5.4) auf PHP/FastCGI bei Hosteurope habe. Der Server lief bislang mit PHP als Apache Modul. Meine vhost.conf funktionierte und PHP ließ sich darüber konfigurieren.
Ich habe für die Umstellung folgende Schritte unternommen (entsprechend Hosteurope FAQ für Plesk 9.3x-9.5x):

1) Hosting Einstellungen in Plesk geändert für folgende Dienste:
PHP-Unterstützung x als FastCGI-Applikation (safe_mode off)
CGI-Unterstützung x
Perl-Unterstützung x
FastCGI-Unterstützung x
(Rest nicht gewählt. FastCGI-Unterstützung hatte ich auch vorher – beim Betrieb von PHP über Apache Modul, bereits angewählt – warum auch immer)
2) Verzeichnis/Datei für domainspezifische php.ini angelegt unter /etc/phpconfigs/php-10001.ini mit Kopie aus /etc/php5/cgi/php.ini
10001 entspricht der UID des in Plesk angelegten FTP Users.
Verzeichnis: root/root 755
Datei: root/root 755
(zum Test auch schon mal dem FTP User übereignet – aber wieder zurückgesetzt)
3) Datei /var/www/cgi-bin/cgi_wrapper/cgi_wrapper wie folgt geändert:

Code: 
#!/bin/sh
PHPRC="/etc/phpconfigs/php-${UID}.ini"
[ -f ${PHPRC} ] || PHPRC="/etc/php5/cgi/"
export PHPRC 
exec /usr/bin/php5-cgi

Die Pfade habe ich überprüft, sie scheinen alle zu stimmen. Owner/Rechte: root/root 755

4) PHP Einstellungen aus vhost.conf in /etc/phpconfigs/php-10001.ini eingepflegt und in vhost.conf auskommentiert. Sie besteht jetzt im Wesentlichen nur noch aus Rewriting Angaben.

5) Apache Neustart

6) phpinfo zeigt bei Server API korrekt: CGI/FastCGI
Aber: Configuration File (php.ini) Path: /etc/php5/cgi
und: Loaded Configuration File: /etc/php5/cgi/php.ini
also nicht meine individuelle php.ini namens /etc/phpconfigs/php-10001.ini. Dementsprechend werden auch meine PHP Settings nicht übernommen.
Auch suexec taucht in der Aufstellung nicht auf, wobei ich mir nicht sicher bin, ob es in der php.ini stehen müßte, wenn kein Apache Modul mehr im Spiel ist?

Ich vermute stark ein Problem mit suexec. Ein slocate suexec bringt folgendes zu Tage:

/opt/psa/suexec
/opt/psa/suexec/psa-suexec
/var/log/apache2/suexec.log.1
/var/log/apache2/suexec.log
/usr/lib/apache2/suexec
/usr/lib/apache2/suexec.distrib
/usr/lib/apache2/modules/mod_suexec.so
/usr/lib/sw-cp-server/sw-suexec
/usr/share/man/man8/suexec2.8.gz
-diverse Links zur HTML Doku -
/etc/apache2/mods-enabled/suexec.load
/etc/apache2/mods-available/suexec.load

im Log /var/log/apache2/suexec.log.1 von heute steht:
[2011-01-23 10:24:43]: uid: (10001/*ftpusername*) gid: (2523/2523) cmd: cgi_wrapper
[2011-01-23 10:26:23]: uid: (10001/*ftpusername*) gid: (2523/2523) cmd: cgi_wrapper
[2011-01-23 10:38:07]: too few arguments
[2011-01-23 10:39:45]: too few arguments
wiederholt sich

*ftpusername* ist hierbei Platzhalter für meinen Plesk FTP Username. Bin jetzt etwas ratlos, in welche Richtung ich weiter forschen könnte. Habt Ihr vielleicht ein paar Tipps für mich?

Vielen Dank im Voraus,

Thomas

Nachtrag:
/usr/lib/apache2/suexec -V: keine Ausgabe,
/usr/lib/apache2/suexec.distrib -V Ausgabe wie folgt:
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="www-data"
-D AP_LOG_EXEC="/var/log/apache2/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=100
-D AP_USERDIR_SUFFIX="public_html"
 
Last edited by a moderator:
Wie du der Dokumentation von PHP entnehmen kannst, muss PHPRC auf das Verzeichnis verweisen, welches die php.ini Datei enthält. PHPRC darf nicht auf eine Datei verweisen.
 
Hallo Roger,

danke für Deine Antwort - sogar am Sonntag. Meinst Du diese Zeile?
Code: 
PHPRC="/etc/phpconfigs/php-${UID}.ini"

Die verweist tatsächlich auf eine Datei (php-10001.ini). In der genutzen Quelle, dem Support FAQ von Hosteurope, steht sie aber genau so drin - zumindest in dem Teil, der meine Plesk Version beschreibt.

Bei älteren Plesk (<9.3) gibt es in deren FAQ tatsächlich ein Directory, welches die UID beinhaltet. Die Konfiguration wird dort im vhost.conf vorgenommen, entsprechend:

Code: 
<Directory "/var/www/vhosts/*ihredomain*/httpdocs">
<Files ~ (\.php)>
FCGIWrapper "/usr/bin/php-cgi -c /etc/phpconfigs/*ihredomain*" .php
Options All
</Files>
</Directory>

wohingegen bei Plesk 9.3-9.5x kein entsprechender vhost Eintrag existiert - dafür aber den Wrapper.

Ich bin also weiterhin unsicher, wo ich eine Änderung vornehmen soll/kann. Irgendwie macht mich dieses Plesk krank (obwohl ich ohne vielleicht noch peinlichere Fragen stellen würde).
 
tsk said:
Die verweist tatsächlich auf eine Datei (php-10001.ini). In der genutzen Quelle, dem Support FAQ von Hosteurope, steht sie aber genau so drin - zumindest in dem Teil, der meine Plesk Version beschreibt.
Click to expand...
Dann ist der FAQ-Eintrag schlicht und ergreifend falsch.
 
Ja, und das wäre vielleicht sogar die angenehmste Lösung. Das dumme ist, in einem anderen Forum (ich bin mir nicht sicher, ob Links erwünscht/erlaubt sind - also ohne Link) genau dieses Vorgehen beschrieben wird. Da lautet der entsprechende Teil:

Code: 
#!/bin/sh
PHPRC="/etc/phpwebs/php-${UID}.ini"
[ -f ${PHPRC} ] || PHPRC="/etc/php.ini"
export PHPRC
exec /usr/bin/php-cgi

Könntest Du mir denn eine stimmige Konfiguration vorschlagen, oder einen weiterführenden Link geben. Für mich ist Plesk sehr großes Neuland.
 
Mein Verständnis vom vorgeschlagenen Hosteurope Wrapper:
Code: 
#!/bin/sh
PHPRC="/etc/phpconfigs/php-${UID}.ini"
[ -f ${PHPRC} ] || PHPRC="/etc/php5/cgi/"
export PHPRC 
exec /usr/bin/php5-cgi

1) PHPRC wird missbräuchlich falsch belegt (mit Datei statt Pfad)
2) Existiert diese Datei, so nimm sie ODER lade PHPRC neu mit Pfad ins cgi
3) Export - was Du gefunden hast.
Klingt nicht lupenrein, aber syntaktisch noch zulässig, oder?
 
Syntaktisch ist das Shell-Skript korrekt. Weshalb PHP trotzdem deine php.ini-Datei ignoriert, habe ich bereits geschrieben.
 
Ja, ich verstehe, dass es an der Datei statt eines Pfades liegt - allein mir fehlt das Wissen, diese Tatsache in eine lauffähige Konfiguration umzusetzen. Ich habe jetzt fast 30 Stunden damit verbracht, eine mutmaßlich banale Konfiguration vorzunehmen, habe viele Dokus gefunden, die bis Plesk 9.2 gelten (mittels Patch) - danach auf gar keinen Fall mehr (wie viele Nutzer mit Plesk > 9.2 darunter posteten). An insgesamt 3 Stellen gibt es Anleitungen ähnlich Hosteurope - allerdings glaube ich selbst nicht, dass die von mir zitierte klappt, weil dort tatsächlich PHPRC="/etc/php.ini" steht (bei Hosteurope steht dort PHPRC="/etc/php5/cgi/", was mir korrekt erscheint.

Ich werd mir noch nen Kaffee kochen und eine weitere Google-Night beginnen. Danke auf jeden Fall für den Tipp, den ich als Ansatzpunkt nutzen werde.
 
755er Rechte sind sinnfrei für eine Separierung mittels suexec/(f)cgi. Das "world" Lesezugriff hat, ist gar nicht mehr notwendig, den Apache-User gibt man in die Gruppe des jeweiligen Webusers. 750 wäre hier zielführender.

Ausserdem kann ich mich daran erinnern, dass suxec bei chmod 755 für den Wrapper den Dienst mit einer Fehlermeldung quittiert hat (im suexec.log). Zumindest der musst 750 haben, der Rest war egal.

Vielleicht kannst du in dieser Richtung nochmal schauen. Zur ENV-Var PHPRC hat ja Roger schon was gesagt.

Anmerkung: Meine Ausführungen beziehen sich auf eine Plesk-lose Konfiguration, wobei die zugrundeliegenden Aspekte jedoch gleich sein sollten.
 
dev said:
Ausserdem kann ich mich daran erinnern, dass suxec bei chmod 755 für den Wrapper den Dienst mit einer Fehlermeldung quittiert hat (im suexec.log).
Click to expand...
Da erinnerst du dich falsch. SuExec meckert nur, wenn die auszuführenden Dateien group- oder world-writable sind.
 
Stimmt, gerade probiert. Ich hatte meine SGID-Konfig für den netatalk-Daemon und chmod 2770 im Kopf. Sorry.
 
Hab's auch gerade getestet. Nehme ich World die Leserechte, crasht der Server beim Restart. Vergebe ich sie wieder, startet er durch.
 
Es läuft!

Hallo zusammen,

am Tag 4 meiner Odyssee bzw. in der Nacht war es schließlich soweit. Alles lief, wie es sollte. Der Wrapper – also wesentlicher Teil der bisherigen Diskussion - hatte damit am wenigsten zu tun. Eher schon das Konzept, wohin man ihn platzieren sollte. Sowohl der (ich nenne ihn mal so) Hosteurope Wrapper als auch der Wrapper aus dem offiziellen How-to bei Plesk, bieten mutmaßlich besonderen Charme, da sie automatisierbar erscheinen hinsichtlich der Domain. Man hat also einen zentralen Wrapper unter /var/www/cgi-bin/cgi_wrapper, und der verweist auf die tatsächlich zu nutzenden php.ini's. Pustekuchen – hat bei mir in keiner Variante wirklich geklappt.
Der Grund liegt in der Ownership. Der Wrapper muss ausführbar sein unter dem jeweiligen FTP User der Domain, sonst kriegt suexec die Krise. Gebe ich dem Wrapper dem ersten FTP User, so klappt für diesen alles. Alle anderen Domains, die einen anderen FTP User haben, gucken in die Röhre. Zusätzlich wird dieser zentrale Pfad (bzw. der Wrapper darin) bei jedem Anlegen einer neuen Domain in Plesk überschieben (denke ich zumindest). Ist also Kabes. Wollte ich auf keinen Fall. Mein Weg zum Ziel steht im nächsten Beitrag – als kleines Howto für andere Trottel wie mich – und als Diskussionsgrundlage, es vielleicht noch richtiger zu machen.

Glückauf,

Thomas
 
Vorläufiges How-to PHP FastCGI statt Apache Modul unter Ubuntu 8.04 und Plesk 9.5.x

Achtung: Erstellt von einem PHP Entwickler, der ein bekennender Linux/Plesk Server Stümper ist. Also Vorsicht bei Nachahmung, ich weiß von nix, wenn's plötzlich knallt!

Das vorher an dieser Stelle gepostete Tutorial "Vorläufiges How-to PHP FastCGI statt Apache Modul unter Ubuntu 8.04 und Plesk 9.5.x" war, wie ich heute weiß, an vielen Stellen falsch. Ich ziehe es deshalb hurtigst zurück.

Der richtige Weg einer php Umstellung von Modul auf FastCGI unter Plesk 9.5.x ist, es einfach zu machen. Plesk führt bei der Umkonfiguration alle Schritte durch, die erforderlich sind für mod_fcgid. Es müssen keine User (z.B. www-data) manuell zu anderen Gruppen hinzugefügt werden (dieser Schritt wird in vielen FastCGI/PHP Tuts als zwingend erforderlich beschrieben) und es müssen schon gar nicht Rechte an Directories geändert werden, die Plesk angelegt hat.

Die Schritte in aller Kürze:
1) Plesk auf FastCGI (statt Modul) umstellen.
2) Geeigneten Wrapper (siehe unten) unter /var/www/cgi-bin/cgi_wrapper/cgi_wrapper anlegen. Den von Plesk vorinstallierten vorher wegsichern/umbenennen.
3) eigene php.ini anlegen (mit Kopie der bislang genutzen - phpinfo verrät dazu mehr)
4) /var/www/vhosts/mydomain.tld/conf/vhost.conf umbenennen/sichern und eigene Anlagen. Als Basis gilt die durch Plesk vorkonfigurierte /var/www/vhosts/mydomain.tld/conf/httpd.include (hier niemals Änderungen vornehmen), die bereits korrekte Settings für suexec enthält). Die anzulegende vhost.conf dient somit dazu, den per "httpd.include" definierten Standard, zu verändern, z.B. in einer eigenen <Directory> Direktive.
5) Apache restart

Fertig. Falls doch etwas hakt. Das Mekka der Ursachenforschung liegt im suexec log, bei mir unter:
/var/log/apache2/suexec.log. Je näher man der tatsächlich erforderlichen Konfiguration kommt, desto verständlicher werden die Logeinträge.

Zum "richtigen" Wrapper:
Egal wie man's macht, er sollte wirklich nur unter /var/www/cgi-bin/cgi_wrapper/cgi_wrapper zu erreichen sein (Remember, we'r talking about Plesk) - und es sollte nichts an den eingerichteten Rechten geändert werden.

Jetzt bleiben 2 Varianten:
1) Wrapper für eigene php.ini unter /var/www/vhosts/mydomain.tld/conf (ich nenne es mal die Plesk Variante, weil ich sie dort in der Knowledgebase gefunden habe)
Vorteil: php.ini im domaineignen /conf Directory, schön aufgeräumt.
Nachteil 1: Die Ermittlung der Domain muss "teuer" erkauft werden:

Code: 
domain=`fgrep -m 1 "$UID" /etc/passwd| awk -F\: '{print $6}' |awk -F"/" '{print $5}'`
Nachteil 2: Das /conf Directory braucht 755 statt 750

2) Wrapper für eigene php.ini unter (z.B.) /etc/phpconfigs/php-{ftp_UID}.ini
Nachteil: Nicht im /conf der Domain, sondern ziemlich ausserhalb.
Vorteil 1: Ich muß im Wrapper nur die - sowieso vorhandene - UID nutzen und nichts aufwendig ermitteln.
Vorteil 2: Das /conf Directory lebt mit 750

Da ich die möglicherweise weitreichenden Konsequenzen der minimalen Unterschiede in beiden Wrapper Methoden nicht abschließend bewerten kann, habe ich mich für Wrapper 2 entschieden. Lieber bei den Rechten hinten eine Null.

Ist jetzt zwar kürzer als das vorherige How-To geworden, dafür aber um einiges Richtiger.

Glückauf,

Thomas
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top