fastcgi

Auf der Suche nach Dokumentation zu diesem Thema landet man recht schnell beim
debianhowto.de HOWTO für apache2 mit PHP 4/5 als FastCGI. Mit den Jungs von Debianhowto bin ich ja in der Vergangenheit schon einmal aneinander geraten, aber im Vergleich zu diesem Machwerk ist das exim4-vexim-HOWTO gerade noch harmlos.

Das HOWTO ist ein reines HOWTO im “übelsten” Sinne: Es wird mit kaum einem Wort erklärt, was die 1:1 abtippbaren Dinge überhaupt machen. Damit mag man vielleicht schnell ans Ziel kommen, aber sobald man aus irgend welchen Gründen vom Weg des HOWTO abweichen muss, wird man mangels Hintergrundwissen auf die Schnauze fallen. Einige Fallen sind zwar im HOWTO erwähnt, aber ich finde es sportlich, dass man davon ausgeht, dass jeder, der jemals in Zukunft mit dem so eingerichteten System arbeiten wird, auch mit dem HOWTO vertraut ist.

Vorteile von PHP per FastCGI:

• PHP mit FastCGI ist thread safe, das apache2 worker-mpm wird einsetzbar.
• Dadurch, dass - wie bei mod_php - der PHP-Interpreter geladen bleibt, ist die Performanz besser als bei suexec oder suphp, wo der PHP-Interpeter als CGI läuft und für jeden Aufruf neu geladen und initialisiert werden muss. Bei FastCGI erfolgt dies allerdings nicht auf einer per-Webserver, sondern auf einer per-Vhost-Basis, so dass die geladenen Interpreter mit den richtigen Benutzerrechten laufen können.

Nachteile

• mod_fastcgi steht unter einer seltsamen Lizenz, die im Debian-Projekt unter non-free geführt wird. Das bedeutet, dass es für mod_fastcgi nicht den aus Debian gewöhnten guten Support gibt.
• Der Benutzerkontextwechsel wird mit mod_suexec erreicht und hat somit alle Nachteile, die suexec mit sich bringt.
• mod_fastcgi ist in der Version 2.4.2 (Debian stable, testing, unstable, Stand 2005/12) fehlerhaft und funktioniert nicht mit apache. Es ist also derzeit der Einsatz eines Development-Snapshots notwendig. Wirklich maintained sieht mod_fastcgi ausserdem nicht aus, der letzte Release ist aus dem Jahr 2003, der “aktuelle” Development-Snapshot aus dem April 2004.

Probleme, die ich mit dem HOWTO sehe

• Die Zusammenhänge werden so gut wie gar nicht erklärt.
• Ebenso wird nicht erklärt, was die einzelnen Konfigurationsschritte nun wirklich tun.
• Es wird genau erklärt, wie man sich ein eigenes PHP5 baut, ohne dass darauf hingewiesen wird, dass man auf diese Weise den Support von Debian verliert. Immerhin wird der User dazu angehalten, sein lokales PHP nach $HOME zu installieren, und bei der Anleitung zur Installation der inoffiziellen PHP5-Pakete fehlt auch der Hinweis auf den mangelnden Security-Support nicht.
• Die Aussage, dass es kein fcgi-enabletes php4-cgi in Debian sarge gibt, halte ich für falsch. Zumindest erhalte ich beim Aufruf von php4-cgi -i auf einem Debian sarge die Ausgabe “ServerAPI: CGI/FastCGI”.
• Der “aktuelle” Development-Snapshot wird von den HOWTO-Usern ohne Sonderprefix unter Umgehung des Packagesystems direkt nach /usr geballert.
• Weiter unten wird erwähnt, dass es in Debian sarge ein libapache2-mod-fastcgi gibt. Das ist allerdings genau die fehlerhafte Version 2.4.2, die laut der Aussage zwei Bildschirmseiten weiter oben “nicht funktioniert”, leider ohne weitere Erklärung des Fehlverhaltens.
• Von a2enmod und a2ensite scheint der HOWTO-Autor nix zu wissen
• Später wird mit dem Immuteable-Bit hantiert, und hier wird’s dann vollends gefährlich.
  • Arbeitet man auf einem Filesystem, das das Immuteable-Bit unterstützt, ist die Aktion noch halbwegs sauber.
  • Böse Falle für Leute, die später das System in die Hand bekommen ist, dass Kopieren des Dateibaums des virtuellen Hosts das Immuteable-Bit nicht mitkopiert. Sprich: In einem simpel mit cp -a kopierten Baum fehler dieses Bit auf den betroffenen Dateien, was ein riesengroßes Sicherheitsloch aufreißt. Das ist zwar im HOWTO klar erklärt, aber wie gesagt - derjenige, der den Dateibaum kopiert, muss nicht notwendigerweise das HOWTO gelesen oder gar verstanden haben.
  • Für Filesysteme, die das immuteable-Bit nicht unterstützen, legt das HOWTO dem Benutzer nahe, suexec zu patchen, und liefert eine idiotensichere Anleitung mit, wie das getan werden kann. Dabei werden zwar die Debian-Sourcen verwendet, aber das entstehende Binary wird natürlich wieder manuell an die passende Stelle im Dateisystem geschoben - erneut unter Umgehung des Packagesystems. Ich möchte kein System in die Finger bekommen, das auf diese Weise so verhunzt wurde. Übel. Immerhin - das neu gebaute, unsicherere suexec wird nicht benutzt um das “Original-suexec” zu überschreiben, sondern erhält einen eigenen Dateinamen, suexec-fcgi, was den Knieschusseffekt dieser Operation wenigstens etwas dämpft.
• Ich würde mich wundern, wenn die Verwendung von Documentroots ausserhalb /var/www für die Benutzer dieses HOWTOs funktioniert. Das Debian-suexec ist relativ strikt übersetzt, und dieser Fall ist im HOWTO mit keinem Wort erwähnt. Für Newbies - mithin die Hauptzielgruppe des HOWTO - ist das eine böse Falle.

Bitte, bitte, bitte. Lest Eure Texte bevor ihr sie veröffentlicht. Schreibt kurze, prägnante Sätze, vermeidet Umgangssprache, schreibt Zahlen zwischen eins und zwölf als Worte. Technische Dokumentation verdient besseres Deutsch!

Fazit: Debianhowto.de ist in meiner Achtung wieder ein Stück gesunken, die von mir erhoffte Standardlösung für ein Standardproblem habe ich immer noch nicht gefunden.

Demnächst in diesem Theater: Für jede PHP-Applikation einen eigenen Apache.