Skip to content

fastcgi

In Fortsetzung der Artikelreihe zur Entfernung von PHP-Scripts aus dem Accountkontext des Webservers ist heute FastCGI an der Reihe.

Kurzzusammenfassung aus der Theorie: Es ist vermutlich performanter als suexec und suphp, bringt aber weder Erleichterung in der Handhabung noch in der Sicherheit.

In diesem Artikel bekommt auch das debianhowto.de apache2-php-fcgi-HOWTO sein Fett weg.

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.

Trackbacks

Zugschlusbeobachtungen on : Trennung von Webapplikationen mit Extrainstanzen des Apache

Show preview
Die Artikelreihe zum Thema “Trennung von Webanwendungen untereinander”, die mit fastcgi, suphp und zwei Artikeln über das klassische suexec begann, findet heute ihren\nvorläufigen Abschluss mit dem Setup, für das ich mich letztendlich ents

AK's weblog on : PHP5, Apache2 und FastCGI

Show preview
Meinen Rootserver plagten seit ein paar Wochen immer wieder Probleme. Teilweise musste ich mehrmals täglich den Apache neu starten, weil dieser eine Unmenge an neuen Prozessen gespawned hatte, und die Last auf 30 bis 50 angestiegen war. Meine Vermutung wa

blog.zugschlus.de on : PingBack

Unfortunately, the contents of this trackback can not be displayed.

Comments

Display comments as Linear | Threaded

-thh on :

Naja, Howto eben - Stück für Stück, Schritt für Schritt nachmachen, dann tut es, mehr erläutert wird nicht. Ist das nicht immer^Woft so?

floschi on :

Hm, bei einem Wiki stört dich niemand dabei, die von dir kritisierten Punkte dort zu ändern und so für ein "vernünftiges Niveau" zu sorgen.

Marc 'Zugschlus' Haber on :

Bei debianhowto.de sind die Texte klar Werk eines Autors oder eines Autorenteams. Da pfusch ich nicht rein, vor allen Dingen nicht, wenn das im Ergebnis eine komplette Neuerstellung des Textes wäre.

eis_os on :

Es wäre trotzdem sehr hilfreich mal einen vernünftigen Text zu lesen, der sich mit diesem Thema besser auseinander setzt.

Christopher Kunz on :

Nunja, von Howtos generell halte ich auch nicht so wirklich viel, und speziell von Debian-optimierten solchen nicht. In diesem Fall hat mir aber das Howto den entscheidenen Hinweis gegeben, warum mein FastCGI-Setup (komplett aus den Sourcen gebaut) nicht so recht performen wollte.

Grundsätzlich bin ich jedoch mit Zugschlus einer Meinung: Howtos, die blindes Abtippen ohne jedes Verständnis fördern (oder gar nur eine Liste der zu apt-gettenden Pakete sind), will man nicht.

Jo on :

räusper ''welche'' Version von mod_fastcgi geht nicht? libapache2-mod-fastcgi oder libapache-mod-fastcgi? Und welche 2.4.2: 2.4.2-1, 2.4.2-2, ..., 2.4.2-6?

Wenn schon über die Ungenauigkeiten in anderer Leute Howtos lästern, dann selbst bitte etwas genauer ;-)

Nichtsdestotrotz probier ich es jetzt grad mal mit einem eigenen Howto, in dem auch Fastcgi vorkommt. Ist alles noch in Arbeit, Kommentare willkommen, Link: durchholz.org/jo/debian-install/ , der Teil über Fastcgi liegt in http://durchholz.org/jo/debian-install/Main/FastCgi .

jojo on :

Hallo,

was sollen denn diese ungenauen Kommentare hier. Welche Version funktioniert nicht? Was sind die Fehler? Kann der Autor das hier mal bitte genau erklären, oder auf welcher Ebene wird hier geschrieben?

Danke!

Marc 'Zugschlus' Haber on :

Ich habe an der Stelle nur aus dem BTS und vorhandener Dokumentation zitiert. Ich habe das damals nur testweise benutzt, und es ist ein Jahr her.

Jo on :

Also, ich hab es (endlich!) zum Laufen gekriegt. Unter Ubuntu (dort hab ich es auch als Howto abgelegt).

fcgid funktioniert leider nicht - es kommt mit Skripten in Unterverzeichnissen nicht klar, man müsste das Starterskript in jedem einzelnen Verzeichnis ablegen. Ich habe das Thema mit dem Autor von modfcgid diskutiert, er hat keine Ahnung, wie er das hinkriegen soll. Vielleicht kümmert er sich irgendwann darum, ich habe modfcgid daraufhin jedenfalls erstmal ad acta gelegt.

modfastcgi funktioniert (erstaunlicherweise) recht problemlos, wenn man die teilweise doch recht umständliche Konfiguration überstanden hat. Zudem habe ich festgestellt, dass die Dokumentation zu Apache 2.0 Links zu den Seiten zu modfastcgi verlinkt - entweder ist mod_fastcgi nicht so tot, wie ich dachte, oder das Apache-Team kümmert sich darum, oder es hat sich sonstwo ein neuer Betreuer gefunden. Es besteht also wohl nicht die Gefahr, dass das Modul nach dem nächsten Update plötzlich den Dienst einstellt.

Immerhin. Damit ist ein langwieriges und streckenweise überaus frustrierendes Kapitel abgeschlossen.

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options