Debian Sarge, Apache2, Suexec2, mod_fastcgi, php5-fcgi HowTo

[kase]

Das Howto gibt es nun bei Debianhowto.de, wo es in einem wesentlich lesbareren und übersichtlicheren Format "untergebracht" wurde.

Natürlich ist hier weiterhin Platz für eure Comments und Anregungen...

http://www.debianhowto.de/howtos/de/apa ... sarge.html

[kase]

Apache 2 und PHP auf die neusten Versionen upgedated...

Apache 2.0.52, PHP 5.0.2

Ein Upgrade von Apache 2 sollte automatisch per apt-get update && apt-get upgrade durchgeführt werden, PHP 5 muss in der neusten Version von Hand neukompiliert werden, siehe dazu Schritt 3, sollte aber kaum länger als ein paar Minuten dauern...

[alexander newald]

Hi,

ich habe zugegebenerweise nicht das ganze Posting durchgelesen, aber:

Hebelst du nicht mit dem auskommentieren des Codeblocks in suexec.c die Abfrage über die Dateizugehörigkeit aus???

[kase]

Ja, genau dies wird gemacht...

Aber die Datei, die suexec ausführt, ist ja nicht, wie normal, die PHP Datei, sondern unser Starter-Script, dieses aus Sicherheitsgründen unbedingt root-root haben muss.

Das "selbstgemachte" suexec Binary darf NUR NOCH für php-fcgi benutzt werden, für nichts anderes, deshalb auch der veränderte Name zu suexec-fcgi.

Allerdings sollte dies trotzdem keine Probleme machen, da das "alte" unveränderte suexec Binary ja immer noch uneingeschränkt benutzt werden kann.

PS: Vielleicht solltest du dir nochmal meine Kommentare zu der Auskommentierung durchlesen, dort habe ich genau beschrieben, warum dies so gemacht werden muss.

[mkr]

Wenn ich das richtig verstanden habe, werden bei dieser Methode nur PHP-Scripts unter einem anderen User ausgeführt, alle anderen CGI-Scripts immer noch unter dem Apache-User.

Kann mir jemand eine Möglichkeit empfehlen, alle Scripts eines vHosts unter dem jeweiligen Benutzer ausführen zu lassen? Käme evtl. Metux dafür in Frage?

Vielen Dank für Eure Vorschläge.

[tomek]

Sehr interessante Möglichkeit und schönes HowTo.

Mich würde dazu interessieren, ob der PHP-Beschleuniger Turck MMCache damit weiterhin funktioniert. Hat das jemand schon mal zusammen probiert?

[wirsing]

Ebenfalls zu Punkt 6 und der Dateizugehörigkeit: Wie wäre es, statt die Datei root zu übereignen, mit chattr das "i"-Attribut (immutable) zu setzen. Das erspart die Kompilation eines eigenen suExec, allerdings muss der php-fcgi-starter für jeden Benutzer existieren und dieses Bit gesetzt haben.
Ansonsten: Soweit ich es schon beurteilen kann, ein gutes Howto zu einer Sache um die ich mir schon Gedanken gemacht habe.

[kase]

Wenn ich das richtig verstanden habe, werden bei dieser Methode nur PHP-Scripts unter einem anderen User ausgeführt, alle anderen CGI-Scripts immer noch unter dem Apache-User.

Kann mir jemand eine Möglichkeit empfehlen, alle Scripts eines vHosts unter dem jeweiligen Benutzer ausführen zu lassen? Käme evtl. Metux dafür in Frage?

Vielen Dank für Eure Vorschläge.

Ja, das ist richtig, das ganze funktioniert nur mit einem PHP only Server. Ich vermute, dass mit ein paar leichten Veränderungen das ganze auch zusammen mit cgi funktionieren würde, aber da kenne ich mich leider nicht gut genug aus, da ich keine cgis benutze.

Sehr interessante Möglichkeit und schönes HowTo.

