13.2 Der Webserver Apache

Der Apache HTTP Server (kurz Apache) ist die mit Abstand verbreitetste Webserversoftware mit einem Marktanteil von 60 bis 70 %. Er entstand ab 1995, zunächst als Weiterentwicklung des NCSA-Webservers durch Detailverbesserungen (Patches), sodass der Name oft mit »a patchy web server« erklärt wird. Um seine Entwickler bildete sich die Apache Software Foundation, die neben dem Webserver auch zahlreiche andere bekannte Open-Source-Programme beheimatet, beispielsweise den Spam-Filter SpamAssassin, die Java-Servlet-Engine Tomcat (nebenbei ebenfalls ein Webserver) oder den XSLT-Prozessor Xalan (siehe Kapitel 15, »XML«).

Apache ist stabil, sicher und läuft auf den verschiedensten Plattformen. Ein Großteil seiner Funktionalität wird durch Module bereitgestellt. So kann er leicht durch Drittanbieter oder gar eigene Programmierung erweitert werden; außerdem können Sie nicht benötigte Teile deaktivieren, sodass sie nicht unnötig Ressourcen verschwenden.

13.2.1 Apache im Überblick

Es gibt zurzeit zwei verschiedene aktive Apache-Entwicklungszweige. Neue Features werden zwar nur noch für den aktuell stabilen Zweig 2.4.x implementiert, aber es gibt bei Bedarf noch Bugfixes für den 2.2-Zweig. Die früheren Versionen 1.3 und 2.0 wurden inzwischen mit je einem finalen Bugfix-Release eingestellt. Tabelle 13.4 zeigt die drei letzten Versionen im Überblick.

Im Folgenden wird vorwiegend die aktuelle, stabile Version 2.4 besprochen, mit ein paar Hinweisen auf den vorigen Entwicklungszweig 2.2. Die in der Tabelle bereits kurz angedeuteten Eigenschaften von Apache 2 sind:

• Abstraktionsbibliothek APR
  Bis zur Version 1.3.x verwendete Apache die auf Unix-Systemen üblichen POSIX-Systemaufrufe zur Verwaltung von Netzwerkverbindungen, Speicher, Dateizugriffen und so weiter. Auf Nicht-Unix-Systemen kam deshalb eine POSIX-Emulationsschicht zum Einsatz, die Apache auf diesen Plattformen allerdings langsamer und weniger stabil machte. Deshalb wurden solche systemnahen Funktionen für die neue Version 2 in die Abstraktionsbibliothek Apache Portable Runtime (APR) ausgelagert, die sie für jedes System nach dessen besten Möglichkeiten bereitstellt. Inzwischen wird die APR daher auch als Grundlage anderer Software eingesetzt.
• Unterschiedliche Laufzeitmodelle durch MPM
  Ein Netzwerkserver muss in der Lage sein, mehrere Clientanfragen gleichzeitig zu beantworten. Dafür gibt es je nach System unterschiedliche Prozess- oder Thread-Verfahren (siehe Abschnitt 10.4, »Einführung in die Netzwerkprogrammierung«). Apache 1.x verwendete ausschließlich ein Preforking-Modell, das heißt, er erzeugte einige Child-Prozesse auf Vorrat. Apache 2 ermöglicht dagegen die Auswahl verschiedener sogenannter Multi-Processing-Module (MPM), die auf Prozessen, Threads oder einer Mischung aus beiden basieren, sodass für jedes System die vorteilhafteste Auswahl getroffen werden kann.

  In der neuen Version 2.4 sind die MPM sogar dynamisch zur Laufzeit ladbar, genau wie alle anderen Module.

• Dynamische Module
  Die bereits in der Einleitung erwähnten Apache-Module mussten früher statisch einkompiliert werden. Apache musste also für jeden Wechsel der Modulauswahl ganz neu kompiliert werden. In Apache 2 besteht dagegen die Möglichkeit, Module als Dynamic Shared Objects (DSO) zu kompilieren und über die Konfigurationsdatei ein- oder auszuschalten. Somit braucht der Server nur neu gestartet zu werden, wenn Sie neue Module hinzufügen oder vorhandene entfernen möchten.
• Eingebaute SSL-Unterstützung
  Sicherheitsbedürftige Webanwendungen wie E-Commerce oder gar Homebanking benötigen gesicherte Verbindungen, die die Identität des Servers und die Integrität der Daten garantieren sowie die Kommunikation verschlüsseln. Die Lösung für diese Anforderung ist HTTP über SSL, kurz HTTPS. Bis Apache 1.3 gab es dafür diverse Erweiterungen, teilweise von Drittanbietern. Apache 2 ist dagegen ab Werk mit dem Modul mod_ssl ausgestattet, das die SSL-Funktionalität nahtlos integriert.

13.2.2 Apache-Module

Zum Lieferumfang von Apache gehören gut 70 verschiedene Module. Daneben gibt es unzählige Erweiterungen von unabhängigen Anbietern, sowohl als Open Source als auch kommerziell. Die meisten dieser Zusatzmodule werden auf der Site http://modules.apache.org/ erwähnt und verlinkt.

Tabelle 13.5 enthält eine Übersicht über die wichtigsten mitgelieferten Module. Die Spalte »aktiv« informiert darüber, ob das jeweilige Modul in einer Standardinstallation von Apache automatisch mitinstalliert und aktiviert wird oder nicht.

13.2.3 Apache installieren

Wenn Sie eine Unix-Variante verwenden, können Sie zunächst überprüfen, ob Apache zum Lieferumfang Ihrer Distribution gehört – dies wird meist der Fall sein. Falls Sie aber mehr Kontrolle über den Installationsumfang ausüben möchten oder die aktuellste Version brauchen, sollten Sie Apache mithilfe des offiziellen Sourcecode-Pakets selbst kompilieren. Für Windows liefert die Apache Software Foundation dagegen einen offiziellen Binär-Installer.

