Neues im Apache Webserver 2.4
Seite 2: Seite 2
AAA
AAA steht für "Authentication, Authorization and Accounting", also alle Module, die mit der Authentifizierung und Autorisierung von Benutzern zu tun haben. Hier gab es schon bei Apache 2.2 große Veränderungen und auch jetzt wieder wurde in diesem Bereich einiges umgestellt. Letzten Endes waren die Entwickler mit dem Grad der Bereinigung in Apache 2.2 nicht zufrieden, daher hat man hier noch einmal einen größeren Wurf gewagt.
In der Konfiguration werden nun alle Autorisierungseinstellungen über die gemeinsame Direktive Require vorgenommen. Dabei registrieren die unterschiedlichen Autorisierungsmodule jeweils zusätzliche Syntax. So wird ein IP-basierter Zugangsschutz nicht mehr mittels "Allow from network/netmask", sondern via "Require ip network/netmask" ausgedrückt. In Require sind auch komplexe Ausdrücke unter Verwendung des allgemeinen neuen Expression Parsers möglich. Außerdem lassen sich Require-Directiven mittels RequireAll, RequireAny und RequireNone schachteln.
Störungsanalyse
Aber nicht nur Features zählen. Administratoren wissen, wie wichtig es ist, im Problemfall eine saubere Störungsanalyse durchführen zu können. Schwachpunkt bei Apache war hier bislang vor allem das Logging von Fehlern. Im normalen Log-Level "info" wurde sehr wenig geloggt, auf dem einzig verfügbaren höheren Log-Level "debug" schrieben einzelne Module, insbesondere mod_ssl und mod_proxy, extrem viel ins Log. Im neuen Apache wurde die Situation stark verbesserte: Der Log-Level ist nun pro Modul konfigurierbar, aber sogar auch pro URL oder Verzeichnis. Gleichzeitig wurden die weiteren Log-Levels "trace1" bis "trace8" eingeführt und viele neue Log-Statements in den Apache-Kern und in die Module eingebaut. Damit ist es möglich, die Verarbeitung wesentlich präziser nachzuvollziehen. Die Entwickler haben darauf geachtet, dass durch die neuen Log-Statements kein Overhead entsteht, wenn sie nicht ausgeführt werden.
Zur besseren Korrelation zwischen Error-Log und Access-Log kann das Error-Log-Format konfiguriert werden und dabei insbesondere eine neue Korrelations-ID aufgenommen werden, die auch im Access-Log protokolliert werden kann. Schließlich erlaubt das Access-Log nun auch die Ausgabe von Millisekunden-Zeitstempeln und das Loggen von Request-Anfang und Response-Ende.
Lust auf Experimente?
Einige Module sind noch als "experimentell" markiert. Bei einigen Modulen bedeutet das lediglich, dass sie noch sehr frisch und nicht so gut getestet sind wie die meisten anderen neuen Module. In diese Kategorie gehört mod_log_debug, das es erlaubt, eigene Meldungen in das Error-Log zu schreiben. Dies ist deshalb interessant, weil mod_log_debug in Verbindung mit dem neuen Expression Parser konditionell loggen kann, das heißt ob eine Meldung geschrieben wird, kann man von Detaileigenschaften eines Requests abhängig machen.
Ein anderes experimentelles Modul hat im Vorfeld für einiges Aufsehen gesorgt: mod_lua. Lua ist eine Skriptsprache, die in den letzten Jahren in vielen Anwendungen für die Entwicklung von Plug-ins unterstützt wird. Die Sprache bietet eine sehr gute Integration mit C und ihr Interpreter ist sehr schlank. Eine Einbettung in Apache bot sich deshalb an. Über mod_lua können Lua-Skripte auf Apache-Interna zuzugreifen und die weitere Verarbeitung beeinflussen. Dabei ist der Overhead weitaus geringer als bei dem früher für ähnliche Zwecke genutzten mod_perl. Das Modul ist als experimentell eingestuft, weil die Details der Verzahnung mit dem Webserver noch nicht finalisiert wurden. Es kann also sein, dass Lua-Skripte, die man jetzt entwickelt, für zukünftige Apache 2.4-Versionen angepasst werden müssen.
Kompatibilität
Die Kompatibilität mit der Vorversion war den Entwicklern sehr wichtig. Auch wenn Apache 2.4 ein neues Major Release darstellt, ist die Konfiguration doch weitgehend kompatibel geblieben. Ein erster Einstieg sollte also mit geringem Aufwand möglich sein. Für den ernsthaften produktiven Einsatz empfiehlt sich aber dennoch die kritische Überarbeitung der Konfiguration.
Die wesentlichen Inkompatibilitäten liegen in den Bereichen AAA (abgefedert durch das Kompatibilitätsmodul mod_access_compat), bei mod_cache (Wegfall von mod_mem_cache, Umbenennung von mod_disk_cache in mod_cache_disk) und bei mod_ssl (Abhängigkeit zum neuen Modul mod_socache bei Benutzung eines SSL-Session-Caches). Weitere Details sind in der aktualisierten Dokumentation enthalten.
Bauen
Als native Software müssen die Apache-Binaries für jede Plattform speziell bereitgestellt werden. Das Apache Webserver-Projekt veröffentlicht jedoch nur den Quellcode und bietet für einige wenige Plattformen als Service der Projektentwickler Binaries zum Download an. Das Gros der Nutzer bezieht seine Binaries jedoch aus Dritt-Distributionen oder baut die Binaries selbst.
Einiges hat sich beim Herstellen der Apache Binaries für Linux und Unix geändert. Zunächst einmal wurden einige Hilfsbibliotheken, die Apache verwendet, aus dem Release ausgegliedert, das heißt sie werden nicht mehr gebündelt bereitgestellt. Dies geschah zum einen, weil das Apache-Projekt in der Vergangenheit bei einigen dieser Bibliotheken die Pflege vernachlässigt hat, etwa bei der PCRE-Bibliothek (Perl Compatible Regular Expressions). Zum anderen stehen aber auch auf vielen Umgebungen die benötigten Bibliotheken bereits installiert zur Verfügung. Als Abhängigkeiten müssen vor dem Bau bereitgestellt werden:
Die bislang fest in den Apache einkompilierten MPMs lassen sich nun als dynamisch ladbare Module bauen. Damit ist es jetzt möglich, alle unterstützten MPMs in einem Durchgang zu bauen. Zudem lassen sie sich alle parallel installieren, sodass die Konfiguration beim Start entscheiden kann, welches MPM genutzt werden soll. Hierzu fügt man dem Aufruf von configure den Schalter --enable-mpms-shared hinzu.
Normale Module werden jetzt per Default als dynamisch ladbare Module übersetzt. Das alte Verfahren des statischen Linkens wird aber weiter unterstützt. Die Liste der Module, die standardmäßig gebaut werden, wurde ausgeweitet; es gehören jetzt zum Beispiel mod_ssl und mod_proxy dazu. Wer einmal alle Module inklusiv der experimentellen Module und der Module, die eigentlich nur für Entwickler interessant sind, bauen möchte, verwendet den Schalter "--enable-mods-shared=reallyall".
Ein altes Problem bei Apache war, dass viele Installationen so konfiguriert waren, dass alle enthaltenen Module auch geladen wurden, unabhängig davon, ob sie wirklich benutzt wurden. Gerade für einen exponierten Webserver ist dies nicht erwünscht; viele Administratoren unterzogen sich aber nicht der Mühe, die Liste der zu ladenden Module abzuspecken. Bei Apache 2.4 werden nun nicht mehr alle Module, die gebaut wurden, auch automatisch geladen: Die entsprechenden LoadModule-Direktiven für die nur selten verwendeten Module werden nun bei der Installation auskommentiert.
Aktuelle Probleme
Die letzten Tests vor dem Release haben noch ein Problem auf der Windows-Plattform ergeben. Apache ist auf dieser Plattform seit einigen Jahren populär, aber die Unterstützung durch die Entwickler im Projekt hinkt noch etwas hinterher. Die Direktive Win32DisableAcceptEx, die bei Apache 2.2 erforderlich sein konnte, ist in 2.4 weggefallen und wurde von AcceptFilter http none abgelöst. Dabei wird unter Windows jedoch gelegentlich das initiale Paket eines SSL-Handshakes nicht verarbeitet, sodass es zu Verbindungsfehlern kommt. Der aktuelle Status des Problems lässt sich im Störungsticket 52476 verfolgen.
Fazit
Das neue Release ist eher als evolutionär zu bezeichnen. Die größte Änderung ist ohne Zweifel das MPM Event: Nach Messungen des Projektes hat Apache in Sachen Skalierbarkeit und Out-of-the-box-Performance nun zu nginx aufgeschlossen und ihn in einigen Szenarien überholt.
Performance ist aber häufig nicht ausschlaggebend. Gerade in großen produktiven Umgebungen spielen Stabilität und die Fähigkeit, komplexe Integrationsszenarien umzusetzen und dabei auftretende Probleme schnell analysieren zu können, eine weit größere Rolle. Hier setzt Apache 2.4 mit seinem deutlich flexibleren Logging neue Maßstäbe.
Für viele einfachere Szenarien reicht der bewährte Apache 2.2 weiter aus. Ein Umstieg auf Apache 2.4 im Laufe der nächsten beiden Jahre empfiehlt sich aber, da der Schwerpunkt der Produktpflege jetzt eindeutig bei 2.4 liegen wird. Apache 2.4 fühlt sich auf Anhieb sehr vertraut an, die Einstiegsschwelle ist also denkbar gering; und viele der neuen Features erleichtern Administratoren das Leben. Nicht zuletzt ist es aber auch ein feines Stück Technik, das zu ergründen Spaß macht. (odi)
Rainer Jung ist Mitglied der Apache Software Foundation und Geschäftsführer von kippdata, einem auf Apache/Tomcat, Lucene, Datenmanagement und Infrastruktur spezialisierten Systemhaus.