Mich würde dazu interessieren, ob der PHP-Beschleuniger Turck MMCache damit weiterhin funktioniert. Hat das jemand schon mal zusammen probiert?

Kann ich dir nicht genau sagen... Wenn man dazu die mm-Erweiterung in PHP aktivieren muss, sieht es (glaube ich) schlecht aus, weil ich damit gravierende Probleme hatte, bis ich sie deaktiviert habe.

Ebenfalls zu Punkt 6 und der Dateizugehörigkeit: Wie wäre es, statt die Datei root zu übereignen, mit chattr das "i"-Attribut (immutable) zu setzen. Das erspart die Kompilation eines eigenen suExec, allerdings muss der php-fcgi-starter für jeden Benutzer existieren und dieses Bit gesetzt haben.
Ansonsten: Soweit ich es schon beurteilen kann, ein gutes Howto zu einer Sache um die ich mir schon Gedanken gemacht habe.

Was genau ist dieses Attribut? Habe davon bisher noch nichts gehört... Werde aber sowie ich etwas Zeit habe, mal Google befragen. Das Problem ist, das PHP-FCGI-Starter-Script darf auf keinen Fall von dem Web-user oder einem anderen User editierbar sein, was ja IMHO nur bei root:root garantiert werden kann.

Edit: Ã?brigens verweigert suexec ja nicht nur bei root:root sondern auch bei einem anderen User != dem User, der die Datei ausführt, den Dienst, dh, es muss auf jeden Fall dem User gehören, der das Script ausführt, aber trotzdem darf der User es nicht editieren können. (chmod -w reicht leider nicht....)

[captaincrunch]

Was genau ist dieses Attribut? Habe davon bisher noch nichts gehört...

man chattr

-> Such nach "immutable"

[kase]

Habe es bereits gefunden in der man...

Theoretisch könnte das gehen, müsste prüfen, ob da suexec nicht meckert, wenn +i gesetzt ist. Außerdem müsste man herausfinden, wie es mit Kompatibilitäten aussieht, mit wie vielen und welchen File-Systems funktioniert das +i Attribut, ist das vielleicht sogar EXTX only, oder kann es sein, dass man Kernel-Funktionen dafür nicht aktiviert hat... usw...

[kase]

Das ganze scheint zu funktionieren...

Mit dem +i Bit ist die File absolut "isoliert" und unveränderbar, und suexec (unverändert) meckert auch nicht mehr.

Müsste noch das Kompatibilitäts-Problem geklärt werden, dann könnte ich das HowTo umschreiben...

[kase]

HowTo entsprechend nach Wirsings Vorschlägen verändert.

Besten Dank für die sehr guten Tipps, die alles wieder etwas "einfacher" machen.

[kenzo]

Ich habe nun mehrere vhosts nach diesem Howto laufen, und die Performance könnte eigentlich nicht besser sein. Jedoch treten sporadisch Probleme auf, die ich nicht reproduzieren/erklären könnte. Seitenabrufe eines vhosts werden langsam, in den Logs taucht zu diesen Zeitpunkten

Code: Select all

"FastCGI: scheduled the start of the last (dynamic) server "/var/www/php-fcgi-scripts/xyz/php-fcgi-starter" process: reached dynamicMaxClassProcs (10)"

auf. Erst ein restart des Apachen behebt das Problem, das sich aber irgendwann wieder einstellt. Hat sonst jemand dieses Verhalten bereits entdeckt? Die fastcgi-Liste schweigt zu diesem Thema.

[kase]

http://www.fastcgi.com/mod_fastcgi/docs ... stcgi.html

Code: Select all

 -maxClassProcesses n (10)
    The maximum number of dynamic FastCGI application instances allowed to run for any one FastCGI application. It must be <= to -maxProcesses (this is not programmatically enforced).

 -maxProcesses n (50)
    The maximum total number of dynamic FastCGI application instances allowed to run at any one time. It must be >= to -maxClassProcesses (this is not programmatically enforced).

