burn a church
Zucht und Ordnung from hell

Lighttpd ist Web 2.0. Muss er auch - es ist schließlich ein flippiger, hipper, kleiner Webserver. Was sonst, wenn nicht diese Prädikate assoziiert der gemeine Web-2.0-Hippie mit Web 2.0? “Lighty” - so nennt man den Webserver in der zugehörigen Community ist anders als der alte archaische Apache-Webserver.

Da aber immer mehr Serveradministratoren Lighttpd einsetzen, muss es auch einen Grund geben. Ist es womöglich der bessere Webserver? Ist er der effektivere? Ist er einfacher zu administrieren?

Web 2.0 und moderne Architektur

Apache ist natürlich nach wie vor unangefochten der Spitzenreiter [2] unter den verwendeten Webservern, darauf folgt lange nichts und irgendwann Microsofts IIS. Das hat selbstverständlich so seine Richtigkeit und entspricht der von Gott gegebenen Ordnung. Vor nicht all zu langer Zeit entschied sich daher ein deutscher Softwareentwickler diese natürliche Ordnung zu verrücken und einen der Platzhirsche zu verdrängen. In der Tat gibt es gegenwärtig nur eine handvoll ernstzunehmender Webserver, gut und züchtig, da frei ist davon aber nur Apache - und Lighthttpd.

Der alte, archaische aber bewährte Apache unterscheidet sich grundsätzlich von Lighttpd. Die Unterschiede liegen dabei nicht nur im Namen: auch die technische Implementierung ist grundverschieden. Apache setzt auf eine verteilte Architektur, auf Threads oder Prozessen und eine komplexe Interprozesskommunikation. Für den Nichtinformatiker bedeutet dies, dass Apache für jeden ankommenden Besucher eine Instanz von sich selbst klont, die exklusiv erwähnten Besucher bearbeitet. Das sind traditionalistische Unix-Strategien; nicht wirklich neu, aber bewährt und stabil. Im Kontrast dazu steht der (modernere) Ansatz von Lighttpd, wo ein einzelner Prozess sämtliche Benutzer verwaltet und über (e)poll/select serialisiert jeden Besucher zyklisch befragt. Das hat beispielsweise den Vorteil, dass die Notwendigkeit von Interprozesskommunikation minimiert wird. Das sind technische Unterschiede in der Implementierung, es lässt sich nur schwer sagen, welcher Ansatz grundsätzlich besser ist, sie sind schlicht anders. Über das ganze Konzept betrachtet und im Gesamten betrachtet ist Lighttpd allerdings unter manchen Umständen und das muss ich neidvoll anerkennen, schneller als Apache (siehe auch Benchmarks [1][2]).

Lighttpd ist nicht der erste Webserver, der in die große freie Welt zog, gegen den übermächtigen Apache anzutreten. Es ist nicht der erste, der in Benchmarks besser als Apache abschnitt. Es ist auch nicht der erste, der interessante Features mitbringt. Es ist aber der erste, der eine nennenswerte Verbreitung erreicht hat. Alle anderen fristen ein Nischendasein. Irgendetwas ist bei Lighthttpd also anders.
Ähnlich archaisch wie die technische Grundlage, ist das Entwicklungskonzept von Apache. Dort hat sich dieses seit zehn Jahren nicht verändert und entspricht exakt dem klassischen Basarsystem. Es gibt eine Entwicklungsmailingliste, eine Versionsverwaltung und einen Bug-Tracker. Seit Jahrzehnten entwickelt man in der Unixwelt so Programme, vom Linux Kernel zum Apache Webserver. In Zeiten von Last.fm, Youtube, myspace und noch viel mehr seltsamen, unredlichen Kram scheint dieses Modell aber renovierungsbedürftig. Ich sprach eingangs von einer Lighttpd-Community. So etwas hat sich tatsächlich um Lighty gebildet und das ist das außergewöhnliche an Lighttpd. In der Tat sieht die Aufmachung auf lighttpd.net anders aus, als die von anderen Projekten. Dort gibts Blogs, noch mehr Blogs, ein Wiki und natürlich die Standardausstattung. Nicht zuletzt dieses Gemeinschaftsbewusstsein, dass sich um Lighty (welcher Webserver hat schon einen Kosenamen?) ist es, was den anhaltenden Erfolg ausmacht. Nicht das technische Konzept, das andere Server auch haben. Lighty ist Web 2.0.

Hinter dem Hype

Sieht man vom Hype um Lighty ab, was bleibt dann noch übrig? Es ist erschreckend wenig. Ich verwende das Ding auf manchen Servern mittlerweile seit eineinhalb Jahren, aber richtig glücklich hat er mich nie gemacht. Ja, Lighty hat seine Vorzüge als Bannerschleuder, zum Downloadthrottling. Das FastCGI-Konzept hongegen, das es für PHP verwendet, bringt aber auch unlustige Seiteneffekte. Wo der Webserver plötzlich nur noch aus einem Prozess besteht, habe ich plötzlich Hunderte von PHP-Prozessen im System. Die Vorteile gegenüber PHP mit Apache-ISAPI halten sich schwer in Grenzen.

