Neuheiten in Apache 2.4.6

Oleksandr But, 123RF

Comeback

Der Apache-Webserver ist nicht tot, nur etwas eingerostet. Damit das nicht so bleibt, haben die Entwickler ihn in Version 2.4 gründlich überholt.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

Wenn man den monatlich erscheinenden Statistiken von Netcraft glauben darf, ist Apache immer noch der am weitesten verbreitete Webserver im ganzen World Wide Web ( Abbildung 1 ). Schon länger legt die Konkurrenz in Person von Nginx zwar stetig zu, ist aber doch noch meilenweit von den beinahe knapp 47 Prozent entfernt, mit denen Apache weiterhin das Feld dominiert.

Abbildung 1: Obwohl Nginx ständig neue Anwender für sich gewinnt, ist Apache weiterhin der dominierende Webserver.

Dennoch haben auch die Apache-Entwickler die Kritik an ihrer Software vernommen, sie sei veraltet und zu schwerfällig, und den Webserver in der Version 2.4 gründlich überarbeitet [1] . Da sind zunächst einmal viele Kleinigkeiten, die das Leben eines Apache-Adminstators erleichtern können. Das beginnt bei der Möglichkeit, in der Server-Konfiguration Variablen zu definieren, die sich später an anderer Stelle wiederverwenden lassen. So legt im folgenden Beispiel die erste Zeile eine Variable »$host« fest, die anschließend verwendet wird:

Define $host www.google.com
<VirtualHost ${host}:80>
   ErrorLog /var/log/httpd/${host}.log

Ähnlich funktioniert Mod-Macro, das es bereits vorher als externes Modul gab, das aber seit der eben erschienenen Version 2.4.6 fester Bestandteil des Apache-Pakets ist [2] . Ein Makro funktioniert ähnlich wie eine Funktion in einer Programmiersprache: Man definiert es zusammen mit Variablen, die im Rumpf des Makros vorkommen. Will man das Makro verwenden, ruft man es mit den konkreten Werten auf, die ins Makro eingesetzt werden. Listing 1 illustriert die Anwendung.

Listing 1

Makro

 

Geändert hat sich auch die Syntax für die Definition namensbasierter virtueller Hosts. Die bisher dafür verwendete Anweisung »NameVirtualHost« gibt es nämlich nicht mehr. Stattdessen können Administratoren sich nun auf die Definition der virtuellen Hosts beschränken. Listing 2 und Listing 3 zeigen den Unterschied. Diese scheinbar kleine Änderung ist laut der Apache-Entwickler eine große Sache, denn der alte Weg der Konfiguration führte zu einer Vielzahl von Problemen, wenn der »NameVirtualHost« nicht zu einem »VirtualHost« passte.

Listing 2

Virtual Host (alt)

 

Listing 3

Virtual Host (neu)

 

Noch mehr Komfort bei der Konfiguration entsteht durch die Möglichkeit, mit logischen Bedingungen wie »If« , »ElseIf« und »Else« einzelne Abschnitte ein- und auszuschalten. Hierbei können sowohl selbstdefinierte Variablen wie auch die vorbelegten Servervariablen zum Einsatz kommen. Ein Beispiel dafür ist in Listing 4 zu sehen. Die gleiche Funktion, nämlich die Umleitung auf den WWW-Host, wurde bisher meistens mit Rewrite-Regeln umgesetzt, erforderte aber dafür kompliziertere Konstruktionen. Lediglich mit den Anführungszeichen muss man beim neuen Weg etwas aufpassen.

Listing 4

Konditional

 

Weitere Änderungen der Syntax gibt es etwa bei der Override-Konfiguration, die nun eine feiner abgestufte Kontrolle dessen erlaubt, was an Zugriffen auf ein bestimmtes Webverzeichnis erlaubt ist. Genauso wurde der Zugriffsschutz per Require von Grund auf überarbeitet. Statt der simplen, alten Anweisungen »allow« und »deny« gibt es nun die Option, logische Bedingungen zu verschachteln und damit den Zugriff im Einzelnen zu kontrollieren. Dabei berücksichtigt der Apache-Server auf Wunsch die Zugriffsmethode (GET/PUT und so weiter), Umgebungsvariablen, IP-Adresse/Hostname und auch selbst gesetzte Variablen, die der Administrator sogar in eigenen Expressions auswerten kann. Die beiden neuen Direktiven »RequireAll« und »RequireAny« gruppieren die Bedingungen als logische Und- respektive Oder-Verknüpfung. Ermöglicht wird all dies durch das Modul »mod_authz_core« . Ein umfangreiches Beispiel aus der Apache-Dokumentation ist in Listing 5 zu sehen.