Allerdings hilft oftmals die PHP_FCGI_CHILDREN hochzusetzen, da, wenn mehr Prozesse benötigt werden, als vorhanden sind, fastcgi viel mehr Prozesse spawnt, als es wirklich braucht, meistens sogar bis an die Limits. (dann kommt dieser Fehler)

Versuche deshalb den PHP_FCGI_CHILDREN wert höher zu setzen, bei sehr stark besuchten PHP-Sites sollte der Start-Wert bei mindestens 20-30 sein. Am besten einfach etwas rumprobieren, optimal ist es, einen Wert zu finden, wo selbst zu Stosszeiten die Start-Prozesse ausreichen, aber es trotzdem nicht extrem viel mehr sind, als benötigt werden.

Probier als Startwert einfach mal 30, dann sollte es keine Probleme mehr geben.

PHP_FCGI_CHILDREN=30

Edit: Welchen Startwert benutzt du momentan?

Edit2: Es ist wie gesagt wichtig, dass man einen guten Start-Wert wählt, da fastcgi mit selber spawnen nicht 100% zurecht kommt. Du findest den Startwert der php-fcgi-prozesse so heraus, dieser sollte sich auch nach Tagen nicht verändern, dh fastcgi darf keine Prozesse von alleine spawnen.

Code: Select all

ps aux | grep php-fcgi | grep VHOST_USER | wc -l

Edit3: Der Startwert weicht meistens so um 1-3 Prozesse von dem ps aux Wert ab, dies ist aber normal, da es auch "Controller-Prozesse" gibt, die in dem Start-Wert nicht mit drin sind.

[kenzo]

Edit: Welchen Startwert benutzt du momentan?

Ich wollte erstmal klein anfangen (mit 2) - habe jetzt 10 gewählt, da auf den gewählten Präsenzen z.Zt. nicht allzu viel los ist. Vielleicht ist das ein guter Mittelwert, ich werde das mal beobachten.

Edit2: Es ist wie gesagt wichtig, dass man einen guten Start-Wert wählt, da fastcgi mit selber spawnen nicht 100% zurecht kommt.

Das scheint so - dumm ist nur, dass ich das an keiner äußeren Größe festmachen kann. Egal, wieviel Last ich erzeuge, das Verhalten läßt sich nicht reproduzieren. Bleibt nur, weiter ein Auge drauf zu haben.

Edit3: Der Startwert weicht meistens so um 1-3 Prozesse von dem ps aux Wert ab

Paßt - es sind jetzt durchgehend 11 Prozesse/vhost.
Edit1: Nicht immer - habe jetzt festgestellt, dass bei einem vhost pro Seitenaufruf 1 parent mit 10 children gespwant wurden - da kam dann einiges zusammen, und die Performance bricht ein. Nach manuellem killen aller zugehörigen Prozesse wurden dann wieder, wie gewollt, 11 Prozesse gestartet und dabei ist es (bisher) auch geblieben. Der besagte vhost hat exakt die gleiche Konfiguration wie die anderen - das Problem ist aber vorhin auch schon bei anderen aufgetreten, hat mit einem speziellen also nichts zu tun.

Edit2: Okay, das Problem scheint gelöst - FYI:
- Wenn man php-Seiten mit vielen Datenbankabfragen betreibt, sollte man beim Erhöhen von PHP_FCGI_CHILDREN ebenfalls an "max_connections" von mysql denken. Es sieht so aus, als würde fastcgi bei erfolglosem Request an mysql (der durch die hohe Anzahl der bereits vorhandenen php-Instanzen bedingt ist) sinnfrei Prozesse nachspawnen und damit das Problem noch verschlimmern. Damit steigt die Anzahl der php-Prozesse ins Unermessliche -> mysql-Connections dito -> nichts geht mehr.
Durch eine maßvolle Relation von PHP_FCGI_CHILDREN sowie "max_connections" scheint hier nun wieder alles friedlich zu laufen.
Falls jemand noch einen anderen offensichtlichen Denkfehler findet - her mit Anregungen für mich ... ;)

