Erfahrungen apache2 mit PHP 5 als FastCGI

Debian macht sich hervorragend als Web- und Mailserver. Schau auch in den " Tipps und Tricks"-Bereich.
Antworten
Benutzeravatar
beggar
Beiträge: 7
Registriert: 04.12.2006 08:32:30

Erfahrungen apache2 mit PHP 5 als FastCGI

Beitrag von beggar » 05.01.2007 00:35:43

Hallo!

Habe den Tag damit verbracht apache2 mit PHP 5 als FastCGI unter Sarge3r2 zu installieren.
Dazu habe ich dieses Howto von DebianHowTo.de benutzt. Leider funktionierte das alles nicht so wie geplant. Hier meine Anmerkungen:

Apache2
Als erstes den Apache2 als mpm-worker installiert. Das hat dann alles soweit geklappt. Ein Hinweis: Wer PHPMyAdmin benutzen möchte, sollte den mpm-prefork nehmen, da PHPMyAdmin sonst nicht funktioniert. Dazu habe ich die libapache2-mod-php als letzten Schritt drüber installiert, der den mpm-prefork enthält. FastCGI und suEXEC bleibt erhalten (soweit beobachtet)....

PHP5
Habe ich einmal selbst kompiliert und danach noch mal von dotdeb.org als Paket installiert. Vom Ergebnis tut sich das nix, läuft beides wie gewünscht.

FastCGI
Das mod_fastcgi selbst kompilieren: Kompilieren und Starten hat soweit nach Anleitung funktioniert. Leider ließ sich suEXEC auch mit viel Testen und Prüfen nicht dazu überreden, mit FastCGI zusammen zu arbeiten. Der Wrapper wollte einfach nicht.
Danach habe ich testweise das libapache2-mod-fastcgi installiert und es funktionierte sofort. Leider lassen sich bei diesem Paket nicht mehr nach dem HowTo getrennte php.ini für jeden User installieren. Habe ca. 5 Stunden versucht das hinzubiegen, aber dann hat mich die Lust verlassen. Steht noch auf meiner ToDo-Liste, wenn jemand Erfahrung mit dem libapache2-mod-fastcgi hat, bitte melden!

Konfiguration vHost
Da sich mit dem libapache2-mod-fastcgi (noch?) keine getrennten php.ini für die vHosts anlegen lassen entfällt auch der ganze Teil mit dem fcgi-starter und immutable bit.


Gruss,

beggar

Pawel
Beiträge: 284
Registriert: 27.11.2006 03:59:39

Re: Erfahrungen apache2 mit PHP 5 als FastCGI

Beitrag von Pawel » 05.01.2007 09:09:36

beggar hat geschrieben:Dazu habe ich dieses Howto von DebianHowTo.de benutzt. Leider funktionierte das alles nicht so wie geplant. Hier meine Anmerkungen:
Kein Wunder, das HowTo ist absoluter Mist. Schon dabei angefangen, dass man php5 selbst kompilieren soll bis hin zum Schluss mit dem immutable Bit. :roll:

Anstatt selbst kompilierte und veränderte Versionen von php5 und suexec2 zu nehmen, geht das alles viel einfacher mit mod_fcgid und mit Debian Paketen. Dabei sollte man eine aktuelle Version von mod_fcgid anstatt die aus dem Stable-Zweig von Debian nehmen, weil es da noch einige Bugs drin gibt.
Dann klappt das auch mit dem Wunsch, verschiedene php.ini's zu benutzen. Ich muss dich allerdings warnen, das pflegen der inis kann sehr mühselig werden. :)

Ich hab mir schon überlegt, ein eigenes HowTo dazu zu schreiben, weil man einige Sachen beachten muss, habe allerdings nie wirklich die Zeit dazu gefunden. :oops:

Benutzeravatar
beggar
Beiträge: 7
Registriert: 04.12.2006 08:32:30

Re: Erfahrungen apache2 mit PHP 5 als FastCGI

Beitrag von beggar » 05.01.2007 10:33:09

Pawel hat geschrieben:Anstatt selbst kompilierte und veränderte Versionen von php5 und suexec2 zu nehmen, geht das alles viel einfacher mit mod_fcgid und mit Debian Paketen. Dabei sollte man eine aktuelle Version von mod_fcgid anstatt die aus dem Stable-Zweig von Debian nehmen, weil es da noch einige Bugs drin gibt.
Dann klappt das auch mit dem Wunsch, verschiedene php.ini's zu benutzen. Ich muss dich allerdings warnen, das pflegen der inis kann sehr mühselig werden. :)

Ich hab mir schon überlegt, ein eigenes HowTo dazu zu schreiben, weil man einige Sachen beachten muss, habe allerdings nie wirklich die Zeit dazu gefunden. :oops:
Danke für den Tip!
Kannst Du mir evtl. Links - gerne in Englisch - oder etwas konkretere Hinweise posten? Ich muss sowieso ein aktuelles HowTo für meinen Server machen, da kann ich das hier reinstellen. Mit meiner aktuellen Lösung bin ich nicht zufrieden. Mein Ziel ist es, zumindest die php.ini und noch besser die PHP-Version nach User getrennt einzubinden. Das mit den inis bekomme ich schon hin, sind nicht so viele vHosts die ich Pflegen muss.

Das mit dem selbst kompilieren ist eine Lösung für Notfälle. Ein schönes Beispiel ist der suEXEC-Wrapper: Ich habe den nicht neu kompiliert (warum?) und es funktioniert nicht mit dem selbst installieren FastCGI. Mit dem Paket libapache2-mod-fastcgi läuft es sofort. Ich bin ja nur ein Debian-Einsteiger, doch eines habe ich schon gelernt: Bei übergreifenden Konzepten sind mir zu viele Änderungen an selbst kompilierten Quellen notwendig - wenn es überhaupt läuft.


