Erfahrungen apache2 mit PHP 5 als FastCGI
Erfahrungen apache2 mit PHP 5 als FastCGI
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
Re: Erfahrungen apache2 mit PHP 5 als FastCGI
Kein Wunder, das HowTo ist absoluter Mist. Schon dabei angefangen, dass man php5 selbst kompilieren soll bis hin zum Schluss mit dem immutable Bit.beggar hat geschrieben:Dazu habe ich dieses Howto von DebianHowTo.de benutzt. Leider funktionierte das alles nicht so wie geplant. Hier meine Anmerkungen:
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.
Re: Erfahrungen apache2 mit PHP 5 als FastCGI
Danke für den Tip!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.
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
Apache:
Code: Alles auswählen
agt-get install apache2-common apache2-mpm-worker
Code: Alles auswählen
apt-get install php4-cgi
FastCGI Modul für Apache:
Code: Alles auswählen
apt-get install libapache2-mod-fcgid/testing
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
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>
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
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
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"
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
Deine besten Freunde bei der ganzen Sache sind:
Code: Alles auswählen
/var/log/apache2/error.log
/var/log/apache2/suexec.log
Danke für deine kurze Anleitung!
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: FastCGI Modul für Apache:Es gibt noch einige Bugs in Version 1.05 (Sarge Stable), die verhindern, dass man unterschiedliche Binarys aufrufen kann.Code: Alles auswählen
apt-get install libapache2-mod-fcgid/testing
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: 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.
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: Danach muss man die entsprechenden Seiten unter /etc/apache/sites-avaible/* anpassen:
Eine Beispiel konfiguration dafür sieht in etwa so aus:User und Group Direktive nicht vergessen, sonst wird suexec nicht benutzt.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>
Nun, wer mit den normalen Paketen arbeitet, sollte doch so schlau sein und auch die empfohlenen Pfade wählen...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
Ich versuche das noch einmal mit meinen Worten wiederzugeben:Pawel hat geschrieben: Dann schauen wir uns auch mal dieses mysteriöses Conf Verzeichnis an:
Die Eigentümer der Datei muss immer der gleiche User sein, der auch in User und Group Direktive eingetragen wurde.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
So sieht die php-fcgi-htdocs aus:PHPRC ist dabei das Verzeichnis, wo die php.ini drin liegt.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
PHP_FCGI_CHILDREN ist die Anzahl der Kinderprozesse, die erhalten beliben sollen.
exec /usr/bin/php4-cgi bezeichnet den Interpreter.
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.
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: 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
Vielen Dank auf jeden Fall! ist ja schon fast ein Glücksfall, das jemand was aktuelles zu dem Thema postet!Pawel hat geschrieben: Ich hofe, das hilft dir ein wenig.
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
Ah, das habe ich vergessen - absolut beginner.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.
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
Code: Alles auswählen
man apt_preferences
Code: Alles auswählen
Package: *
Pin: release stable
Pin-Priority: 500
Package: libapache2-mod-fcgid
Pin: release testing
Pin-Priority: 990
Code: Alles auswählen
apt-get update
apt-get dist-upgrade
Wie bereits erwähnt, mit Etch müsste man das nicht mehr machen.
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:beggar hat geschrieben: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: 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.
Code: Alles auswählen
a2dismod php5
Code: Alles auswählen
a2dismod
Ja, Ja/Nein, gerne.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?
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>
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: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.
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.beggar hat geschrieben: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: 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
PHP funktioniert, weil du libapach2-mod-php hast und er das suexec umgeht.
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.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.
-
- Beiträge: 2
- Registriert: 15.01.2007 21:47:30
Passt... beinahe
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
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
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
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)
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
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.
-
- Beiträge: 2
- Registriert: 15.01.2007 21:47:30
Respekt!Pawel hat geschrieben:So, nachdem ich mir das ganze ordentlich durchgelesen habe,
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: weiß ich spontan auch nicht weiter.
Welche Version von libapach2-fcgid benutzt du?
Hmm... stimmt. Apache gestoppt, und pstree meldet immer noch "64*[php5-cgi]".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.
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...
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.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.
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)
Re: Erfahrungen apache2 mit PHP 5 als FastCGI
Hallo Pawel,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.
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.
Re: Erfahrungen apache2 mit PHP 5 als FastCGI
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...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
- michael
Re: Erfahrungen apache2 mit PHP 5 als FastCGI
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: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.
Da geb ich dir absolut Recht.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.
Man könnte die Anzahl der E-Mails auch als eine Kennzahl für ein schlechtes HowTo nehmen.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*
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.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.
@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.
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
- rolo
- Beiträge: 2697
- Registriert: 29.08.2002 12:12:25
- Lizenz eigener Beiträge: neue BSD Lizenz
- Wohnort: hannover
Code: Alles auswählen
php5-cgi -i | grep FastCGI
<tr><td class="e">Server API </td><td class="v">CGI/FastCGI </td></tr>
Re: Erfahrungen apache2 mit PHP 5 als FastCGI
mundaun hat geschrieben: 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...
Code: Alles auswählen
cd ~
mkdir fcgid
cd fcgid
echo "deb-src http://ftp.de.debian.org/debian/ unstable main" >> /etc/apt/sources.list
echo "APT::Default-Release "testing";" >> /etc/apt/apt.conf.d/70debconf
apt-get update
apt-get -t unstable source libapache2-mod-fcgid
cd libapache2-mod-fcgid-2.0
dpkg-checkbuilddeps
dpkg-buildpackage
cd ..
dpkg -i libapache2-mod-fcgid_2.0-1_i386.deb
Ein php-fcgi Binary gibt es, denn die fastcgi Unterstützung ist im normalen CGI Binary schon mit drin, also einfach das CGI installieren.
@Pawel:
Das mit den Emails kann man so oder so sehen *ggg* Vieles waren aber auch einfach nur "Danke" Mails
Mit dem Kopieren beim immutable Bit hast du natürlich recht, ist sehr unschön, aber was macht man nicht alles für die Sicherheit
sehr schöne Anleitung hier.
Ich hab das nun alles so eingerichtet aber leider parst er die php Dateien nicht sondern bietet sie zum downloaden an.
Ich nutze Debian Etch.
virualhost:
Code: Alles auswählen
NameVirtualHost *
<VirtualHost *>
SuExecUserGroup wwwbenutzer wwwbenutzer
ServerName waleb.net
ServerAlias www.waleb.net
DocumentRoot /var/www/waleb.net/
<Directory /var/www/waleb.net>
FCGIWrapper /var/www/conf/php-fcgi-waleb.net .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>
/var/www/conf/php-fcgi-waleb.net
Code: Alles auswählen
#!/bin/sh
PHPRC="/etc/php5/cgi"
export PHPRC
PHP_FCGI_CHILDREN=3
export PHP_FCGI_CHILDREN
exec /usr/bin/php5-cgi
Grüße
- rolo
- Beiträge: 2697
- Registriert: 29.08.2002 12:12:25
- Lizenz eigener Beiträge: neue BSD Lizenz
- Wohnort: hannover
Code: Alles auswählen
DocumentRoot /var/www/waleb.net/
<Directory /var/www/waleb.net>
...
FCGIWrapper /var/www/conf/php-fcgi-waleb.net .php
Code: Alles auswählen
/var/www/conf/waleb.net
dafür musst du dann natürlich auch DocumentRoot und Directory anpassen.
in der /var/www/conf/php-fcgi-waleb.net muss PHPRC der komplette pfad zu deiner php.ini sein. also statt
Code: Alles auswählen
PHPRC="/etc/php5/cgi"
Code: Alles auswählen
PHPRC="/etc/php5/cgi/php.ini"
Den Pfad zur php.ini habe ich nun auch komplettiert aber nach einen restart hat nicht nichts gebessert:
http://waleb.net/w.php
- rolo
- Beiträge: 2697
- Registriert: 29.08.2002 12:12:25
- Lizenz eigener Beiträge: neue BSD Lizenz
- Wohnort: hannover
Code: Alles auswählen
DocumentRoot ....
AddHandler fcgid-script .php
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
/var/log/apache2/suexec.log
[2007-02-24 15:44:45]: uid: (1001/wwwbenutzer) gid: (1001/1001) cmd: php-fcgi-waleb.net
[2007-02-24 15:44:45]: target uid/gid (1001/1001) mismatch with directory (0/0) or program (0/0)
- rolo
- Beiträge: 2697
- Registriert: 29.08.2002 12:12:25
- Lizenz eigener Beiträge: neue BSD Lizenz
- Wohnort: hannover
Code: Alles auswählen
mismatch with directory
Code: Alles auswählen
waleb:/var/www# ls -l -R
.:
total 16
drwxr-xr-x 2 wwwbenutzer wwwbenutzer 4096 2007-02-24 14:32 conf
-rw-r--r-- 1 root root 21 2007-02-24 13:40 index.php
-rw-r--r-- 1 wwwbenutzer wwwbenutzer 122 2007-02-24 15:12 php-fcgi-waleb.net
drwxr-xr-x 2 waleb waleb 4096 2007-02-24 15:41 waleb.net
./conf:
total 8
-rw-r--r-- 1 wwwbenutzer wwwbenutzer 114 2007-02-24 13:12 php-fcgi-htdocs
-rw-r--r-- 1 wwwbenutzer wwwbenutzer 114 2007-02-24 13:14 php-fcgi-waleb.net
./waleb.net:
total 16
-rw-r--r-- 1 waleb waleb 669 2007-02-24 15:41 favicon.ico
-rw-r--r-- 1 waleb waleb 4 2007-02-24 13:38 index.html
-rw-r--r-- 1 waleb waleb 26 2007-02-24 13:54 index.php
-rw-r--r-- 1 waleb waleb 21 2007-02-24 13:55 w.php