Installation auf Unix-Systemen

Laden Sie zunächst das neueste Release von Apache 2.4 (Anfang Juli 2013: 2.4.4) von http://httpd.apache.org/ herunter. Falls zu dem Zeitpunkt, zu dem Sie dieses Buch lesen, bereits ein neueres Release verfügbar ist, wird Ihnen dieses automatisch angeboten. Die Download-Site wählt automatisch einen nahe gelegenen Mirror, sodass Sie nach dem Download die Integrität des Pakets überprüfen sollten. Dazu müssen Sie die MD5-Prüfsumme der heruntergeladenen Datei ermitteln und mit dem Wert auf der Apache-Website vergleichen. Geben Sie dazu beispielsweise dieses Kommando ein:

$ md5sum httpd-2.4.4.tar.gz

Unter Mac OS X heißt das Kommando md5 statt md5sum.

Als Nächstes können Sie das Paket auspacken. Geben Sie für die .tar.gz-Variante Folgendes ein:

$ tar xzvf httpd-2.4.4.tar.gz

Haben Sie dagegen ein .tar.bz2-Archiv heruntergeladen, lautet die Eingabe:

$ tar xjvf httpd-2.4.4.tar.bz2

Nun müssen Sie in das neu erstellte Verzeichnis wechseln:

$ cd httpd-2.4.4

Der erste Schritt besteht darin, das Skript configure auszuführen, das die Makefiles an Ihr System und mithilfe von Kommandozeilenparametern an Ihre Wünsche anpasst. Eine vollständige Liste aller verfügbaren Optionen erhalten Sie durch Eingabe von:

$ ./configure --help |less

Hier einige der wichtigsten Optionen im Überblick:

• --prefix=/Verzeichnispfad
  übergeordnetes Verzeichnis, in das Apache installiert wird (Standard /usr/local/apache2)
• --enable-layout=Layoutname
  Auswahl eines benannten Verzeichnislayouts aus der Datei layout.config; kann als Ersatz für oder zusätzlich zu --prefix angegeben werden.
• --with-mpm=MPM-Modul
  Auswahl des passenden MPM – die wichtigsten sind prefork (rein prozessbasiert, Standard) und worker (gemischtes Prozess-/Thread-Modell). worker arbeitet auf Plattformen mit guter Thread-Unterstützung etwas speicherschonender, sollte aber nicht mit Drittanbietermodulen wie PHP eingesetzt werden.
• --enable-so
  Aktiviert die grundsätzliche Unterstützung für Module als Dynamic Shared Objects; inzwischen ist diese Option Standard.
• --enable-modules="modul1 modul2 ..."
  Kompiliert die angegebenen Module (ohne das Präfix mod_) statisch ein.
• --enable-mods-shared="modul1 modul2 ..."
  Kompiliert die angegebenen Module als Shared Objects.
• --enable-modules=most
  Kompiliert fast alle Module (außer die experimentellen sowie diejenigen, die Schwierigkeiten bereiten würden) statisch ein.
• enable-mods-shared=most
  Kompiliert fast alle Module als Shared Objects.
• --disable-modules="modul1 modul2 ..."
  Lässt die angegebenen Module explizit weg.

Das folgende Kommando bereitet Apache zur Installation ins Standardverzeichnis /usr/local/apache2 sowie zur Kompilierung fast aller Module als DSOs vor:

Danach müssen Sie die beiden folgenden Kommandos eingeben, um die eigentliche Kompilierung sowie die Installation in das Zielverzeichnis durchzuführen:

$ make
# make install

Mindestens den letzten Schritt müssen Sie als User root ausführen, da ein normaler User nicht in Verzeichnisse wie /usr/local schreiben darf.

Nach der Installation können Sie Apache starten und anderweitig steuern. Dazu dient das Skript apachectl im Unterverzeichnis bin. Es besitzt unter anderem folgende Aufrufoptionen:

• apachectl start
  Apache starten
• apachectl stop
  Apache beenden
• apachectl graceful-stop
  Apache beenden, aber erst nach Bearbeitung aller laufenden Clientanfragen (seit Version 2.2 verfügbar)
• apachectl restart
  Apache neu starten – wichtig nach Konfigurationsänderungen
• apachectl graceful
  Apache nach Fertigstellung der aktuellen Anfragen neu starten; manche Änderungen benötigen allerdings einen »richtigen« Neustart.

Im Übrigen eignet sich apachectl auch als Startskript, das den automatischen Start von Apache beim Booten ermöglicht. Einzelheiten dazu finden Sie in Kapitel 7, »Linux«. Auf den meisten Linux-Systemen genügt es, einen Symlink auf apachectl in /etc/init.d abzulegen und diesen anschließend per chkconfig -a zu aktivieren. Beispiel:

# ln -s /usr/local/apache2/bin/apachectl \
 /etc/init.d/apache2
# chkconfig -a apache2

Installation unter Windows

Ein offizielles Windows-Binary-Release von Apache 2.4 gibt es noch nicht. Sie können es entweder selbst kompilieren (Anleitung in der offiziellen Apache-Dokumentation) oder von Drittanbieter-Websites wie http://www.apachelounge.com erhalten.

Laden Sie den Apache-Installer (zurzeit httpd-2.2.25-win32-x86-openssl-0.9.8y.msi) von http://httpd.apache.org/ herunter.[Anm.: Es gibt auch eine SSL-freie Variante namens apache_2.2.25-win32-x86-no_ssl.msi – bis vor einigen Jahren gab es gar keine Windows-Version, die das Modul mod_ssl und die passende OpenSSL-Version mitlieferte.] Doppelklicken Sie danach auf das Icon des Installers.