Gruss,

beggar

Pawel
Beiträge: 284
Registriert: 27.11.2006 03:59:39

Beitrag von Pawel » 05.01.2007 14:19:21

Ich hoffe du kannst dich noch ein wenig Gedulden. Bin zur Zeit auf der Arbeit und "arbeite". ;)

Ach ja, durch die Installation von libapache2-mod-php umgehst du die Beschränkung von suexec.

Pawel
Beiträge: 284
Registriert: 27.11.2006 03:59:39

Beitrag von Pawel » 05.01.2007 16:42:21

So, das ganze fängt mit der Installtion der üblicher Verdächtigen an:
Apache:

Code: Alles auswählen

agt-get install apache2-common apache2-mpm-worker
PHP:

Code: Alles auswählen

apt-get install php4-cgi
Man kann auch php5-cgi aus dem unstable/testing Zweig von Sarge nehmen, wenn man will. Wichtig ist nur, dass es eine CGI Version ist, weil diese mit FastCGI Support erstellt wurde.

FastCGI Modul für Apache:

Code: Alles auswählen

apt-get install libapache2-mod-fcgid/testing
Es gibt noch einige Bugs in Version 1.05 (Sarge Stable), die verhindern, dass man unterschiedliche Binarys aufrufen kann.

Alle liabpache2-mod-php Module sollte man deaktivieren (oder besser löschen), weil sonst werden diese Anstatt FastCGI benutzt, was auch verhindert, dass suexec als Wrapper benutzt wird.

Als erster sollte man nach der Installation mod_fcgid und suexec aktivieren:

Code: Alles auswählen

a2enmod fcgid
a2enmod suexec
Die Konfiguration von mod_fcgid findet man unter: /etc/apache2/mods-available/fcgid.conf

