Jetzt oder erst in ein paar Monaten steht für Administratoren der Wechsel vom Apache-Server 1.3 zu 2 ins Tipi. Dieser Beitrag nennt die wichtigen Neuerungen und gibt Entscheidungshilfen.

Nach zweieinhalb Jahren Entwicklungszeit hat die Apache Software Foundation[1] mit der Version 2.0.35 im April die neue Generation Ihres Webservers [2] für “die Allgemeinheit nutzbar” erklärt[3]. Zum Redaktionsschluss dieses Hefts war 2.0.40 aktuell. Doch offenbar trauen sich viele Administratoren nicht an eine Umstellung. Dieser Artikel benennt für Unentschlossene die Vorteile des Neuen und für Umsteiger die Fallstricke.

Was ist neu?

Augenfällig ist zunächst ein ganzer Strauß neuer Funktionen in Apache 2.0:

• Build-System: Das Build-System setzt nun ganz auf Autoconf und Libtool. Die Installation läuft nach dem Auspacken wie gewohnt: »./configure –prefix= Prefix«, ohne die »prefix«-Option ist der Zielpfad »/usr/local/ apache2«. Es folgen »make« und »make install«. Ein Ansi-C-Compiler wie GCC ist dazu nötig, Perl ab Version 5.003 optional. Module werden wie bei Apache 1.3 entweder einkompiliert (»–enable- Module«) oder zur Laufzeit als Dynamic Shared Objects (»–enable- Module=shared«) geladen. Zum Erzeugen von DSOs gibt’s das neue Apache Extension Tool »apxs«.
• Konfiguration: Zur Konfiguration ändert der Administrator die Datei » Prefix/conf/httpd.conf«. In ihr wurden viele der bisher verwirrenden Konfigurationsanweisungen vereinfacht oder wie die »Port«- und »BindAddress«-Anweisungen ganz entfernt. Ausschließlich die »Listen«-Anweisung dient fortan zum Setzen von IP-Adressen und Portnummern. Der Servername und die Portnummer, die für Weiterleitungen und Erkennung virtueller Server verantwortlich zeichnen, konfiguriert künftig die »ServerName«-Anweisung.
• IPv6: Auf Systemen, bei denen die zugehörige Portable-Runtime-Bibliothek (siehe Abschnitt über APRs) IPv6 unterstützt, benutzt Apache IPv6 Listening Sockets. Zusätzlich beherrschen die Konfigurationsanweisungen »Listen«, »NameVirtualHost« und »VirtualHost«-IPv6-Adressangaben, zum Beispiel »Listen [fe80::1]:8080«.
• Module: Mod_ssl ist jetzt offizieller Apache-Bestandteil. Mod_proxy ist großteils neu geschrieben, wobei viele Funktionen in mehrere Mod_*cache-Module abgewandert sind. Neu ist der Kompressor Mod_deflate, der potenziell Mod_gzip (siehe Beitrag ab Seite 39) ersetzt.
• Filterung: Apache-Module lassen sich jetzt als Filter der ein- und ausgehenden Datenströme einsetzen. So können beispielsweise die Ausgaben von CGI-Skripten durch den »INCLUDES«-Filter von Mod_include bearbeitet und damit Server-seitige Include-Anweisungen ausgeführt werden.
• Mehrsprachig: Fehlermeldungen, die an die Client-Browser gehen, speichert Apache als SSI-Dokumente in mehreren Sprachen. Der Administrator kann sie auch anpassen, um ein einheitliches Design zu erreichen.
• Multi-Protokoll: Apache 2.0 stellt die Basis bereit, um mehrere Protokolle zu verarbeiten. (Die Dokumentation für dieses Feature ist leider derart dürftig, dass bis zum Redaktionsschluss seine praktische Bedeutung nicht zu ermitteln war.)

bu1Abbildung 1: Die Standardmodule der Version 1.3 bringt Apache 2.0 zwar ausnahmslos mit, die alten Third-Party-Module laufen aber zunächst nicht.

Unter der Haube: Gestern und heute

Bis zur Version 1.2 unterstützte Apache nur Unix-Betriebssysteme. Sie sind im Gegensatz zu Windows in der Lage, Prozesse zu kopieren (das so genannte Forking). Apache arbeitete als so genannter Preforking-Server: Der gestartete Vater- Prozess legt zu Beginn eine in der Konfigurationsdatei angegebene Anzahl von Kopien seiner selbst an, die auf eingehende HTTP-Anfragen warten. Falls mehr Anfragen eingehen, als es Prozesse gibt, werden rechtzeitig neue Kopien des Ursprungsprozesses angelegt.

Apache wurde in der Version 1.3 relativ mühsam auf Windows-Betriebssysteme (auch auf Netware 5 und IBMs Transaction Processing Facility) portiert. Dazu schrieben Entwickler die komplette Prozess-Engine neu. Unter Windows läuft die so genannte Thread-Version von Apache 1.3, unter Unix/Linux die Prozess-Variante.