Edit3: Falls es noch jemandem so gehen sollte - das Setzen von PHP_FCGI_CHILDREN hat hier feste Probleme gemacht. Ohne rennt es höchst performant und problemlos. Infos zu meinem Problem gibt es auch hier: http://thread.gmane.org/gmane.comp.web. ... .devel/704

[sebbus]

Hallo,

leider komme ich nicht zu gewünschten Erfolg.

/var/log/apache2/error.log sagt alle 4 Sekunden, dass der Prozess beendet wurde und startet ihn wieder neu.

Code: Select all

[Mon Nov 15 18:24:28 2004] [warn] FastCGI: server "/var/www/php-fcgi-scripts/syscp/php-fcgi-starter" (pid 26456) terminated by calling exit with status '0'
[Mon Nov 15 18:24:33 2004] [warn] FastCGI: server "/var/www/php-fcgi-scripts/syscp/php-fcgi-starter" (uid 1003, gid 1003) restarted (pid 26457)
Content-type: text/html
X-Powered-By: PHP/4.3.9

jemand eine Ahnung, was da genau schief läuft? Hab nochmal alles durchgesehen, aber leider keine Auffälligkeiten gesehen.

Seiten werden nicht geparst, sondern es kommt nach einiger Wartezeit ein 500 Internal Server Error. Is ja auch klar, wenn PHP nicht richtig "geladen" wird..

MfG, Sebastian

[edit]
Was mir grade noch einfällt: beim Aufruf von

Code: Select all

./php -v 

hatte sich PHP nicht wie im Howto mit (cgi-fcgi) gemeldet, sondern nur mit (cgi). Habe beim configure aber wie für php4 vorgeschlagen --with-fastcgi und nicht --enable-fastcgi angegeben, es sollte also eigentlich mit eingebunden sein.
[/edit]

[kase]

Schaue mal bitte in die /var/log/apache2/suexec.log, dort können weitere sehr hilfreiche Informationen stehen.

Außerdem habe ich gerade gesehen, dass bei php4 es inzwischen scheinbar auch --enable-fastcgi heißt, es wurde wohl an php5 angeglichen.

TODO:
-suexec.log schauen, ob dort irgendwelche Errors auftauchen
-php4 neu kompilieren, und im configure von --with-fastcgi auf --enable-fastcgi umstellen
-make clean nicht vergessen vor dem make && make install
-im Configure sollte ziemlich am Anfang was von "Running FastCGI checks" stehen
-./php -v sollte cgi-fcgi ausgeben

Ansonsten bitte nicht aufgeben, ich stehe sooft es zeitlich geht als Support zur Seite.

[sebbus]

Hallo kase,

danke, dein Tipp, doch mal --enable-fastcgi zu probieren, hat geklappt. php4 meldet sich mit php-fcgi und auch die Prozesse beenden sich nicht sofort wieder :)

Werd dann morgen mal meine Homepage drauf loslassen und mal sehen, wie gut sich das System macht.

Danke für die schnelle Hilfe.

Sebastian

[cybermage]

ich warte gerade begierig darauf, dass mein neuer server endlich eingerichtet is, um das zu testen. wird kein debian, aber wo bleibt denn sonst die herausforderung ;)

[kase]

Ich bin für jede "Meldung" über eine erfolgreiche Einrichtung nach diesem howTo sehr dankbar. Gerade wenn es in Bezug von anderen Systemen ist, sprich php4 anstatt php5, Suse statt Debian, usw.

Außerdem will ich hier im Post nochmals deutlich schreiben, dass wer Probleme mit PHP_FCGI_CHILDREN hat, und keinen guten bzw pasenden Wert findet, die Option PHP_FCGI_CHILDREN einfach komplett aus seinem php-fcgi-starter-Script rauslässt. PHP regelt dann das Prozess-Management komplett von alleine.