Danach muss man die entsprechenden Seiten unter /etc/apache/sites-avaible/* anpassen:
Eine Beispiel konfiguration dafür sieht in etwa so aus:

Code: Alles auswählen

<Directory /var/www/htdocs>
                FCGIWrapper /var/www/conf/php-fcgi-htdocs .php
                Options ExecCGI
                AllowOverride All
                Order deny,allow
                Allow from all
</Directory>
User und Group Direktive nicht vergessen, sonst wird suexec nicht benutzt.

Ach ja, ich setze vorraus, dass unter /var/www folgende Verzeichnisstruktur besteht:
/var/www/
+ conf - Pfad mit den Konfigurationsdateien für die Sites
+ beliebiges anderes Verzeichnis - die DocumentRoot der beliebigen Sites

Dann schauen wir uns auch mal dieses mysteriöses Conf Verzeichnis an:

Code: Alles auswählen

/var/www/conf# ls -al
-r-xr-xr-x  1 wwwuser wwwuser 116 2006-06-21 12:25 php-fcgi-htdocs
-r-xr-xr-x  1 vhost-user1 wwwuser 118 2006-09-01 02:09 php-fcgi-vhost1
-r-xr-xr-x  1 vhost-user2 wwwuser 117 2006-08-18 15:13 php-fcgi-vhost2
Die Eigentümer der Datei muss immer der gleiche User sein, der auch in User und Group Direktive eingetragen wurde.

So sieht die php-fcgi-htdocs aus:

Code: Alles auswählen

#!/bin/sh
PHPRC="/etc/php4/htdocs"
export PHPRC
PHP_FCGI_CHILDREN=3
export PHP_FCGI_CHILDREN
exec /usr/bin/php4-cgi
PHPRC ist dabei das Verzeichnis, wo die php.ini drin liegt.
PHP_FCGI_CHILDREN ist die Anzahl der Kinderprozesse, die erhalten beliben sollen.
exec /usr/bin/php4-cgi bezeichnet den Interpreter.

Theoretisch war es das :)

Jetzt noch eine kleine Erklärung:

Code: Alles auswählen

/usr/lib/apache2/suexec2 -V
 -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"
Suexec erlaubt nur den Zugriff auf Dateien unter /var/www (deswegenm auch /var/www/conf).
Die mIndest User ID und Group ID für die User in der User und Group Direktive sind 100, deswegen wird es mit dem Apache2-User von Debian (www-data:33) nicht funktionieren.

Du musst einen weiteren User mit einer weiteren Group anlegen:

Code: Alles auswählen

man adduser
Ich hofe, das hilft dir ein wenig.
Deine besten Freunde bei der ganzen Sache sind:

Code: Alles auswählen

/var/log/apache2/error.log
/var/log/apache2/suexec.log

Benutzeravatar
beggar
Beiträge: 7
Registriert: 04.12.2006 08:32:30

Beitrag von beggar » 05.01.2007 22:58:26

Hallo Pawel!
Danke für deine kurze Anleitung!
Pawel hat geschrieben: FastCGI Modul für Apache:

Code: Alles auswählen

apt-get install libapache2-mod-fcgid/testing
Es gibt noch einige Bugs in Version 1.05 (Sarge Stable), die verhindern, dass man unterschiedliche Binarys aufrufen kann.
Offensichtlich ist das testing-packet nicht mehr online, die Entwickler haben es kurzfristig runter genommen. Eine andere Quelle z.B. für die sources.list habe ich nicht gefunden. Habe daher das 10.5-1 stable genommen, langt erst einmal.
Pawel hat geschrieben: Alle liabpache2-mod-php Module sollte man deaktivieren (oder besser löschen), weil sonst werden diese Anstatt FastCGI benutzt, was auch verhindert, dass suexec als Wrapper benutzt wird.
Da habe ich dann eine Frage: Wie nehme ich die raus? Mit dem Paketmanagent jedenfalls nicht, denn zu mindest bei mir ist das libapache-mod-php zum Beispiel mit apt nicht zu löschen....?
Pawel hat geschrieben: Danach muss man die entsprechenden Seiten unter /etc/apache/sites-avaible/* anpassen:
Eine Beispiel konfiguration dafür sieht in etwa so aus:

Code: Alles auswählen

<Directory /var/www/htdocs>
                FCGIWrapper /var/www/conf/php-fcgi-htdocs .php
                Options ExecCGI
                AllowOverride All
                Order deny,allow
                Allow from all
</Directory>
User und Group Direktive nicht vergessen, sonst wird suexec nicht benutzt.
Damit meinst Du dann die SuexecUserGroup Direktive, oder? Wird die wie gehabt am Anfang des VirtualHost eingetragen, oder erst bei der Directory? Kannst Du eine exemplarische vHost config reinstellen?
Pawel hat geschrieben: Ach ja, ich setze vorraus, dass unter /var/www folgende Verzeichnisstruktur besteht:
/var/www/
+ conf - Pfad mit den Konfigurationsdateien für die Sites
+ beliebiges anderes Verzeichnis - die DocumentRoot der beliebigen Sites
Nun, wer mit den normalen Paketen arbeitet, sollte doch so schlau sein und auch die empfohlenen Pfade wählen... :)
Pawel hat geschrieben: Dann schauen wir uns auch mal dieses mysteriöses Conf Verzeichnis an:

Code: Alles auswählen

/var/www/conf# ls -al
-r-xr-xr-x  1 wwwuser wwwuser 116 2006-06-21 12:25 php-fcgi-htdocs
-r-xr-xr-x  1 vhost-user1 wwwuser 118 2006-09-01 02:09 php-fcgi-vhost1
-r-xr-xr-x  1 vhost-user2 wwwuser 117 2006-08-18 15:13 php-fcgi-vhost2
Die Eigentümer der Datei muss immer der gleiche User sein, der auch in User und Group Direktive eingetragen wurde.

So sieht die php-fcgi-htdocs aus:

Code: Alles auswählen

#!/bin/sh
PHPRC="/etc/php4/htdocs"
export PHPRC
PHP_FCGI_CHILDREN=3
export PHP_FCGI_CHILDREN
exec /usr/bin/php4-cgi
PHPRC ist dabei das Verzeichnis, wo die php.ini drin liegt.
PHP_FCGI_CHILDREN ist die Anzahl der Kinderprozesse, die erhalten beliben sollen.
exec /usr/bin/php4-cgi bezeichnet den Interpreter.
Ich versuche das noch einmal mit meinen Worten wiederzugeben:
In /var/www/conf/ liegt das php-fcgi-script des vHosts. Beim Start vom Apache2 wird aus der FCGIWrapper-Anweisung der Pfad zum php-fcgi-srcipt ausgelesen. Daher sollte das Script an dem Ort sein, auf den Pfad der FCGIWrapper-Anweisung zeigt.
Das betreffende php-fcgi-script wird mit Userrechten ausgeführt. Dazu wird in der vHost config unter der Anweisung Suexec der Name und die Gruppe des Users angegeben. Die php-fcgi-script Datei muss daher auch die entsprechenden Rechte des Users und der Gruppe besitzen, sonst kann die Datei nicht ausgeführt werden.
Das php-fcgi-script enthält die Einstellungen für den vHost. Diese sind der Pfad zur php.ini, die Anzahl der Prozesse und der Pfad zur PHP-Binary.
Pawel hat geschrieben: Suexec erlaubt nur den Zugriff auf Dateien unter /var/www (deswegenm auch /var/www/conf).
Die mIndest User ID und Group ID für die User in der User und Group Direktive sind 100, deswegen wird es mit dem Apache2-User von Debian (www-data:33) nicht funktionieren.

Du musst einen weiteren User mit einer weiteren Group anlegen:

Code: Alles auswählen

man adduser
Das hört sich jetzt vielleicht etwas doof an, aber was mache ich dann mit dem neuen User? Mir ist bekannt, das die /usr/lib/suexec2 die Rechte 4755 braucht. Muss ich dem Apache den neuen User zuweisen? Im apache error.log habe ich nur einmal den "(notice) suexec wrapper enabled" hinweis, das war es dann. Der Service läuft, wenn ich eine phpinfo() aufrufe, funktioniert das auch. Leider ist der User www-data/33. SuEXEC läuft so nicht.
Pawel hat geschrieben: Ich hofe, das hilft dir ein wenig.
Vielen Dank auf jeden Fall! ist ja schon fast ein Glücksfall, das jemand was aktuelles zu dem Thema postet!
:)
Mir ist aufgefallen, das es ja kaum vernünftige Infos zu dem Thema gibt. Vielleicht ist es nicht im Trend, zu wenige Leute interessieren sich dafür? Wieder mal irritierend, das in vielen Deutschen Foren solche Sätze wie "man lesen" stehen. Es geht so viel Zeit für die Suche nach Lösungen drauf, das ist schon fast abschreckend.

Gruss,

beggar

Pawel
Beiträge: 284
Registriert: 27.11.2006 03:59:39

Beitrag von Pawel » 06.01.2007 15:39:52

beggar hat geschrieben: Offensichtlich ist das testing-packet nicht mehr online, die Entwickler haben es kurzfristig runter genommen. Eine andere Quelle z.B. für die sources.list habe ich nicht gefunden. Habe daher das 10.5-1 stable genommen, langt erst einmal.
Ah, das habe ich vergessen - absolut beginner. :)

Das folgende sollte sich mit Etch erledigt haben! Also nur Übergangsweise wichtig.

Du musst /etc/apt/sources.list um die Pakete des Testing Zweiges erweitern. So sieht meine sources.list aus, allerdings benutze ich aus Geschwindigkeitsgründen einen lokalen Mirror. :) Die zweite Zeile ist die neue, genauer gesagt das Wort "testing"

Code: Alles auswählen

deb http://localhost/debian stable main non-free contrib
deb http://localhost/debian testing main non-free contrib
deb-src http://localhost/debian stable main

deb http://security.debian.org/ stable/updates main
Jetzt weiß allerdings apt-get nicht, welchen Zweig es wählen soll. Allerdings bietet apt auch dafür eine Lösung:

Code: Alles auswählen

man apt_preferences
Im Endeffekt habe ich folgende /etc/apt/preferences

Code: Alles auswählen

Package: *
Pin: release stable
Pin-Priority: 500

Package: libapache2-mod-fcgid
Pin: release testing
Pin-Priority: 990
Danach sollte ein

Code: Alles auswählen

apt-get update
apt-get dist-upgrade
nur liapach2-mod-fcgid als upgrade vorgeschlagen werden, ansonsten habe ich ein Detail bei der Erklärung vergessen. :)

Wie bereits erwähnt, mit Etch müsste man das nicht mehr machen.
beggar hat geschrieben:
Pawel hat geschrieben: Alle liabpache2-mod-php Module sollte man deaktivieren (oder besser löschen), weil sonst werden diese Anstatt FastCGI benutzt, was auch verhindert, dass suexec als Wrapper benutzt wird.
Da habe ich dann eine Frage: Wie nehme ich die raus? Mit dem Paketmanagent jedenfalls nicht, denn zu mindest bei mir ist das libapache-mod-php zum Beispiel mit apt nicht zu löschen....?
Bei dir dürfte das libapache2-mod-php5 sein. Ich meinte das eher allgemein. Allerdings solte man es auch mit folgendem Befehl aus der Apache Konfiguration entfernen können:

Code: Alles auswählen

a2dismod php5
Wobei ich mir jetzt nicht sicher bin, ob das php5 oder irgendwie anders hieß. Deswegen reicht es auch aus, wenn man nur folgendes eintippt:

Code: Alles auswählen

a2dismod
Danach wird eine Liste aller aktivierten Module angezeigt und man kann sich das entsprechende auswählen.
beggar hat geschrieben: Damit meinst Du dann die SuexecUserGroup Direktive, oder? Wird die wie gehabt am Anfang des VirtualHost eingetragen, oder erst bei der Directory? Kannst Du eine exemplarische vHost config reinstellen?
Ja, Ja/Nein, gerne. :)

Code: Alles auswählen

NameVirtualHost *
<VirtualHost *>
        SuExecUserGroup wwwuser wwwuser

        # TRACE and TRACK are HTTP methods which are used to debug
        # web server connections. It has been shown that servers
        # supporting this method are subject to cross-site-scripting
        # attacks dubbed XST for "Cross-Site-Tracing", when
        # used in conjunction with various weaknesses in browsers.
        RewriteEngine on
        RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
        RewriteRule .* - [F]

       DocumentRoot /var/www/htdocs/
       <Directory /var/www/htdocs>
               FCGIWrapper /var/www/conf/php-fcgi-htdocs .php
               Options FollowSymLinks MultiViews +ExecCGI
               AllowOverride None
               Order allow,deny
               allow from all
       </Directory>

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/access.log combined
        ServerSignature Off
</VirtualHost>
beggar hat geschrieben:Ich versuche das noch einmal mit meinen Worten wiederzugeben:
In /var/www/conf/ liegt das php-fcgi-script des vHosts. Beim Start vom Apache2 wird aus der FCGIWrapper-Anweisung der Pfad zum php-fcgi-srcipt ausgelesen. Daher sollte das Script an dem Ort sein, auf den Pfad der FCGIWrapper-Anweisung zeigt.
Das betreffende php-fcgi-script wird mit Userrechten ausgeführt. Dazu wird in der vHost config unter der Anweisung Suexec der Name und die Gruppe des Users angegeben. Die php-fcgi-script Datei muss daher auch die entsprechenden Rechte des Users und der Gruppe besitzen, sonst kann die Datei nicht ausgeführt werden.
Das php-fcgi-script enthält die Einstellungen für den vHost. Diese sind der Pfad zur php.ini, die Anzahl der Prozesse und der Pfad zur PHP-Binary.
Bis auf eine Kleinigkeit alles richtig. Es ist nicht die Anzahl der Prozesse, sondern die Anzahl der Prozesse, die immer zur Verfügung gestellt werden sollen. Es können bei entsprechenden Last auch mehr entstehen. So, hab ich das jedenfalls verstanden.
beggar hat geschrieben:
Pawel hat geschrieben: Suexec erlaubt nur den Zugriff auf Dateien unter /var/www (deswegenm auch /var/www/conf).
Die mIndest User ID und Group ID für die User in der User und Group Direktive sind 100, deswegen wird es mit dem Apache2-User von Debian (www-data:33) nicht funktionieren.

Du musst einen weiteren User mit einer weiteren Group anlegen:

Code: Alles auswählen

man adduser
Das hört sich jetzt vielleicht etwas doof an, aber was mache ich dann mit dem neuen User? Mir ist bekannt, das die /usr/lib/suexec2 die Rechte 4755 braucht. Muss ich dem Apache den neuen User zuweisen? Im apache error.log habe ich nur einmal den "(notice) suexec wrapper enabled" hinweis, das war es dann. Der Service läuft, wenn ich eine phpinfo() aufrufe, funktioniert das auch. Leider ist der User www-data/33. SuEXEC läuft so nicht.
Das Problem an dem/der www-data User/Group ist, dass sie eine ID unterhalb von 100 hat. Deswegen kann man das nicht in der SuExecUserGroup Direktive benutzen (man erinnere sich min UID/GID 100). D.h. man braucht einen neuen User, der eine höhere User ID als 100 hat.
PHP funktioniert, weil du libapach2-mod-php hast und er das suexec umgeht.
beggar hat geschrieben:Mir ist aufgefallen, das es ja kaum vernünftige Infos zu dem Thema gibt. Vielleicht ist es nicht im Trend, zu wenige Leute interessieren sich dafür? Wieder mal irritierend, das in vielen Deutschen Foren solche Sätze wie "man lesen" stehen. Es geht so viel Zeit für die Suche nach Lösungen drauf, das ist schon fast abschreckend.
Das Problem an dem ganzem Thema ist dieses HowTo von debianhowto.de. Viele Lesen es, kommen damit aber nicht zurecht und es ist absolut gegen den "Debian Way of Live". Dann installieren sie einfach libapache2-mod-phpX oder suphp und denken, dass das doch recht einfach ging. Das hat allerdings einen Nachteil. Bei libapach2-mod-phpX ist es, dass er den mpm-prefork Worker von Apache2 benutzt und den eigentlichen Vorteil gegenüber Apache1 wieder verliert. (Forks statt Threads). Außerdem wird suexec garnicht benutzt und man vermutet sich in Sicherheit, die es nicht gibt. Als ich mich damals mit dem Thema beschäftigt habe, hatte suPHP keine Unterstützung für mod_userdir und ich hatte nicht genug Kontrolle bei den PHP Einstellungen, deswegen habe ich mich gegen suPHP entschieden und ich denke, ich fahr damit gut. :)
Zuletzt geändert von Pawel am 06.03.2007 09:50:12, insgesamt 1-mal geändert.

JoachimDurchholz
Beiträge: 2
Registriert: 15.01.2007 21:47:30

Passt... beinahe

Beitrag von JoachimDurchholz » 15.01.2007 22:56:41

Bei mir funktioniert suexec2+fcgid+php-fcgi. Sozusagen - an einem letzten Detail beiße ich mir schier die Zähne aus und weiß nicht, warum. Er besteht nämlich darauf, dass der fcgi-Wrapper immer im gleichen Verzeichnis liegt wie das PHP-Skript. Ich doktore schon seit Wochen daran rum, google wie ein Blöder und finde nix, was mir weiterhilft.

Die relevanten Dateien und Ausschnitte:

Code: Alles auswählen

# /etc/apache2/mods-available/fcgid.load
LoadModule fcgid_module /usr/lib/apache2/modules/mod_fcgid.so

Code: Alles auswählen

# /etc/apache2/sites-available/80_syscp
<VirtualHost ...>
  DocumentRoot /var/www/syscp
  SuexecUserGroup syscplokal syscplokal
  <Directory /var/www/syscp>
    # Da liegt php5-fcgid (der fcgi-Wrapper) drin.
    Options Indexes FollowSymLinks MultiViews ExecCGI
    AllowOverride None
    Order deny,allow
    Allow from all
    FCGIWrapper /var/www/syscp/php5-fcgid .php
  </Directory>
</VirtualHost>

Code: Alles auswählen

# /var/www/syscp/php5-fcgid
#!/bin/sh
PHPRC=”/etc/php5/cgi”
export PHPRC
PHP_FCGI_CHILDREN=8
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /usr/bin/php5-cgi
Wenn ich eine phpinfo.php aus dem DocumentRoot ausführe, funktioniert alles. Die Logdateien dazu sagen:

Code: Alles auswählen

# access.log
84.175.30.148 - - [15/Jan/2007:22:13:42 +0100] "GET /phpinfo.php HTTP/1.1" 200 43381
84.175.30.148 - - [15/Jan/2007:22:13:43 +0100] "GET /phpinfo.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2146
84.175.30.148 - - [15/Jan/2007:22:13:43 +0100] "GET /phpinfo.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 4644
# error.log
[Mon Jan 15 22:13:42 2007] [notice] mod_fcgid: call /var/www/syscp/phpinfo.php with wrapper /var/www/syscp/php5-fcgid
[Mon Jan 15 22:13:42 2007] [notice] mod_fcgid: server /var/www/syscp/phpinfo.php(2616) started
[Mon Jan 15 22:13:42 2007] [info] Connection to child 1 established (server itsy3.de:443, client 84.175.30.148)
[Mon Jan 15 22:13:42 2007] [info] Seeding PRNG with 136 bytes of entropy
[Mon Jan 15 22:13:43 2007] [info] Subsequent (No.2) HTTPS request received for child 0 (server itsy3.de:443)
[Mon Jan 15 22:13:43 2007] [info] Initial (No.1) HTTPS request received for child 1 (server itsy3.de:443)
# suexec.log
[2007-01-15 22:13:42]: uid: (9000/syscplokal) gid: (9000/9000) cmd: php5-fcgid
Das sieht soweit ganz gut aus. Der erste Request ist das eigentliche phpinfo, die anderen dürften die nachgeladenen Grafiken sein.
Packe ich die phpinfo.php in ein Unterverzeichnis, funktioniert zunächst alles wunderbar:

Code: Alles auswählen

84.175.30.148 - - [15/Jan/2007:22:24:19 +0100] "GET /test/phpinfo.php HTTP/1.1" 200 43451
84.175.30.148 - - [15/Jan/2007:22:24:20 +0100] "GET /test/phpinfo.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2146
84.175.30.148 - - [15/Jan/2007:22:24:20 +0100] "GET /test/phpinfo.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 4644
Die Freude ist aber nur von kurzer Dauer, denn nach einem Apache-Neustart mit /etc/init.d/apache2 restart geht gar nichts mehr:

Code: Alles auswählen

# access.log
84.175.30.148 - - [15/Jan/2007:22:33:16 +0100] "GET /test/phpinfo.php HTTP/1.1" 500 643
# error.log
[Mon Jan 15 22:33:16 2007] [info] Initial (No.1) HTTPS request received for child 0 (server itsy3.de:443)
[Mon Jan 15 22:33:16 2007] [notice] mod_fcgid: call /var/www/syscp/test/phpinfo.php with wrapper /var/www/syscp/php5-fcgid
[Mon Jan 15 22:33:16 2007] [notice] mod_fcgid: server /var/www/syscp/test/phpinfo.php(3996) started
[Mon Jan 15 22:33:16 2007] [info] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[Mon Jan 15 22:33:16 2007] [error] [client 84.175.30.148] Premature end of script headers: phpinfo.php
[Mon Jan 15 22:33:16 2007] [info] Connection to child 0 closed with standard shutdown(server itsy3.de:443, client 84.175.30.148)
# suexec.log
[2007-01-15 22:33:16]: uid: (9000/syscplokal) gid: (9000/9000) cmd: php5-fcgid
[2007-01-15 22:33:16]: cannot stat program: (php5-fcgid)
Erstaunlich ist, dass mod_fcgid offenbar genau weiß, wo der Wrapper liegt (/var/www/syscp/php5-fcgid), suexec aber offenbar nicht mehr (php5-fcgid ohne Verzeichnisangabe).

Wenn ich nun den php5-fcgid nach /var/www/syscp/test verschiebe, verweigert fcgid den Dienst, weil es php5-fcgid unter /var/www/syscp erwartet, und der Apache startet gar nicht erst.

Wenn ich es aber mit cp -a kopiere, funktioniert es erstaunlicherweise wieder:

Code: Alles auswählen

# access.log
84.175.30.148 - - [15/Jan/2007:22:41:26 +0100] "GET /test/phpinfo.php HTTP/1.1" 200 43466 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; de;
 rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9"
84.175.30.148 - - [15/Jan/2007:22:41:27 +0100] "GET /test/phpinfo.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2146 "https://
itsy3.de/test/phpinfo.php" "Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9"
84.175.30.148 - - [15/Jan/2007:22:41:27 +0100] "GET /test/phpinfo.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 4644 "https://
itsy3.de/test/phpinfo.php" "Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9"
# error.log
[Mon Jan 15 22:41:26 2007] [info] Initial (No.1) HTTPS request received for child 0 (server itsy3.de:443)
[Mon Jan 15 22:41:26 2007] [notice] mod_fcgid: call /var/www/syscp/test/phpinfo.php with wrapper /var/www/syscp/php5-fcgid
[Mon Jan 15 22:41:26 2007] [notice] mod_fcgid: server /var/www/syscp/test/phpinfo.php(4371) started
[Mon Jan 15 22:41:27 2007] [info] Connection to child 1 established (server itsy3.de:443, client 84.175.30.148)
[Mon Jan 15 22:41:27 2007] [info] Seeding PRNG with 136 bytes of entropy
[Mon Jan 15 22:41:27 2007] [info] Subsequent (No.2) HTTPS request received for child 0 (server itsy3.de:443)
[Mon Jan 15 22:41:27 2007] [info] Initial (No.1) HTTPS request received for child 1 (server itsy3.de:443)
# suexec.log
[2007-01-15 22:41:26]: uid: (9000/syscplokal) gid: (9000/9000) cmd: php5-fcgid
Ich habe da den bösen Verdacht, dass mod_fcgid vom absoluten unter FCGIWrapper angegebenen Verzeichnis ausgeht, davon aber suexec nix das, das wiederum den php5-fcgid im gleichen Verzeichnis wie das PHP-Skript sucht - aber WARUM?

Pawel
Beiträge: 284
Registriert: 27.11.2006 03:59:39

Beitrag von Pawel » 16.01.2007 15:07:37

So, nachdem ich mir das ganze ordentlich durchgelesen habe, weiß ich spontan auch nicht weiter.
Welche Version von libapach2-fcgid benutzt du?
Was passiert eigentlich, wenn du anstatt "/etc/init.d/apache2 restart" "/etc/init.d/apache2 force-reload" machst?

Meine Vermutung geht dahin, dass bei einem apache2 restart nicht die fcgid Child Prozesse mit terminiert werden.

JoachimDurchholz
Beiträge: 2
Registriert: 15.01.2007 21:47:30

Beitrag von JoachimDurchholz » 16.01.2007 20:25:36

Pawel hat geschrieben:So, nachdem ich mir das ganze ordentlich durchgelesen habe,
Respekt! ;)
Pawel hat geschrieben: weiß ich spontan auch nicht weiter.
Welche Version von libapach2-fcgid benutzt du?
Die in Ubuntu aktuelle, d.h. 1.0.7. Ist schon ein bisschen ältlich, aber ich möcht nur ungern auf Aktuelleres umsteigen - dann hab ich nicht mehr so viel von den Bemühungen des Security Teams.
Pawel hat geschrieben: Was passiert eigentlich, wenn du anstatt "/etc/init.d/apache2 restart" "/etc/init.d/apache2 force-reload" machst?

Meine Vermutung geht dahin, dass bei einem apache2 restart nicht die fcgid Child Prozesse mit terminiert werden.
Hmm... stimmt. Apache gestoppt, und pstree meldet immer noch "64*[php5-cgi]".
Macht ja auch Sinn. Das FastCGI-Protokoll lagert ja die Abarbeitung der Requests in Server aus, die außerhalb von Apache liegen; auf einer Maschine mit einer Proxy-Konfiguration (Apache+Zope z.B.) stehen die FastCGI-Server dann für alle HTTP-Server zur Verfügung. (Oder für jedes andere Programm, das das FastCGI-Protokoll beherrscht.) Also warum sollten sie sich beenden, wenn Apache endet?
Das eigentliche Problem ist wohl, dass mod-fcgid den relativen Pfad "php5-fcgid" an suExec übergibt. Das funktioniert gut, solange php5-fcgid im gleichen Verzeichnis ist wie das Skript (das wird vom Apachen ja als aktuelles Verzeichnis gesetzt), aber es geht in die Hose, sobald Wrapper und Skript eben nicht mehr im gleichen Verzeichnis sind.
Um diese Theorie zu testen, müsste man eigentlich den Wrapper in ein Verzeichnis außerhalb des DocumentRoot packen, dann dürfte gar nichts mehr funktionieren...
... testing ...
Geht gar nicht, suExec besteht ja darauf, dass der Wrapper im DocumentRoot ist.
Aber wenn ich den Wrapper in das eine und das Skript in das andere Verzeichnis packe:
Skript aufrufen, wo der Wrapper nicht ist -> Fehler 500.
Skript aufrufen, wo der Wrapper im gleichen Verzeichnis ist -> klappt.
Wieder Skript aufrufen, wo der Wrapper nichts ist -> jetzt klappt's. (Klar, der Wrapper muss nicht mehr gestartet werden, er nimmt jetzt den laufenden Prozess.)

Ich glaub, das ist ein Bug in fcgid. Ist für Debian-basierende Lösungen wohl (noch) nicht geeignet, außer man kann den Wrapper in jedes Unterverzeichnis kopieren.
Die Sache funktioniert ja heimtückischerweise auch immer, solang die Besucher mit einer URL aus der DocumentRoot anfangen. Es geht nur dann in die Hose, wenn man eine weitgehend inaktive Website hat, wo dann nach einem Tag wieder mal jemand eine Seite per Direktlink aus einem Unterverzeichnis abruft. Und dann fällt das auch nicht weiter auf, wenn das in die Hose geht - der Besucher sieht den 500er und geht halt zu einer anderen Website. Und weder der Sitebetreiber noch der Systemadmin merkt jemals etwas davon...

... oder man schreibt sich ein Skript, das jede Stunde einmal das Stammverzeichnis jedes virtuellen Hosts abruft...

Pawel
Beiträge: 284
Registriert: 27.11.2006 03:59:39

Beitrag von Pawel » 16.01.2007 23:18:07

JoachimDurchholz hat geschrieben:Die in Ubuntu aktuelle, d.h. 1.0.7. Ist schon ein bisschen ältlich, aber ich möcht nur ungern auf Aktuelleres umsteigen - dann hab ich nicht mehr so viel von den Bemühungen des Security Teams.
Naja, das hier ist nicht das UbuntuForum.de :) Darüber hinaus glaube ich kaum, dass das Security Team irgendwas in Richtung libapache2_mod_fcgid jemals gemacht hat.

Aber zurück zu deinem Problem:

Code: Alles auswählen

version 1.08 ( Jan 22nd 2006 )
...
2. Wrapper binary can be stored in a different location to the web content (like /usr/local/apache2/fcgi-bin)
(Patch from Stephen Grier, s.e.grier at qmul.ac.uk)
Quelle: http://fastcgi.coremail.cn/download.htm

Kase
Beiträge: 124
Registriert: 24.01.2005 22:15:40

Re: Erfahrungen apache2 mit PHP 5 als FastCGI

Beitrag von Kase » 23.01.2007 21:40:33

Pawel hat geschrieben: Kein Wunder, das HowTo ist absoluter Mist. Schon dabei angefangen, dass man php5 selbst kompilieren soll bis hin zum Schluss mit dem immutable Bit. :roll:
Hallo Pawel,
ich bin der Autor dieses Howtos und ich hoffe, du bist mir nicht böse, wenn ich das Howto auf deine Aussage hin etwas in Schutz nehme.

Du musst bedenken, dass das Howto in der "finalen Version" November 2004 online gegangen ist. Damals, Ende 2004 gab es leider deine ganzen aufgezählten Pakete noch nicht.

Damals hat das mod_fastcgi Paket nicht mit Apache2 funktioniert, damals gab es standardm#ßig noch nicht mal php-fcgi Pakete, und erst recht nicht von php5 :) Damals hat mod_fcgid extrem viele Kinderkrankheiten gehabt und war alles andere als Stable (first public release von mod_fcgid war mai 2004). Damals gab es sogut wie keine Dokumentation zu fastcgi+php, wenn überhaupt nur im Zusammenhang anderer Programmiersprachen.

Ich will gar nicht wissen, wie viele Server 2004/2005 nach diesem Howto installiert wurden, aber allein anhand der E-Mails, die ich deswegen bekommen habe, müssen es extrem viele sein *gggg*

Inzwischen, und da gebe ich dir Recht, müsste das Howto eigentlich vom Netz genommen werden. :)

1.
aptitude install apache2-mpm-worker php5-cgi libapache2-mod-fcgid

2. (in den vHost, in dem man php braucht)
SuexecUserGroup xxx yyy
AddHandler fcgid-script .php
FCGIWrapper /var/www/USER/php5-cgi .php

fertig :)

Wobei, das mit dem immutable Bit praktiziere ich immer noch. Das PHP-Binary, bzw der php-fcgi-starter muss nun mal dem User gehören, dem der vhost gehört, sprich er kann eventuell die Datei auch verändern. Wenn sie außerhalb seines FTP Zugangs liegt, bleiben ihm immer noch jede Menge PHP Funktionen übrig, und längst nicht alle davon sind im open_basedir gefangen (system und co). Es ist meiner Ansicht nach also auch weiterhin nützlich, dieses Bit zu setzen.

mundaun
Beiträge: 29
Registriert: 13.10.2002 11:37:24
Wohnort: CH
Kontaktdaten:

Re: Erfahrungen apache2 mit PHP 5 als FastCGI

Beitrag von mundaun » 23.01.2007 22:57:17

Hallo allerseits,
Kase hat geschrieben: 1. aptitude install apache2-mpm-worker php5-cgi libapache2-mod-fcgid

2. (in den vHost, in dem man php braucht)
SuexecUserGroup xxx yyy
AddHandler fcgid-script .php
FCGIWrapper /var/www/USER/php5-cgi .php

fertig :)
wobei das leider mit Debian Etch nicht mehr möglich sein wird, da libapache2-mod-fcgid rausgeflogen ist, und da es für PHP ebenfalls kein FCGI-Binary geben wird. Das heisst, man muss weiterhin den Umweg über inoffizielle Pakete bzw. selber Kompilieren machen. Schade...

- michael

Pawel
Beiträge: 284
Registriert: 27.11.2006 03:59:39

Re: Erfahrungen apache2 mit PHP 5 als FastCGI

Beitrag von Pawel » 24.01.2007 13:41:03

@Kase: Kannst es ruhig verteidigen, aber ob dir was hilft ... :twisted:
Kase hat geschrieben:Du musst bedenken, dass das Howto in der "finalen Version" November 2004 online gegangen ist. Damals, Ende 2004 gab es leider deine ganzen aufgezählten Pakete noch nicht.
Kein Grund PHP selbst zu kompilieren und zu deployen, sondern ein extrem guter Grund den Leuten zu zeigen, wie man deb Pakete selbst macht. Dann findet sich schneller einer, der bereit wäre das ins Debian Repository aufzunehmen und zu pflegen oder ein eigenes Repository auf zu machen.
Kase hat geschrieben:Damals hat mod_fcgid extrem viele Kinderkrankheiten gehabt und war alles andere als Stable (first public release von mod_fcgid war mai 2004). Damals gab es sogut wie keine Dokumentation zu fastcgi+php, wenn überhaupt nur im Zusammenhang anderer Programmiersprachen.
Da geb ich dir absolut Recht.
Kase hat geschrieben:Ich will gar nicht wissen, wie viele Server 2004/2005 nach diesem Howto installiert wurden, aber allein anhand der E-Mails, die ich deswegen bekommen habe, müssen es extrem viele sein *gggg*
Man könnte die Anzahl der E-Mails auch als eine Kennzahl für ein schlechtes HowTo nehmen. :P :D
Kase hat geschrieben:Wobei, das mit dem immutable Bit praktiziere ich immer noch. Das PHP-Binary, bzw der php-fcgi-starter muss nun mal dem User gehören, dem der vhost gehört, sprich er kann eventuell die Datei auch verändern. Wenn sie außerhalb seines FTP Zugangs liegt, bleiben ihm immer noch jede Menge PHP Funktionen übrig, und längst nicht alle davon sind im open_basedir gefangen (system und co). Es ist meiner Ansicht nach also auch weiterhin nützlich, dieses Bit zu setzen.
Das Problem am immutable Bit ist, dass man es nicht "kopieren" kann. D.h., nach einem Zurückspielen eines Backups muss man es neu setzen.

@mundau: Nur weil libapache2-mod-fcgid aus Etch rausgeflogen ist, heist das nicht, das es komplett rausgeflogen ist. Es ist noch im Unstable Zweig und wird sicherlich auch wieder den Weg ins Stable finden. Und ja, es gibt auch noch phpX-cgi in stable, testing und unstable. Kann ich mal die Quellen deiner Aussage erfahren? Das würde mich mal brennend interessieren.

mundaun
Beiträge: 29
Registriert: 13.10.2002 11:37:24
Wohnort: CH
Kontaktdaten:

Beitrag von mundaun » 24.01.2007 14:23:03

@Pawel: Du scheinst dich da ja bestens auszukennen! Also weisst du, ob das php5-cgi Paket mit FCGI-Unterstützung kompiliert wurde? Ich dachte eigentlich, das sei nicht so...

Zu diesem Schluss bin ich übrigens selber gekommen, nachdem ich das ChangeLog sowie einige Mails aus Debian-Devel-Release gelesen hatte. Es würde mich natürlich freuen, wenn ich damit falsch liege...

Quellen:
http://packages.qa.debian.org/liba/liba ... fcgid.html (siehe "Testing Status")
http://thread.gmane.org/gmane.linux.deb ... ocus=12708 (da seither aber trotzdem nichts mehr passiert ist denke ich, dass die Zeit dafür langsam abgelaufen ist, und für eine Wiederaufnahme in Etch keine Chance mehr besteht...)

Gruss michael

Antworten