Um Apache 2.0 leichter portierbar zu machen, trennten die Entwickler den plattformspezifischen Code vom restlichen Apache-Code in den Sourcen des APR und der MPMs (siehe unten). Diese Kapselung macht es auch leichter, Plattform-Optimierungen vorzunehmen.

Die Apache Portable Runtime APR

Apache 2 benutzt nicht mehr (direkt) die Posix-Schnittstellen wie die Apache-Versionen zuvor. Fehlerhaft und leistungsschwach implementierte Posix-Bibliotheken beziehungsweise -Emulatoren hatten auf Nicht-Unix-Betriebssystemen zur Folge, dass der Server dort nicht sonderlich gut lief.

Die stattdessen eingeführte Apache Portable Runtime (APR) ist eine Apache- eigene Bibliothek, die eine Schicht zwischen den jeweiligen Betriebssystemen und Apache 2 bildet. APR bietet durch sein API grundlegende Funktionen eines virtuellen Betriebssystems an. Dazu gehören File- und Netzwerk-I/O, Speicherverwaltung sowie Thread- und Prozessverwaltung. Die APR benutzt, wann immer möglich, native Aufrufe der realen Betriebssysteme. Zudem versuchen die APR-Methoden frühere Posix-Methoden nachzuempfinden, damit älterer Code leichter auf APR portierbar ist.

Das (erreichte) Ziel der APR-Version 1.0 war es, alle Funktionen bereitzustellen, die für Apache 2.0 erforderlich sind. Es ist geplant, danach das APR auch unabhängig von Apache als Basis für plattformunabhängiges Programmieren weiterzuentwickeln und interessierten Programmierern zur Verfügung zu stellen.

Multi Processing Modules

Mit einer spezielle Modul-Art lagert Apache 2 den Code aus, der in der Version 1.3 die Prozesse und Threads verwaltet. Die Aufgabe solcher Multi Processing Modules (MPMs) ist es, eingehende HTTP-Anfragen auf einfache Ausführungseinheiten abzubilden, die die Anfragen bearbeiten. Ob Prozesse oder Threads erzeugt und verwaltet werden, hängt vom gewählten MPM ab.

Diese Form der Modularisierung verschafft Apache 2 neben einem klar strukturierten Quellcode einige weitere Vorteile. Die Apache-Entwickler erlauben es in MPMs ausdrücklich, betriebssystemspezifischen Code zu benutzen. Solche MPMs lassen sich nur auf diesem einen Betriebssystem übersetzen, laufen dann dort aber Performance-optimiert – ein Effekt, der insbesondere auf Nicht-Unix-Betriebssystemen zu beobachten ist. Apache-Entwickler Bill Stoddard erreichte unter Windows einen Performance-Gewinn von 50 Prozent bei statischen Webseiten.

MPMs unter Unix

Für Unix gibt es mehrere MPMs. Jedes davon implementiert eine andere Strategie, mit der der Webserver die anfallenden HTTP-Anfragen abarbeiten soll. Ein Webmaster hat somit die Möglichkeit, die für seine jeweilige Anwendung geeignetste Variante auszusuchen, indem er das entsprechende MPM in das Apache-Binary einkompiliert (siehe Kasten “Vorgefertigte MPMs in Apache 2.0”). Threads sind unter den Unix-Betriebssystemen – auch unter Linux – weniger Ressourcen-intensiv als Prozesse. Andererseits ist die Stabilität bei einer reinen Prozess-Strategie größer, da ein fehlerhafter Thread seinen Prozess mitreißt.

Update oder Neuinstallation?

Da sich sehr gravierende Dinge in der Architektur des Apache verändert haben, ist eine Neuinstallation[5] dringend anzuraten und von einem Update-Versuch besser abzusehen. Der Autor dieses Beitrages hat beide Arten ausprobiert und festgestellt, dass beim einfachen Update der neue 2.0 versucht, die Module des Ausgangs-1.3ers zu übernehmen. Aufgrund der neuen Technologie sind jedoch 1.3er Module nicht ohne Anpassungen verwendbar.

Auch die Konfigurationsdateien – insbesondere die »httpd.conf« – sind eins zu eins nicht wieder benutzbar, da viele Konfigurationsanweisungen vereinfacht oder gar entfernt wurden.

Lohnt der Umstieg?

Ein Umstieg ist mit hohem Aufwand verbunden, nämlich einer vollständigen Neuinstallation des Apache-Webservers inklusive der vollständigen Neukonfiguration aller Einstellungen. Die Standardmodule der Version 1.3 bringt Apache 2.0 zwar ausnahmslos mit (siehe Abbildung 1), alte Third-Party-Module laufen aber erstmal nicht.

Ob sich der Umstieg lohnt, muss jeder Administrator für sich selbst entscheiden. Sollen die oben aufgeführten Features – wie das MPM Perchild – wirklich genutzt werden, dann lohnt es den Arbeitsaufwand. Wer die neuen Funktionen eher als Sahnehäubchen betrachtet oder gar als Spielerei, dem sei die Empfehlung auf den Weg gegeben: Never change a running Apache. (jk)