Listing 5

Zugriffsschutz

 

Neue Module

Eine ganze Reihe weiterer neuer Module erweitert den Funktionsumfang von Apache beträchtlich. Zum Teil gab es sie – wie im Fall von »mod_proxy_html« – schon vorher, sie wurden nun aber in die Apache-Core-Distribution eingegliedert. Experimentell ist derzeit noch der Support für die Skriptsprache Lua, mit der sich nun eigene Apache-Webanwendungen schreiben lassen. Ein ADMIN-Artikel hat über das Modul bereits einmal ausführlich berichtet [3] .

Die beiden Module »mod_fcgi« und »mod_scgi« ermöglichen es, Anwendungen einzubinden, die das Fast-CGI- beziehungsweise das SCGI-Protokoll implementieren. Dies geschieht über Mod-Proxy, während sich mit dem Mod-Proxy-Balancer gleich auch noch Loadbalancing realisieren lässt. Eine Liste der wichtigsten neuen Module in Apache 2.4 ist in Tabelle 1 zu sehen.

Tabelle 1

Neue Module

Modul

Funktion

mod_auth_form

Authentifizierung über HTML-Forms

mod_log_debug

Frei konfigurierbares Logging zu Debugging-Zwecken

mod_lua

Integriert den Interpreter der Lua-Skriptsprache in den Webserver (experimenteller Support)

mod_proxy_express

Vereinfachte Konfiguration für Reverse Proxies.

mod_proxy_fcgi

Backend für die Anbindung von Webanwendungen über FastCGI-Protokoll

mod_proxy_html

Ändert bei Proxy-Konfiguration den HTML-Quelltext, zum Beispiel URLs

mod_proxy_scgi

Backend für die Anbindung von Webanwendungen über das SCGI-Protokoll

mod_ratelimit

Bandbreitenlimitierung für Clients

mod_remoteip

Unterstützung für die Remote-IP-Variable beim Einsatz von Proxy und Loadbalancer

mod_sed

On-the-Fly-Änderungen des HTTP-Response-Body nach Art des Unix-Tools »sed«

mod_session

Speichert Client-Sessions, etwa über Cookies oder Datenbank

Fehler in der Konfiguration sind nun generell leichter aufzuspüren, weil sich das Loglevel per Modul und per Verzeichnis einstellen lässt ( Listing 6 ). Darüber hinaus gibt es jenseits des alten Debug-Loglevels noch die neuen Loglevel »trace1« bis »trace8« . Um für ein spezifisches Modul das Logging zu kontrollieren, stellt man es dem Loglevel voran: »LogLevel info ssl:warn« .

Listing 6

Logging per Directory

 

Performance

Der neue Apache-Server ist von Grund auf stärker modularisiert als seine Vorgänger. So sind nun erstmals die sogenannten Multiprocessing-Module, die das Verhalten bei der Verarbeitung von HTTP-Requests bestimmen, dynamisch ladbar. Früher gab es nur das Prefork-Modul, das beim Start des Webservers eine gewisse Anzahl von Prozessen startete und für neue Verbindungen neue Kindprozesse startete. Dann kam das Threading-Modul hinzu, das die Thread-basierte Verarbeitung von Anfragen ermöglichte. Bisher mussten diese beiden Module aber immer fest einkompiliert werden, was dazu führte, dass es in Linux-Distributionen zwei verschiedene Pakete dafür gibt, etwa »apache-mpm-prefork« und »apache-mpm-worker« .

Jetzt kann der Administrator per Konfigurationsdatei bestimmen, welches MPM-Modul verwendet wird. Darüber hinaus gibt es noch ein neues Thread-basiertes Modul namens »event« , das Event-basierte Verarbeitung von Requests implementiert. Es existiert schon eine Zeit lang und hat sich dabei bewährt, sodass es nun sogar die bisherige Default-Konfiguration »prefork« abgelöst hat. Unter Linux verwendet es den Systemcall »epoll« , unter BSD-Systemen die KQueue-Infrastruktur.

Verbessern soll das neue Event-Modul die Performance vor allem bei vielen HTTP-Keepalive-Verbindungen. Dabei halten Server und Webbrowser die einmal aufgebaute TCP-Verbindung aufrecht und schicken darüber mehrere HTTP-Requests. Das verringert den Overhead von immer neuen Verbindungseröffnungen, bindet aber auf dem Server dauerhaft Ressourcen, gerade wenn im Fall des Prefork-Moduls ein kompletter Kindprozess durch die Verbindung blockiert ist.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023