Befolgen Sie danach in jedem Fall die Installationsanweisungen. Der Dialog besteht aus den folgenden Seiten, auf denen Sie jeweils Next anklicken müssen, um fortzufahren:

1. kurze Information, dass Apache 2 installiert wird
2. Anzeige der Apache-Lizenz – eine typische Open-Source-Lizenz, die sowohl die freie Verwendung als auch die beliebige Veränderung des Webservers gestattet. Wählen Sie die Option I accept the terms in the license agreement.
3. Informationstext über Apache 2 und Hinweise zu weiteren Informationsquellen
4. Voreinstellungen einiger Konfigurationsdaten: Geben Sie unter Network Domain Ihren Domainnamen ein, etwa »test.local« für einen nicht öffentlichen Testserver. Als Server Name müssen Sie den DNS-Namen des Servers selbst angeben, zum Beispiel »www.test.local«. Die Administrator’s E-Mail Address ermöglicht Benutzern den Versand einer Mitteilung über Serverfehler, da sie auf automatisch generierten Fehlermeldungsseiten angezeigt wird; üblich ist die Adresse webmaster@<Domain>. Auch für einen lokalen Test sollten Sie Apache als vollwertigen Produktionsserver (For All Users, on Port 80, as a Service) installieren.[Anm.: Falls auf Ihrem System bereits Microsoft Internet Information Services oder ein anderer Webserver installiert ist, der Port 80 belegt, müssen Sie den Port nach der Installation über die Konfigurationsdatei wechseln (siehe den nächsten Abschnitt).]
5. Wenn Sie Typical wählen, werden nur gängige Komponenten installiert. Custom ermöglicht dagegen die freie Auswahl, was zu bevorzugen ist.
6. Wenn Sie Custom ausgewählt haben, wird nun eine Baumansicht mit den möglichen Komponenten der Installation angezeigt. In der Regel können Sie einfach die Wurzel anklicken und die Option This Feature, and all subfeatures, will be installed on local hard drive einstellen; dies erfordert knapp 50 MByte Festplattenspeicher. Am unteren Rand wird das Verzeichnis gewählt; der Vorgabewert ist Apache Software Foundation im Verzeichnis Program Files oder Programme.
7. Wenn Sie doch noch etwas ändern möchten, können Sie nun auf Back klicken; andernfalls beginnt ein Klick auf Install mit der eigentlichen Installation.

Wenn Sie Apache als Dienst installiert haben (siehe Punkt 4), startet er automatisch. Zur Verwaltung des Dienstes können Sie den mitinstallierten Apache Service Monitor verwenden, der im Systray als kleines Federsymbol angezeigt wird. Mit der rechten Maustaste können Sie dieses Programm öffnen und Apache 2 steuern.

13.2.4 Apache-Konfiguration

Einstellungen für den Apache-Webserver werden in diversen Konfigurationsdateien vorgenommen. Bei Apache 2.0 befanden sich alle Einstellungen in der zentralen Datei httpd.conf, die standardmäßig unter /usr/local/apache2/conf (Unix) oder C:\Program Files\Apache Software Foundation\Apache2.2\conf (Windows) liegt.

