Lighttpd Umstellung
26th of June 2005
Wie schon zuvor angemerkt, habe ich meinen host auf lighttpd umgestellt (über Sinn oder Unsinn kann man sich natürlich streiten). Da ich nicht so viele vhosts hoste (um die 10), war die Konfiguration ziemlich übersichtlich.
Einzig und alleine meine bis dato recht dürftige Erfahrung mit fastcgi machte die Umstellung etwas “mühsam”.
Wie schon zuvor angemerkt, habe ich meinen host auf lighttpd umgestellt (über Sinn oder Unsinn kann man sich natürlich streiten). Da ich nicht so viele vhosts hoste (um die 10), war die Konfiguration ziemlich übersichtlich.
Einzig und alleine meine bis dato recht dürftige Erfahrung mit fastcgi machte die Umstellung etwas “mühsam”.
Unabhängig von lighttpd, wird bei fastcgi pro Applikation ein (oder mehrere) persistente Prozesse gestartet, die dann natürlich unter ganz anderen Benutzern laufen können, als der eigentlich Webserver. So kann man z.B. ziemlich schmerzlos für Benutzer A eine Webapplikation betreiben, die auch Zugriff auf das Filesystem hat, aber keinen Schreibzugriff auf Verzeichnisse anderer Webapplikationen (Benutzer) hat…, was bei naivem mod_php nicht möglich ist (ok es gibt Dinge wie mod_suPHP).
Lighttpd unterstützt für fastcgi zwei Betriebsarten. Beim sog. adaptive-spawning startet lighttpd die fastcgi-Prozesse selbstständig und erzeugt bei Bedarf, konfigurierbar, mehr Prozessem, falls die Last steigt.
Alternativ können fastcgi-Prozesse über TCP oder UnixDomain-Sockets angesprochen werden. D.h. die Prozesse müssen extern (und unabhängig) vom Webserver gestartet werden.
Gut gefällt mir auch, dass man mit lighttpd load balancing für fastcgi benutzen kann.
In meiner Testumgebung hatte ich zunächst die erste Variante verwendet, da man sich so erstmal auf den Webserver und die Applikationen konzentrieren kann. Apropos Testumgebung: hierzu habe ich mir ein test-Verzeichnis anglegt und dort
- lighttpd
- mysql
- python
- php
- cronolog
installiert (configure—prefix=$HOME/test) und ausgehend davon die einzelnen Webapps getestet.
Untersucht habe ich folgende (alle fastcgi):
- Textpattern
- Wordpress
- Scuttle
- Squirrelmail
- Websvn
- einige selbstgeschriebene Applikationen
Probleme gab es eigentlich keine grösseren, ausser bei Scuttle, das extensiv PATH_INFO nutzt. Nützlich war hier dann letztlich der ausgesprochen freundliche IRC-channel #lighttpd auf freenode, wo mir Jan von der undokumentierten Option “broken-scriptfilename” erzählte.
MoinMoin habe ich leider, trotz einigen Experimenten, nicht mit fastcgi zum laufen bekommen (obwohl ich es in der Vergangenheit schon einmal unter fastcgi mit dem Indianer im Betrieb hatte). MoinMoin lieferte immer nur die Startseite aus, unabhängig von der angeforderten Seite. Nachdem ich “request.py” irgendwann total zerpflückt hatte, hab ich die Lust verloren und es so gemacht, wie man auf der MoinMoin-Site verfährt: ein lokaler twisted-Server, in dem moinmoin persistent läuft. Lighttpd verbindet sich dann per mod_proxy auf diesen.
Wie zu erwarten, gab es bei normalen CGIs (bei mir z.B. AWStats) wenig Probleme. Nagut, ViewCVS habe ich nicht auf Anhieb überreden können, aber das wollte ich sowieso durch WebSVN ersetzen.
mod_davsvn habe komplett eleminiert und durch svnserve ersetzt.
Mein persönliches Fazit ist: I love it! Die Konfiguration ist sehr übersichtlich und kompakt. Die Performanz ist ideal (auch dank freebsd-kqueue). Hier und da würde ich mir zwar mehr Einstellmöglichkeiten wünschen (z.B. bei ssl/tls), aber lighttpd ist ja noch jung und relativ unbekannt.