Mehr als lästig ist auch die Konfiguration von Lighttpd. MIME-Typen muss man Lighty erst kompliziert beibringen, ihn an mehrere IP-Adressen zu binden ist nur mit wildesten Konfigurationsconditionals möglich. Überhaupt scheint die Konfiguration ein wilder Mix aus Direktiven, Conditionals und allerlei seltsamen Getier. Da Lighty Konfigurationsdateien auch nicht zur Laufzeit auf Verzeichnisbasis erweitert werden können (viele werden Apaches “.htaccess” kennen), ist es auch nicht möglich, Benutzern ohne Administratorrechten die Möglichkeit zu geben, etwa die eigenen Rewriteregeln erstellen zu lassen oder schlicht einen Passwortschutz anzulegen. Für einen ISP ist sowas ein K.O.-Kriterium.
Das gesamte Wikikonzept auf der Homepage bringt im übrigen auch die Folgen mit sich, dass Lighty nur spärlich dokumentiert ist. Tiefgreifende Konzepte finden sich kaum, neue Features sind unterdokumentiert. Lighty ist nämlich an allen Stellen eine große Baustelle, Module werden ständig weiterentwickelt und verändert. Tiefgreifendste Neuerung an Lighthttpd 1.5, der gerade zur Veröffentlichung ansteht, ist etwa die Tatsache, dass dort ohne Übergangszeit nicht rückwärtskompatible Änderungen eingeführt wurden, die etwa die Ausführung von PHP-Skripten komplett verändern. Sowas ist unprofessionell und wird sich hoffentlich bis zur finalen Veröffentlichung noch ändern.

PHP, GeoIP und URL-Rewriting in Lighthttpd 1.5

Es steht also, wie erwähnt die Veröffentlichung von Lighty 1.5 an, der einige (interessante) Neuerungen mit sich bringt - aber eben auch die äußerst lästige Änderung an den Skriptenbackends. Bislang funktionierte PHP wie erwähnt über FastCGI, bereitgestellt von mod_fastcgi. Ab 1.5 funktioniert das von einem Moment auf den anderen nicht mehr. Dort wurden etwa die Module für FastCGI (PHP) und SCGI (Python) zusammengefasst und hören ab nun auf den Namen mod_proxy_core. Gegenwärtig ist die Dokumentation hierzu mehr als spärlich, ursprünglich der Auslöser für diesen Artikel. Nach etwas hin und her, habe ich nämlich herausgefunden, dass es kein integriertes FCGI-Backend mehr gibt und dieses (nun) extern mitgeliefert wird. Eine minimale Lighthttpd.conf mit PHP sieht daher nun so aus:

server.modules       = (
"mod_alias",
"mod_proxy_core",
"mod_accesslog",
"mod_status",
"mod_proxy_backend_fastcgi"
)
 
server.document-root = "/var/www/"
server.errorlog      = "/var/log/lighttpd/error.log"
 
index-file.names     = (
"index.php",
"index.html",
"index.htm"
)
 
mimetype.use-xattr   = "enable"
mimetype.assign      = (
".png"  => "image/png",
".jpg"  => "image/jpeg",
".jpeg" => "image/jpeg",
".html" => "text/html",
".txt"  => "text/plain"
)
 
server.pid-file       = "/var/run/lighttpd.pid"
dir-listing.encoding  = "utf-8"
server.dir-listing    = "enable"
server.username       = "www-data"
server.groupname      = "www-data"
 
$HTTP["url"] =~ ".php$" {
proxy-core.balancer = "round-robin"
proxy-core.protocol = "fastcgi"
proxy-core.check-local = "enable"
proxy-core.allow-x-sendfile = "enable"
proxy-core.backends = ( "unix:/tmp/php-fastcgi.sock" )
proxy-core.max-pool-size = 16
}

Gestartet werden muss Lighttpd dann wie folgt:

/usr/local/bin/spawn-fcgi -f /usr/bin/php5-cgi \
-s /tmp/php-fastcgi.sock -C 75 -u www-data
chown www-data:www-data /tmp/php-fastcgi.sock
/usr/local/sbin/lighthttpd -f /etc/lighttpd/lighthttpd.conf

Alternativ kann man das natürlich auch in ein einfaches Startskript pflanzen. Nun gut, der Sinn der ganzen Umbauaktion erschließt sich mir nicht wirklich, aber bitte. Die mod_rewrite Konfiguration hat sicher immerhin nicht verändert. Die zugehörige Dokumentation für das Apache Modul und Kochbuch, hat sich hingegen nicht verändert. Der einzige Unterschied zwischen dem Apache Modul und dem Lighttpd Modul ist daher die Syntax. Dort sieht das dann so aus:

server.modules  += ( "mod_rewrite" )
url.rewrite-once      = ( "^/id/([0-9]+)$" => "/index.php?id=$1" )
url.rewrite-repeat    = ( "^/link/([a-zA-Z]+)" => "/index.php?link=$1" )

Neu und wenig bekannt ist außerdem die Unterstützung für GeoIP. Ein bewährtes, aber unfreies Apache Modul von MaxMind, mit dem Besucher anhand der IP-Adresse geografisch zugeordnet werden. Nicht offiziell unterstützt, aber mit etwas Arbeit ist es möglich mod_geoip für Lighttpd zu bauen. Die Konfiguration erfolgt wie folgt:

server.modules  += ( "mod_geoip" )
geoip.db-filename     = "/pfad/zur/geoip/datenbank.dat"
geoip.memory-cache    = "enable"

Benutzt werden, kann das Modul dann wie gewohnt.

Kategorien

Verwandte Artikel

• Windows Vista ist Unfug - aber Linux auch (12)
• SYN-Flood kurz erklärt (10)
• SQL-Injection kurz erklärt (6)
• Ressourcenverwaltung mit Xen (0)
• ksshmenu - Ein grafischer SSH-Manager für KDE (25)