Seit Apache 2.2 wurden einige Einstellungen dagegen in separate Dateien im Unterverzeichnis extra ausgelagert. Um sie zu aktivieren, müssen Sie das Kommentarzeichen (#) vor der jeweiligen Include-Direktive in der Konfigurationsdatei httpd.conf entfernen. Im Einzelnen handelt es sich um folgende Dateien:

• httpd-mpm.conf – Einstellungen für das jeweilige MPM, deren Änderung je nach Serverlast die Performance verbessern kann
• httpd-multilang-errordoc.conf – Fehlermeldungsseiten in unterschiedlichen Sprachen
• httpd-autoindex.conf – Einstellungen für automatisch generierte Verzeichnisseiten
• httpd-languages.conf – Zuordnung zusätzlicher Dateiendungen zu Inhaltssprachen für Content-Negotiation
• httpd-userdir.conf – benutzerspezifische Webverzeichnisse (http://servername/~username)
• httpd-info.conf – Veröffentlichung von Serverinformationen unter einer speziellen URL
• httpd-vhosts.conf – Konfiguration virtueller Hosts, das heißt verschiedener Websites für unterschiedliche Hostnamen oder IP-Adressen
• httpd-manual.conf – Veröffentlichung der Apache-Dokumentation unter dem URL-Pfad /manual
• httpd-dav.conf – Einstellungen für WebDAV (Web-based Distributed Authoring and Versioning), ein HTTP-basiertes Repository
• httpd-default.conf – optionale Standardeinstellungen für den Server
• httpd-ssl.conf – SSL-Konfiguration

Der mit Ihrer Distribution gelieferte Apache verwendet oft eine andere Dateiaufteilung. Mitunter hilft es dann auch nichts, diese Dateien direkt zu editieren, da ihr Inhalt durch distributionseigene Tools oder Konfigurationsdateien bestimmt wird.

Jede Apache-Konfigurationseinstellung (Direktive) hat das folgende Format:

Direktive Wert [Wert ...]

Außerdem existieren Container-Direktiven wie etwa <Directory> ... </Directory>, die die Wirkung der enthaltenen Apache-Direktiven auf bestimmte Verzeichnisse, Dateien oder andere Spezialwerte beschränken.

Wichtige Konfigurationsdirektiven

Es folgt eine Beschreibung der wichtigsten Apache-Direktiven. Für jede von ihnen wird das Modul mitgeteilt, das sie bereitstellt; core ist dabei kein Modul, sondern der immer verfügbare Funktionskern des Servers. Zudem erfahren Sie durch eine oder mehrere der nachfolgenden Abkürzungen diejenigen Kontexte, in denen eine Direktive stehen darf:

• S – Serverkontext
  Diese Direktive gilt serverweit.
• V – virtueller Host
  Die Direktive kann in einem <VirtualHost>-Container stehen und gilt dann nur für den betreffenden virtuellen Host.
• D – Verzeichnis-Kontext
  Die Direktive gilt für einen Verzeichnisbereich und darf sich in einem <Directory>-, <Location>- oder <Files>-Container befinden.
• H – .htaccess-Dateien
  Die Direktive darf in einer .htaccess-Datei stehen, über die Sie Konfigurationsdaten in die einzelnen Verzeichnisse der Website selbst auslagern können. .htaccess-Dateien werden nur benötigt, falls Sie bei einem Hoster Webspace angemietet haben oder umgekehrt virtuelle Hosts für andere User zur Verfügung stellen. Auf Ihrem eigenen Server sollten Sie dagegen alle Direktiven in die Datei httpd.conf beziehungsweise die mit ihr verknüpften Konfigurationsdateien schreiben.

Ausführlichere Informationen zu diesen Direktiven sowie zu allen anderen finden Sie in der Apache-Originaldokumentation (http://httpd.apache.org/docs/2.4) sowie in meinem Buch »Apache 2.4« (4. Auflage, Bonn 2012, Galileo Press). Zu diesem Buch gibt es auch eine Website mit einer umfangreichen Direktivenliste (http://buecher.lingoworld.de/apache2/dirs.php).

Die Werte mancher Direktiven sind Pfadangaben. Auch unter Windows müssen Sie in diesem Fall den Unix-Slash (/) als Pfadtrennzeichen verwenden. Falls Pfadangaben oder andere Werte Leerzeichen enthalten, müssen Sie sie in Anführungszeichen setzen.

• Alias URL-Pfad Verzeichnispfad

  Kontext: SV; Modul: mod_alias

  Ein Verzeichnispfad, der sich außerhalb der DocumentRoot (siehe im Folgenden) befindet, wird an der angegebenen Stelle in den URL-Pfad eingebunden. Beispiel:

  Alias /info /var/webdata/info
  
  

  Die Eingabe von »http://servername/info/...« liefert daraufhin die entsprechenden Inhalte aus dem Verzeichnis /var/webdata/info.

• Allow from all | IP-Adresse | Hostname

  Kontext: DH; Modul: mod_authtz_host

  Die traditionelle Art, Hosts anzugeben, denen der Zugriff auf eine bestimmte Ressource erlaubt wird. Als Wert hinter Allow from können Hostnamen, ganze IP-Adressen oder Teile von ihnen eingetragen werden; alternativ auch das Schlüsselwort all für jeden Host.

  Das folgende Beispiel erlaubt allen Hosts den Zugriff auf URLs unter http://servername/public:

  <Location /public>
     Order allow,deny
     Allow from all
  </Location>
  
  

  In Apache 2.4 wird diese Syntax zwar noch unterstützt, gilt aber als veraltet. Hier wird sie von dem Modul mod_access_compat bereitgestellt, während mod_authz_host keine eigenen Direktiven mehr definiert, sondern Require ip für IP-Adressen beziehungsweise Require host für Hostnamen verwendet.

  Die zuvor dargestellte Konfiguration wird für Apache 2.4 wie folgt angegeben:

  <Location /public>
     Require all granted
  </Location>
  
  

• AllowOverride None|All|Direktiventyp [Direktiventyp ...]

  Kontext: D; Modul: core

  Legt fest, welche Direktiven im aktuellen Kontext und in seinen Unterverzeichnissen durch .htaccess-Dateien überschrieben werden dürfen. Diese Direktive ist nur in <Directory>-Abschnitten erlaubt, nicht in <Location> oder <Files>. Eine Voreinstellung für alle Verzeichnisse kann in einem Container für das Wurzelverzeichnis, also

  <Directory />
      ...
  </Directory>
  
  

  vorgenommen werden.

  Die möglichen Werte sind:

  • None: Apache wertet im angegebenen Kontext keine .htaccess-Dateien aus; empfiehlt sich als Vorgabewert für /.
  • FileInfo: Direktiven für Dateitypen und -inhalte
  • Indexes: Direktiven für automatisch generierte Verzeichnisindizes
  • Limit: Direktiven zur Zugriffskontrolle, insbesondere Order, Allow und Deny
  • AuthConfig: Direktiven zur Authentifizierung
  • Options: Direktiven für Verzeichnisoptionen, zum Beispiel Options
  • All: alle bisher genannten sowie einige zusätzliche Direktiven
• AuthBasicProvider provider

  Kontext: DH; Modul: mod_auth_basic

  Gibt das Provider-Modul (mod_authn_*) an, das die Vergleichsdaten für die klartextbasierte Authentifizierung liefern soll. Hier ein Beispiel, das einfache Textdateien (Modul mod_authn_file) auswählt:

  AuthBasicProvider file
  
  

• AuthDigestProvider provider

  Kontext: DH; Modul: mod_auth_digest

  Wie AuthBasicProvider, allerdings für die verschlüsselte Digest-Authentifizierung

• AuthName Bereichsname

  Kontext: DH; Modul: core

  Bestimmt den Namen eines Authentifizierungsbereichs, den sogenannten Realm. Nach einmaliger erfolgreicher Anmeldung senden Browser die Anmeldedaten für denselben Realm innerhalb einer Sitzung automatisch. Außerdem zeigen Browser den Realm im Anmeldefenster an. Beispiel:

  AuthName "Privater Bereich"
  
  

• AuthType Basic | Digest

  Kontext: DH; Modul: core

  Legt fest, auf welche Weise ein Browser die Anmeldedaten an den Server senden soll: Basic steht für Klartext, Digest dagegen für MD5-Verschlüsselung. Letzteres ist natürlich sicherer, funktioniert aber nicht mit allen Provider-Modulen und bereitet sehr alten Browsern Schwierigkeiten.

• AuthUserFile Dateipfad

  Kontext: DH; Modul: mod_authn_file

  Gibt eine Textdatei an, in der sich Benutzerdaten zur Überprüfung bei der Anmeldung befinden. Für die Erzeugung solcher Dateien ist das im bin-Verzeichnis von Apache befindliche Kommandozeilentool htpasswd zuständig. Beispiel:

  # htpasswd [-c] .htuser username
  
  

  Nach dieser Eingabe wird zweimal nach dem neuen Passwort für den angegebenen Usernamen gefragt; daraufhin wird es verschlüsselt in der Datei .htuser im aktuellen Verzeichnis gespeichert. Die Option -c (»create«) muss zum Anlegen einer neuen Datei verwendet werden.

  In der Direktive wird der Dateipfad relativ zur ServerRoot (siehe im Folgenden) interpretiert, es sei denn, Sie geben einen absoluten Pfad an. Hier ein Beispiel, das die Datei .htuser aus dem Verzeichnis credentials im Apache-Installationsverzeichnis auswählt:

  AuthUserFile credentials/.htuser
  
  

  Aus Sicherheitsgründen sollte die angegebene Datei sich auf keinen Fall innerhalb des Website-Verzeichnisses selbst befinden. Falls Sie gemieteten Webspace verwenden und daher keine andere Möglichkeit haben, müssen Sie den Zugriff auf die entsprechende Datei ganz verbieten. Dies funktioniert in Apache 2.4 für den Dateinamen .htuser zum Beispiel so:

  <Files .htuser>
    Require all denied
  </Files>
  
  

  In den Versionen bis 2.2 wird dagegen folgende Variante verwendet:

  <Files .htuser>
      Order deny,allow
      Deny from all
  </Files>
  
  

• Deny from all|IP-Adresse|Hostname

  Kontext: DH; Modul: mod_authtz_host

  Traditionelle Art und Weise, den angegebenen Rechnern den Zugriff auf Ressourcen in dem Kontext zu verweigern, in dem die Direktive steht. Das folgende Beispiel untersagt zunächst allen Hosts den Zugriff auf den URL-Pfad /geheim und erlaubt anschließend den Zugriff vom lokalen Rechner aus:

  <Location /geheim>
     Order deny,allow
     Deny from all
     Allow from 127.0.0.1
  </Location>
  
  

  Für die Änderungen in Apache 2.4 beachten Sie bitte die Anmerkungen zur Direktive Allow. Das 2.4-Äquivalent zur eben dargestellten Konfiguration lautet:

  <Location /geheim>
    Require ip 127.0.0.1
  </Location>
  
  

• <Directory Verzeichnis> ... </Directory>

  Kontext: SV; Modul: core

  Umschließt Einstellungen für ein bestimmtes Verzeichnis der Website. Das folgende Beispiel verbietet .htaccess-Dateien auf dem gesamten Server (kann für einzelne Verzeichnisse aber wieder überschrieben werden):

  <Directory />
     AllowOverride None
  </Directory>
  
  

• DirectoryIndex Dateiname [Dateiname ...]

  Kontext: SVDH; Modul: mod_dir

  Gibt Namen für Startseiten an, das heißt für Dateien, nach denen Apache in der angegebenen Reihenfolge suchen soll, wenn nur ein Verzeichnis ohne konkreten Dateinamen angefordert wurde. Der Vorgabewert ist index.html; das folgende Beispiel erlaubt zusätzlich index.htm und index.php:

  DirectoryIndex index.html index.htm index.php
  
  

• DocumentRoot Verzeichnis

  Kontext: SV; Modul: core

  Das Wurzelverzeichnis der Website, dem der URL-Pfad / zugeordnet ist. Die Voreinstellung ist /htdocs im Apache-Verzeichnis.
  Unix-Standard:

  DocumentRoot /usr/local/apache2/htdocs
  
  

  Windows-Standard:

  DocumentRoot "C:/Programme/Apache Software Foundation/Apache2.2/htdocs"
  
  

• <IfModule Modul> ... </IfModule>

  Kontext: SVDH; Modul: core

  Direktiven in diesem Container werden nur dann ausgeführt, wenn das betreffende Modul verfügbar ist. Der Modulname wird so angegeben wie das erste Argument von LoadModule (siehe im Folgenden); für mod_mime wird beispielsweise mime_module geschrieben. Das folgende Beispiel, das so in der Original-Konfigurationsdatei steht, stellt nur dann die Startseite index.html ein, wenn mod_dir aktiv ist:

  <IfModule dir_module>
      DirectoryIndex index.html
  </IfModule>
  
  

• Listen [IP-Adresse:]Port

  Kontext: S; Modul: MPM-Module

  Bestimmt den TCP-Port, an dem Apache auf eingehende Clientverbindungen lauscht. Wenn eine IP-Adresse angegeben wird, gilt die Einstellung nur für die betreffende Netzwerkschnittstelle, ansonsten für alle. Standard:

  Listen 80
  
  

  Falls Apache an mehreren Ports lauschen soll, müssen mehrere Listen-Direktiven angegeben werden, zum Beispiel 443 für SSL-verschlüsselte Verbindungen.

• LoadModule Modulname Dateipfad

  Kontext: S; Modul: mod_so

  Module, die als Dynamic Shared Objects (DSOs) kompiliert wurden (unter Windows ist dies grundsätzlich der Fall), werden mithilfe dieser Direktive geladen und aktiviert. Der erste Parameter, der Modulname, entspricht dem Grundnamen mit angehängtem _module (zum Beispiel rewrite_module für mod_rewrite); der Dateipfad verweist meist auf eine .so-Datei im Verzeichnis modules relativ zur ServerRoot (siehe im weiteren Verlauf). Das folgende Beispiel lädt mod_autoindex:

  LoadModule autoindex_module modules/mod_autoindex.so
  
  

• <Location URL-Pfad> ... </Location>

  Kontext: SV; Modul: core

  Umschließt die Konfiguration für einen bestimmten URL-Pfad. Hier ein Beispiel, das für alle Dateien in Verzeichnissen unter der URL http://servername/info die Startseite start.html einstellt:

  <Location /info>
     DirectoryIndex start.html
  </Location>
  
  

• NameVirtualHost IP-Adresse[:Port]

  Kontext: S; Modul: core

  Konfiguriert eine IP-Adresse und/oder einen TCP-Port für den Einsatz namensbasierter virtueller Hosts, das heißt, dass bei Zugriffen auf diese Adresse oder diesen Port je nach Host-Header der Anfrage unterschiedliche Sites geliefert werden. Wenn alle Netzwerkschnittstellen angesprochen werden sollen, können Sie statt einer konkreten Adresse * benutzen. Um virtuelle Hosts einzurichten, müssen Sie anschließend mehrere <VirtualHost>-Container definieren, in denen die Direktive ServerName die unterschiedlichen möglichen Hostnamen angibt.

  Wichtig: Für die betreffende Adresse beziehungsweise den Port gibt es danach keinen »Hauptserver« mehr. Auch die bisherige Hauptserver-Konfiguration muss in einen <VirtualHost>-Container verschoben werden.

  In Apache 2.4 wurde diese Direktive ersatzlos gestrichen; der Server erkennt die Konfiguration anhand der <VirtualHost>-Container selbst.

  Hier zwei Beispiele:

  NameVirtualHost 196.23.17.42
  NameVirtualHost *:8080
  
  

• Options None|All|[+|-]Optionstyp [[+|-]Optionstyp ...]

  Kontext: SVDH; Modul: core

  Diese Direktive stellt Optionen für ein Verzeichnis ein. None deaktiviert alle Optionen, während All alle außer MultiViews einschaltet. Die verfügbaren Optionen sind:

  • Indexes: Wenn ein Verzeichnis angefordert wurde, wird die Startseite (DirectoryIndex) beziehungsweise der automatisch generierte Index geliefert.
  • FollowSymLinks: Falls die angeforderte URL ein symbolischer Link ist, wird deren Ziel geliefert.
  • SymLinksIfOwnerMatch: Verfolgt ebenfalls symbolische Links, aber nur, wenn der Eigentümer des Symlinks demjenigen der Zieldatei entspricht.
  • ExecCGI: CGI-Skripte werden ausgeführt.
  • Includes: Server Side Includes (SSI) werden ausgeführt.
  • IncludesNOEXEC: Aktiviert ebenfalls SSI, allerdings mit Ausnahme von #exec (Programmausführung) und #exec cgi (CGI-Ausführung).
  • MultiViews: Content-Negotiation wird automatisch anhand bestimmter Dateiendungen durchgeführt.

  In untergeordneten Kontexten stehen die speziellen Schreibweisen +Option und -Option zur Verfügung, um Optionen zu den Einstellungen des übergeordneten Kontextes hinzuzufügen beziehungsweise daraus zu entfernen.

• Order allow,deny | deny,allow

  Kontext: DH; Modul: mod_authtz_host

  Legt die Reihenfolge fest, in der Allow- und Deny-Direktiven ausgewertet werden. Der vordere Wert gilt dabei als Voreinstellung (meist mit dem Wert All), der hintere als Ausnahme von dieser Regel.

  Wichtig: In allow,deny beziehungsweise deny,allow darf kein Leerzeichen hinter dem Komma stehen.

  Hier ein Komplettbeispiel, das nur Rechnern aus dem Netzwerk 192.168.1.0/24 den Zugriff auf den URL-Pfad /intranet gestattet:

  <Location /intranet>
     Order deny,allow
     Deny from all
     Allow from 192.168.1
  </Location>
  
  

  In Apache 2.4 gilt Order zusammen mit Allow und Deny als veraltet; in der Beschreibung der Direktive Allow steht mehr dazu. Die entsprechende Konfiguration lautet hier folgendermaßen:

  <Location /intranet>
     Require ip 192.168.1
  </Location>
  
  

• Redirect [Status] URL-Pfad URL

  Kontext: SVDH; Modul: mod_alias

  Anfragen für den angegebenen URL-Pfad werden an die (externe) URL weitergeleitet. Das folgende Beispiel leitet alle Anfragen für http://servername/extern an entsprechende Ressourcen unter http://externerserver weiter:

  Redirect /extern http://externerserver
  
  

• Require user Username | group Groupname | valid-user

  Kontext: DH; Modul: core

  Gibt im Rahmen von Authentifizierungsdirektiven an, welche Benutzer (user) oder Gruppen (group) sich anmelden dürfen. valid-user steht für alle Benutzer aus der aktuellen Datenquelle, zum Beispiel dem AuthUserFile (siehe zuvor).

  In Apache 2.4 wird Require auch verwendet, um Clients anhand ihrer IP-Adressen (Require ip) beziehungsweise Hostnamen (Require host) den Zugriff zu erlauben beziehungsweise zu verweigern. Außerdem stehen verschachtelbare Require-Container zur Verfügung, um zu bestimmen, wie mehrere Require-Direktiven zusammenwirken sollen:

  • <RequireAll>...</RequireAll> ist eine logische Und-Verknüpfung, legt also fest, dass alle enthaltenen Require-Direktiven erfüllt sein müssen.
  • <RequireAny>...</RequireAny> ist dagegen logisches Oder, das heißt, mindestens eine der enthaltenen Require-Direktiven muss erfüllt sein.
  • <RequireNone>...</RequireNone> gilt nur als bestanden, wenn keine der enthaltenen Require-Direktiven zutrifft.
• Satisfy Any | All

  Kontext: DH; Modul: core

  Falls Authentifizierung und Zugriffskontrolle über Order/Allow/Deny für dasselbe Verzeichnis eingesetzt werden, gibt diese Direktive an, ob beide Kriterien erfüllt sein müssen (All) oder ob eines von ihnen genügt (Any). Der Vorgabewert ist All.

  In Apache 2.4 entfällt Satisfy, weil die Require-Container eine viel genauere Festlegung erlauben.

• ScriptAlias URL-Pfad Verzeichnispfad

  Kontext: SV; Modul: mod_alias

  Entspricht der Funktionsweise von Alias (siehe zuvor), betrachtet aber zusätzlich die Dateien im angegebenen Verzeichnis als CGI-Skripte. In der Standardkonfiguration gibt es ein Verzeichnis cgi-bin unter der ServerRoot (nicht etwa der DocumentRoot!), das als solches CGI-Verzeichnis dient. Der betreffende Eintrag sieht unter Unix so aus:

  ScriptAlias /cgi-bin /usr/local/apache2/cgi-bin
  
  

  Die Windows-Variante lautet:

  ScriptAlias /cgi-bin \
  "C:/Programme/Apache Software Foundation/Apache2.2/cgi-bin"
  
  

• ServerAdmin E-Mail-Adresse

  Kontext: SV; Modul: core

  Die E-Mail-Adresse des Serveradministrators, an die Benutzer Fehlermeldungen schicken können. Beispiel:

  ServerAdmin webmaster@test.local
  
  

• ServerName Domainname

  Kontext: SV; Modul: core

  Gibt den Domainnamen des Servers oder des virtuellen Hosts an. Beachten Sie, dass der Server in der Öffentlichkeit nur dann tatsächlich unter diesem Namen verfügbar ist, wenn entsprechende Nameserver-Einträge existieren. Die nötigen Einzelheiten zur Nameserver-Konfiguration werden im nächsten Kapitel erläutert. Beispiel:

  ServerName www.test.local
  
  

• ServerRoot Verzeichnispfad

  Kontext: S; Modul: core

  Dies ist das Stammverzeichnis, in dem Apache installiert wurde. Verzeichnisangaben in vielen Direktiven werden relativ zu diesem Wert interpretiert. Unter Unix wird standardmäßig der folgende Wert verwendet:

  ServerRoot /usr/local/apache2
  
  

  Hier zum Vergleich die übliche Windows-Voreinstellung:

  ServerRoot \
  "C:/Programme/Apache Software Foundation/Apache2.2"

• ServerSignature On|Off|E

  Kontext: SVDH; Modul: core

  Bestimmt die Fußzeile mit Informationen über den Server, den Hostnamen und eventuell die E-Mail-Adresse des Administrators. Die drei möglichen Werte sind: Off – keine Fußzeile; On – Fußzeile ohne E-Mail-Adresse (Beispiel: Apache/2.4.4 (Unix) Server at www.test.local Port 80); EMail – wie On, aber als Link auf die ServerAdmin-E-Mail-Adresse.

• ServerTokens Major|Minor|Minimal|ProductOnly|OS|Full

  Kontext: S; Modul: core

  Bestimmt, wie ausführlich die Serversoftware im Server-Header und auf automatisch generierten Seiten genannt wird. Angenommen, es handelt sich um Apache 2.4.4 auf einem Unix-System, dann lautet ProductOnly: Apache, Major: Apache/2, Minor: Apache/2.4, Minimal: Apache/2.4.4 und OS: Apache/2.4.4 (Unix). Full hängt noch die Selbstbeschreibungen diverser Module an, zum Beispiel Apache/2.4.4 (Unix) Dav/2 PHP/5.5.0.

• <VirtualHost Host[:Port]> ... </VirtualHost>

  Kontext: S; Modul: core

  Umschließt die Konfiguration eines virtuellen Hosts, der durch eine IP-Adresse, einen Hostnamen und/oder einen TCP-Port angegeben wird. Die zugehörigen Listen- und eventuellen NameVirtualHost-Direktiven müssen allerdings im Serverkontext stehen. Näheres über das komplexe Thema Virtual Hosts erfahren Sie in der Beschreibung dieser Direktive auf der Website zu meinem Buch »Apache 2«: http://buecher.lingoworld.de/apache2/showdir.php?id=757.

Konfigurationsbeispiele

Nachdem soeben diverse Apache-Direktiven vorgestellt wurden, sollten Sie sich einige von ihnen im größeren Konfigurationszusammenhang anschauen.

Als Erstes sollten restriktive Voreinstellungen für das Wurzelverzeichnis – und damit für jedes beliebige Verzeichnis – vorgenommen werden:

Für Apache 2.2 sieht der entsprechende Container so aus:

<Directory />
    # Alle Optionen ausschalten
    Options None
    # .htaccess ausschalten (f. Sicherheit & Performance)
    AllowOverride None
    # ALLE Zugriffe verbieten
    Order deny,allow
    Deny from all
</Directory>

Die DocumentRoot benötigt dagegen großzügigere Einstellungen, beispielsweise diese:

<Directory /usr/local/apache2/htdocs>
    # Einige Optionen aktivieren
    Options Indexes FollowSymLinks
    # Alle Zugriffe gestatten
    Require all granted
</Directory>

Hier die Variante für Apache bis einschließlich Version 2.2:

<Directory /usr/local/apache2/htdocs>
    # Einige Optionen aktivieren
    Options Indexes FollowSymLinks
    # Alle Zugriffe gestatten
    Order allow,deny
    Allow from all
</Directory>

Wenn Sie Aliasse verwenden, müssen Sie für die betreffenden Verzeichnisse übrigens auch derartige Angaben machen.

Hier ein etwas umfangreicheres Beispiel, das zwei namensbasierte virtuelle Hosts für den Port 8080 bereitstellt:

# An Port 8080 lauschen
Listen 8080

# Namensbasierte virtuelle Hosts für Port 8080 aktivieren
NameVirtualHost *:8080
# (in Apache 2.4 entfällt NameVirtualHost ersatzlos)

# Erster VHost, server1.test.local:8080
<VirtualHost *:8080>
    # ServerName, mit dem der Host-Header
    # einer Anfrage verglichen wird
    ServerName server1.test.local
    # Spezifische Webmaster-E-Mail-Adresse
    ServerAdmin webmaster@server1.test.local
    # Wurzelverzeichnis der Website
    DocumentRoot /var/www/vhosts/server1
    # Zugriffe auf dieses Verzeichnis erlauben
    <Directory /var/www/vhosts/server1>
        Options All
        Require all granted
        # Variante für Apache 2.2 (# entfernen):
        # Order allow,deny
        # Allow from all
    </Directory>
    # Fehler-Logdatei
    ErrorLog logs/server1.test.local-error_log
    # Zugriffs-Logdatei

    CustomLog logs/server1.test.local-access_log common
</VirtualHost>

# Zweiter VHost, server2.test.local:8080
<VirtualHost *:8080>
    ServerName server2.test.local
    ServerAdmin webmaster@server1.test.local
    DocumentRoot /var/www/vhosts/server1
    <Directory /var/www/vhosts/server1>
        Options All
        Require all granted
        # Variante für Apache 2.2 (# entfernen):
        # Order allow,deny
        # Allow from all
    </Directory>
    ErrorLog logs/server1.test.local-error_log
    CustomLog logs/server1.test.local-access_log common
</VirtualHost>

Je nachdem, ob ein Besucher eine Adresse unter http://server1.test.local:8080 oder unter http://server2.test.local:8080 eingibt, wird die gewünschte Ressource aus der jeweiligen DocumentRoot geliefert.

Um eine solche Konfiguration auf Ihrem lokalen Rechner zu testen, müssen Sie die entsprechenden Hostnamen in Ihrer /etc/hosts-Datei der lokalen IP-Adresse 127.0.0.1 zuweisen. Die entsprechende Zeile sieht dann beispielsweise wie folgt aus:

127.0.0.1 localhost server1.test.local server2.test.local

Als Nächstes sehen Sie hier ein vollständiges Beispiel für ein geschütztes Verzeichnis, dessen Inhalte Benutzer nur nach Anmeldung mit Benutzername und Passwort aufrufen dürfen. Die gewünschten Benutzerdaten müssen sich dabei in der htpasswd-Datei .htuser im Apache-conf-Verzeichnis befinden:

<Location /privat>
    # Klartextbasierte Übertragung der Anmeldedaten
    AuthType Basic
    # Anmeldedaten in einfacher htpasswd-Textdatei
    AuthBasicProvide file
    # Realm
    AuthName "Privater Bereich"
    # Pfad der htpasswd-Datei
    AuthUserFile conf/.htuser
    # Alle User aus der Datei haben Zutritt
    Require valid-user
</Location>

Dies akzeptiert alle Benutzer-Passwort-Kombinationen aus der Datei .htuser. Wenn ein User einen URL-Pfad aus diesem Verzeichnis anfordert, erhält sein Browser den Status 401 Unauthorized als Antwort und zeigt einen Anmeldedialog an. Wenn die Anmeldung innerhalb einer Sitzung einmal korrekt erfolgt ist, sendet der Browser bei weiteren Zugriffen auf denselben Bereich die Anmeldedaten automatisch.

Hier zu guter Letzt noch eine Standardkonfiguration für einen virtuellen Host unter dem SSL-Standardport 443. Anfragen, die an https://servername gesendet werden, erzeugen dadurch gesicherte Verbindungen und werden mit Dateien aus der DocumentRoot /var/www/secure beantwortet:

# An Port 443 (SSL-Standard) lauschen
Listen 443

# Die wichtigsten allgemeinen SSL-Voreinstellungen
# Standardverhalten bei der SSL-Serialisierung
# (geordnete Verarbeitungsreihenfolge)
SSLMutex default
# Den eingebauten Startwertalgorithmus für
# den Zufallsgenerator verwenden
SSLRandomSeed startup builtin
# Kein Cache für SSL-Sitzungsdaten
SSLSessionCache none

# Virtueller Host für Port 443
<VirtualHost *:443>
    # SSL-Funkitonalität einschalten
    SSLEngine On
    # Pfad zum Server-Zertifikat
    SSLCertificateFile conf/ssl/test.cert
    # Pfad zum Public Key des Server-Zertifikats
    SSLCertificateKeyFile conf/ssl/test.key
    # Pfad der gesicherten Website
    DocumentRoot /var/www/secure
</VirtualHost>

Das Zertifikat können Sie mithilfe von openssl erzeugen, müssen es für den Praxiseinsatz aber von einer anerkannten Zertifizierungsstelle durch eine digitale Signatur beglaubigen lassen, damit Browser es ohne Fehlermeldung akzeptieren. Eine solche Signatur kostet Geld; in der Regel ist es aber günstiger, sich dafür an Ihren Hoster zu wenden als direkt an eine Zertifizierungsstelle. Näheres zur Zertifikatserstellung und SSL-Konfiguration erfahren Sie auf der Webseite http://buecher.lingoworld.de/apache2/mod_ssl.html.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.