Danke für den Tipp an kenzo.

[gleitz]

Ich bin für jede "Meldung" über eine erfolgreiche Einrichtung nach diesem howTo sehr dankbar. Gerade wenn es in Bezug von anderen Systemen ist, sprich php4 anstatt php5, Suse statt Debian, usw.

Ich teste das ganze mal die Woche lokal auf einer Suse 9.0 und php4.
Wird ca. 1 Woche dauern bis ich berichten kann.
Funktioniert alles einwandfrei, setze ich das auch mal auf einem schwach frequentierten Server ein.

[kase]

Freue mich wie gesagt immer über Rückmeldungen, vor allem auf sehr stark belasteten Systemen...

[cybermage]

ich versuch das ganze gerade auf meinem gentoo testsystem aufzusetzen.
php-cgi ist dort standardmäßig mit fcgi compiliert und mod_fastcgi gibt es auch als fertig geschnürtes paket.

ich hab soweit alles so gemacht wie du auch, denk ich jedenfalls *g*, bis auf das immutable. kommt noch wenn mein reiserfs endlich die attribute beachtet
allerdings bringt mir ein /etc/init.d/apache2 start folgenden fehler:

Syntax error on line 9 of /usr/lib/apache2/conf/modules.d/20_mod_fastcgi.conf:
FastCgiWrapper: "/usr/sbin/suexec2" execute access for server (uid -1, gid -1) failed: execute not allowed

Code: Select all

<IfDefine FASTCGI>
        <IfModule !mod_fastcgi.c>
                LoadModule fastcgi_module     extramodules/mod_fastcgi.so
        </IfModule>

        <IfModule mod_fastcgi.c>
                AddHandler fastcgi-script .fcg

                FastCgiWrapper /usr/sbin/suexec2
                FastCgiServer /var/www/php-fcgi-scripts/nibbler/php-fcgi-starter -user benjamin -group users
                AddHandler php-fastcgi .php

                <Location /cgi-bin/php-fcgi-starter>
                        SetHandler fastcgi-script
                        Options +ExecCGI
                </Location>

                Action php-fastcgi /cgi-bin/php-fcgi-starter
                AddType application/x-httpd-php .php
        </IfModule>
</IfDefine>

Code: Select all

NameVirtualHost 80.190.251.79

<VirtualHost 80.190.251.79:80>
        ServerName nibbler.hirnstrudel.de
        DocumentRoot /var/www/nibbler/nibbler.hirnstrudel.de
        SuexecUserGroup benjamin users

        <Directory /var/www/nibbler>
                Options FollowSymLinks
                Order allow,deny
                Allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /var/www/php-fcgi-scripts/nibbler/
        <Directory /var/www/php-fcgi-scripts/nibbler>
                AllowOverride None
                Options +ExecCGI -MultiViews -Indexes
                Order allow,deny
                Allow from all
        </Directory>

        CustomLog /var/log/apache2/access_log combined
        ErrorLog /var/log/apache2/error_log
        LogLevel warn

        ServerSignature On
</VirtualHost>

Code: Select all

-rwxr-xr-x  1 benjamin users 120 Nov 30 23:12 /var/www/php-fcgi-scripts/nibbler/php-fcgi-starter

Code: Select all

#!/bin/sh
PHPRC="/var/www/nibbler/conf"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /usr/bin/php-cgi

irgendwelche vorschläge?

[kase]

Poste mal die Ausgabe von:

Code: Select all

ls -l /usr/sbin/suexec2

/usr/sbin/suexec2 -V

[cybermage]

Code: Select all

-rws--x---  1 root apache 10808 Nov 25 20:54 /usr/sbin/suexec2

Code: Select all

 -D AP_DOC_ROOT="/var/www"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="apache"
 -D AP_LOG_EXEC="/var/log/apache2/suexec_log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_SUEXEC_UMASK=077
 -D AP_UID_MIN=1000
 -D AP_USERDIR_SUFFIX="public_html"