Apache/06 Grundkonfiguration/3 Allgemeine Direktiven

Apache2.4/06 Grundkonfiguration/3 Allgemeine Direktiven - Allgemeine Konfigurationsdirektiven

Beschreibung

In diesem Abschnitt werden die Direktiven behandelt, die für den grundlegenden Betrieb von Apache und einer einfachen Website aus statischen Dokumenten wichtig sind. Es handelt sich ausschließlich um solche Konfigurationsanweisungen, die zum Kern des Servers (core) gehören oder in MPM-Modulen beziehungsweise in solchen Modulen verfügbar sind, die standardmäßig zu Apache gehören und aktiviert sind.

Server-Umgebung

Wie bereits erwähnt, bilden die grundlegenden Programmeinstellungen den ersten Abschnitt der Datei httpd.conf. In der automatisch generierten Konfigurationsdatei einer normalen Apache-Installation bis 2.0 wurde der Abschnitt durch folgenden Kommentar charakterisiert:

1. 1. 1. Section 1: Global Environment
3. The directives in this section affect the overall operation
4. of Apache, such as the number of concurrent requests it can
5. handle or where it can find its configuration files.

Hier wird beispielsweise das grundlegende Verzeichnis wichtiger Server-Ressourcen (ServerRoot) festgelegt. Außerdem werden hier die DSO-Module geladen, und das grundlegende Verhalten des Servers bei der Verarbeitung von Anfragen wird konfiguriert. Die Direktiven werden hier in der Reihenfolge behandelt, in der sie in der Standarddatei stehen.

ServerRoot Stammverzeichnis der Apache-Installation; enthält unter anderem die Verzeichnisse conf/ und logs/

Modul core Kontext Server Syntax ServerRoot Pfad Standardwert PREFIX der Installation

Zahlreiche Pfade in der Apache-Konfiguration können relativ zu dem hier eingestellten Verzeichnis angegeben werden. Insbesondere die Verzeichnisse für die Konfigurationsdateien (conf/) und die Log-Dateien (logs/) müssen sich normalerweise unterhalb des hier eingestellten Verzeichnisses befinden. Welcher Wert hier eingestellt werden muss, variiert je nach Plattform und Installationslayout. In Kapitel 4, »Apache kompilieren und installieren«, finden Sie die passenden Angaben für verschiedene UNIX-Systeme und für Windows: Auf UNIX-Rechnern handelt es sich um das beim Kompilieren angegebene PREFIX, bei Windows um das übergeordnete Verzeichnis der Apache-Installation. Beispiele:

ServerRoot /usr/local/httpd # UNIX ServerRoot "C:/Programme/Apache Group/Apache2" # Windows

Beachten Sie, dass der Wert dieser Direktive (im Gegensatz zu zahlreichen anderen Konfigurationsanweisungen, deren Wert ein Verzeichnis ist) keinen abschließenden Slash enthalten darf.

TimeOut Wartezeit, bis die Verarbeitung einer Anfrage abgebrochen wird

Modul core Kontext Server Syntax TimeOut Sekunden Standardwert 300

Die Direktive TimeOut legt die Wartezeit für drei verschiedene Aspekte einer HTTP-Transaktion fest:

• die maximale Gesamtdauer einer GET-Anfrage
• die maximale Wartezeit zwischen zwei TCP-Paketen einer POST- oder PUTAnfrage
• die maximale Wartezeit zwischen zwei Empfangsbestätigungen (ACK) für TCPPakete der Server-Antwort

In der Regel gibt es keinen Grund, an den (recht großzügig) voreingestellten 300 Sekunden etwas zu ändern. Für zukünftige Apache-Versionen ist allerdings geplant, die drei Werte getrennt konfigurierbar zu machen. Siehe auch »RequestReadTimeout« auf Seite 259.

KeepAlive Persistente Verbindungen gemäß HTTP/1.1-Spezifikation

Modul core Kontext Server, <VirtualHost> Syntax KeepAlive On|Off Standardwert On

Diese Direktive regelt, ob Apache 2 grundsätzlich persistente HTTP-Verbindungen zulässt, also mehrere Anfragen über ein und dieselbe Verbindung abhandelt. Clients, die HTTP/1.1 verwenden, erwarten standardmäßig eine persistente Verbindung, HTTP/1.0-Clients dagegen nur, wenn sie den Header Connection: Keep-Alive senden. Es gibt im Allgemeinen keinen Grund, KeepAlive grundsätzlich abzuschalten. Für einzelne Clients, die damit Schwierigkeiten haben, können Sie über eine BrowserMatch-Direktive die Option nokeepalive setzen (siehe Kapitel 14, »CGI«).

MaxKeepAliveRequests Zulässige Höchstzahl von Anfragen über eine persistente Verbindung

Modul core Kontext Server, <VirtualHost> Syntax MaxKeepAliveRequests Anzahl Standardwert 100

Diese Direktive legt fest, wie viele aufeinanderfolgende HTTP-Anfragen über ein und dieselbe persistente HTTP-Verbindung abgehandelt werden. Der Wert 0 steht für beliebig viele Anfragen. Er sollte nicht verwendet werden, weil er möglicherweise die Gefahr von Denial-of-Service-Attacken erhöht. Ein relativ hoher Wert ist dagegen gut für die Server-Performance, da persistente Verbindungen besonders die Auslieferung von HTML-Dokumenten mit zahlreichen eingebetteten Bildern beschleunigen. Beispiel:

MaxKeepAliveRequests 200

KeepAliveTimeout Maximale Zeitspanne für nachfolgende Anfragen innerhalb einer persistenten Verbindung

Seit Version 1.x; Zeitangaben in Millisekunden seit 2.3.2 Modul core Kontext Server, <VirtualHost> Syntax KeepAliveTimeout Zeitwert[ms] Standardwert 15

Mithilfe dieser Konfigurationsanweisung können Sie festlegen, wie viele Sekunden Apache eine persistente Verbindung nach dem Abschluss einer Anfrage offen halten und auf eine weitere Anfrage warten soll. Es ist ein wenig schwierig, den richtigen Wert zu finden: Die Zeitspanne darf nicht zu kurz sein, weil sie persistente Verbindungen ansonsten in der Praxis verhindert, sie sollte aber auch nicht zu lang sein, damit der Server nicht zu stark durch unnütz offen gehaltene Verbindungen belastet wird. Die Voreinstellung von 15 Sekunden ist in der Regel in Ordnung – bei einem sehr beschäftigten Server sollten Sie allerdings einen kürzeren Wert wählen.

Seit Version 2.3.2 können Sie den Zeitwert auch in Millisekunden angeben. Dazu müssen Sie hinter der Zahl das Kürzel ms notieren. Beispiel:

KeepAliveTimeout 1500ms

RequestReadTimeout Timeouts für den Empfang von Anfrage-Header und -Body von Clients

Seit Version 2.2.15 Modul mod_reqtimeout Kontext Server, <VirtualHost> Syntax RequestReadTimeout [header=Timeout[-max.Timeout][,MinRate=Rate] [body=Timeout[-max.Timeout][,MinRate=Rate] Standardwert header=20-40,MinRate=500 body=20,MinRate=500

Seit Apache 2.2.15 ist das Modul mod_reqtimeout verfügbar, mit dem Timeouts und Mindestdatenraten für die Header und den Body einer Client-Anfrage gesetzt werden können. Das Modul definiert lediglich die Direktive RequestReadTimeout. Für die Header und den Body werden jeweils separate Werte angegeben. Es gibt drei mögliche Wertangaben:

• Ein numerischer Wert: Angabe des Gesamt-Timeout-Werts in Sekunden

• Zwei numerische Werte (m-n mit m < n): Der erste Wert gibt an, wie lange auf

den Beginn der Datenübertragung gewartet wird. Findet dieser innerhalb der angegebenen Zeit statt, tritt der zweite Wert als Timeout für die gesamte Datenübertragung in Kraft.

• Zusatzangabe MinRate=n: Nach dem Empfang von n Byte wird der TimeoutWert beziehungsweise der maximale Timeout-Wert um eine Sekunde erhöht.

Beispiele:

RequestReadTimeout header=5 body=20

Es wird maximal 5 Sekunden auf den Empfang des gesamten Headers und 20 Sekunden auf den Empfang des Bodys gewartet.

RequestReadTimeout header=5,MinRate=1000 \ body=20-40,MinRate=1000

Für den Header gelten 5 Sekunden, die pro 1.000 empfangenen Byte um eine Sekunde erhöht werden. Beim Body werden 20 Sekunden bis zum Beginn der Datenübertragung gewährt und insgesamt maximal 40 Sekunden; letztere werden wiederum pro 1.000 Byte um eine Sekunde erhöht.

RequestReadTimeout header=0 body=0

Deaktiviert die Funktionalität der Direktive – beispielsweise für einen VHost, bei dem Sie wissen, dass er mit besonders langsamen Clients zusammenarbeiten muss.

Listen TCP-Port (und IP-Adresse), an der der Webserver lauscht

Seit Version 1.x; seit 2.0 vorgeschrieben; Protokoll seit 2.1.5 Modul beos, mpm_netware, mpm_winnt, mpmt_os2, prefork, worker, event Kontext Server Syntax Listen [IP-Addr:]Port [Protokoll] Standardwert 80

Dies ist eine der wichtigsten Konfigurationsdirektiven. Sie bestimmt, an welchen TCP-Ports der Apache-Webserver auf eingehende Verbindungen lauscht. Da die TCP/IP-Implementierung trotz der APR-Abstraktionsschicht plattformspezifisch ist, wurde diese Direktive in den MPM-Modulen und nicht im core implementiert.

Wird nur ein TCP-Port angegeben, dann lauscht der Server über alle Netzwerkschnittstellen an diesem Port. Wenn Sie Verbindungen nur über bestimmte Schnittstellen zulassen möchten, können Sie vor dem Port, durch einen Doppelpunkt getrennt, eine IP-Adresse angeben. Anstelle IPv4-Adressen können übri

gens auch IPv6-Adressen verwendet werden; da diese Doppelpunkte enthalten, müssen sie zusätzlich in eckigen Klammern stehen, um sie korrekt von der Portangabe zu trennen. Wenn Ihr Server an mehreren Ports lauschen soll, müssen Sie mehrere Listen-Anweisungen untereinanderschreiben; die Direktive kann nur jeweils einen Wert haben. Wenn Sie ein anderes Protokoll verwenden möchten als das Standardprotokoll (zum Beispiel HTTP auf Port 80 oder HTTPS auf Port 443), dann können Sie es optional als zusätzlichen Parameter angeben.

Beachten Sie, dass Listen nur im Server-Kontext stehen darf. Wenn Sie virtuelle Hosts verwenden, müssen zunächst die IP-Adressen und Ports für den »Hauptserver« und alle virtuellen Hosts angegeben werden. Anschließend können Sie sie mithilfe von <VirtualHost>-Containern nach Wunsch aufteilen. Beispiele:

Listen 8080 http Listen 196.23.17.3:80 Listen [fe80::3a0:93a2:5a5b:3ab1]:80

Protocol Protokoll für ein lauschendes Socket festlegen

Seit Version 2.1.5 (für Windows seit 2.3.3) Modul core Kontext Server, <VirtualHost> Syntax Protocol Protokoll Standardwert nicht gesetzt

Wenn Sie HTTP oder HTTPS nicht auf den Standard-Ports (80 beziehungsweise 443) betreiben, können Sie mit Hilfe dieser Direktive das Protokoll für den aktuellen Kontext angeben. Dies dient der Auswahl des passenden Moduls und der Verarbeitung protokollspezifischer Optionen durch AcceptFilter. Das folgende Beispiel stellt https für einen Nicht-Standard-Port ein:

Protocol https

Alternativ kann das Protokoll auch über Listen eingestellt werden.

Mutex Allgemeine Methode für alle Serialisierungsaufgaben

Seit Version 2.3.4 Modul core Kontext Server

Syntax Mutex-Mechanismus Default|Methode [OmitPID] Standardwert Default

Manche Vorgänge in einem Webserver erfordern, dass sie nur jeweils einmal zur selben Zeit ausgeführt werden dürfen. Um dies sicherzustellen, wird ein MutexVerfahren verwendet (mutual exclusion, also gegenseitiger Ausschluss). Bis einschließlich Version 2.2 gibt es diverse Einzeldirektiven, die Mutex-Einstellungen für verschiedene Vorgänge vornehmen. In Version 2.3.4 wurde dann die zentrale Direktive Mutex eingeführt, die alle anderen Mutex-Direktiven ersetzt.

Der erste Parameter, der Mechanismus, bestimmt, für welchen der verschiedenen Anwendungsfälle Sie einen Mutex definieren möchten. Verfügbar sind zurzeit folgende (Drittanbieter-Module können jedoch zusätzliche MechanismusNamen definieren):

• mpm_accept (Module prefork und worker): Vermeidung des »ThunderingHerd«-Problems (donnernde Herde) beim Verbindungseingang; ersetzt die

veraltete, im vorliegenden Kapitel beschriebene Direktive AcceptMutex.

• authdigest_client (mod_auth_digest): Zugriff auf die Client-Liste im Shared

Memory (siehe Kapitel 9, »Authentifizierung, Autorisierung und Zugriffskontrolle«)

• authdigest_opaque (mod_auth_digest): Zugriff auf den Counter im Shared

Memory (Kapitel 9, »Authentifizierung, Autorisierung und Zugriffskontrolle«)

• ldap_cache (mod_ldap): Zugriff auf den Cache für LDAP-Abfrage-Ergebnisse

(Kapitel 9, »Authentifizierung, Autorisierung und Zugriffskontrolle«)

• rewrite_map (mod_rewrite): Vermeidung vermischter Ein-/Ausgabedaten

beim Zugriff mehrerer Anfragen auf externe RewriteMap-Programme (Kapitel 8, »Weiterleitungen und Indizes«)

• ssl_cache (mod_ssl): Zugriff auf den SSL-Session-Cache (Kapitel 10, »Gesicherte Verbindungen«)
• ssl_stapling (mod_ssl): Zugriff auf den OCSP-Stapling-Cache (Kapitel 10, »Gesicherte Verbindungen«)
• watchdog_callback (mod_watchdog): Callback-Funktion des jeweiligen ClientModuls (mod_watchdog ist ein neues Modul, das noch nicht dokumentiert

wurde, und wird daher in diesem Buch noch nicht beschrieben)

Der zweite Parameter ist die Mutex-Methode. In Versionen vor 2.0 konnte diese nur einmalig bei der Kompilierung angepasst werden. Das funktioniert in Versionen ab 2.0 noch immer. Die Flags, die Sie für den jeweiligen Wert beim Aufruf des configure-Skripts setzen müssen, werden bei den entsprechenden Angaben für die Direktive genannt:

• flock: Apache verwendet den Systemaufruf flock(), um eine Dateisperre auf

die mithilfe von LockFile definierte Datei zu errichten und später wieder aufzuheben. Um dies bei der Kompilierung als Standard zu setzen, müssen Sie configure mit folgender Option aufrufen:

CFLAGS="-D APR_USE_FLOCK_SERIALIZE"

• fcntl: Der Systemaufruf fctnl() wird benutzt, um die durch LockFile festgelegte Datei zu sperren und wieder zu entsperren.

configure: -D APR_USE_FCNTL_SERIALIZE

• posixsem: Apache verwendet mit POSIX kompatible Semaphore als Warteschlangen.

configure: -D APR_USE_POSIXSEM_SERIALIZE

• sysvsem: Es werden mit System V kompatible Semaphore als Warteschlangen

benutzt. Diese Einstellung wird zurzeit nur unter dem Betriebssystem IRIX verwendet.

configure: -D APR_USE_SYSVSEM_SERIALIZE

• sem: Es wird jeweils die »beste« verfügbare Semaphoren-Implementierung

ausgewählt, also je nach System entweder posixsem oder sysvsem. Einen eigenen configure-Wert hierfür gibt es logischerweise nicht.

• pthread: Apache benutzt POSIX-Mutexe, die der POSIX-Thread-Spezifikation

genügen.

configure: -D APR_USE_PTHREAD_SERIALIZE

• Default: Der bei der Kompilierung festgelegte Wert wird verwendet.

Zusätzlich können Sie noch das Schlüsselwort OmitPID angeben, um zu verhindern, dass die Prozess-ID des Parent-Prozesses an den Namen der Mutex-Datei angehängt wird.

AcceptFilter Optimierung für die lauschenden Sockets bestimmter Protokolle

Seit Version 2.1.5 Modul core Kontext Server Syntax AcceptFilter Protokoll Filter Standardwert nicht gesetzt

Unter einigen Betriebssystemen existieren spezielle Kernel-Filter, die die Performance von TCP/IP-Anwendungsprotokollen durch Pufferung verbessern können. In der Praxis sind dies die Accept-Filter von FreeBSD sowie die TCP_DEFER_ ACCEPT-Filter von Linux.

Die passenden Werte unter FreeBSD sind:

AcceptFilter http httpready AcceptFilter https dataready

httpready puffert die gesamte HTTP-Anfrage auf Kernel-Ebene und gibt sie erst dann an den Server weiter, wenn sie vollständig ist. Die Vollständigkeit von HTTPS-Anfragen kann der Kernel dagegen aufgrund der Verschlüsselung nicht erkennen; deshalb wird hier dataready verwendet. Näheres steht in den FreeBSD-Manpages zu accf_http(9) beziehungsweise accf_data(9).

Auf Linux-Systemen steht dagegen nur der Filter data zur Verfügung:

AcceptFilter http data AcceptFilter https data

Weitere Informationen über TCP_DEFER_ACCEPT liefert die Linux-Manpage zu tcp(7).

Für Protokolle, die vor dem Senden auf eine Server-Meldung warten, empfiehlt sich dagegen der Wert none – die Apache-Online-Dokumentation nennt als Beispiel NNTP:

AcceptFilter nntp none

LoadModule Das angegebene DSO-Modul laden und aktivieren

Modul mod_so Kontext Server Syntax LoadModule Modul Dateiname Standardwert nicht gesetzt

Wenn Sie einen Apache-Webserver mit DSO-Unterstützung betreiben (siehe Kapitel 4, »Apache kompilieren und installieren«) und ein DSO-Modul laden möchten, wird dazu die Direktive LoadModule verwendet. Sie benötigt zwei Parameter: einen kanonischen Modulnamen sowie den Pfad und Dateinamen des gewünschten Moduls. Der Dateiname hat jeweils das Format mod_xxx.so.2 Beim kanonischen Namen werden das Präfix mod_ und die Dateiendung .so weggelas

sen; dafür wird _module angehängt (z.B. xxx_module). Die Pfadangabe wird relativ zur ServerRoot interpretiert, falls sie keinen absoluten Pfad enthält. Das folgende Beispiel lädt das Modul mod_dir:

LoadModule dir_module modules/mod_dir.so

Bei manchen Modulen heißt die eigentliche DSO-Datei nicht mod_xxx.so, sondern anders. Dies ist beispielsweise bei PHP (siehe Kapitel 15, »Technologien zur Webprogrammierung«) der Fall:

LoadModule php5_module modules/libphp5.so

LoadFile Die angegebene Objektdatei oder Bibliothek laden

Modul mod_so Kontext Server Syntax LoadFile Dateiname [Dateiname ...] Standardwert nicht gesetzt

Einige Module benötigen Unterstützung durch zusätzliche Dateien. Eine solche externe Bibliothek oder Objektdatei wird mithilfe von LoadFile geladen. Sie können eine oder mehrere zu ladende Dateien angeben. Das folgende Beispiel lädt auf einem Windows-Rechner den Perl-Interpreter, der für das Modul mod_perl (siehe Kapitel 15, »Technologien zur Webprogrammierung«) benötigt wird, und anschließend mod_perl selbst:

LoadFile "C:/Perl/bin/perl58.dll" LoadModule perl_module modules/mod_perl.so

TraceEnable Bestimmt das Verhalten bei TRACE-Anfragen

Seit Version 1.3.34 und 2.0.55 Modul core Kontext Server Syntax TraceEnable on|off|extended Standardwert On

2 Unter Windows handelt es sich bei DSO-Modulen formal um DLL-Dateien. Trotzdem wurde seit Apache 1.3.15 auch auf dieser Plattform die Dateiendung .so eingeführt.

Diese Direktive ermöglicht es, das Verhalten von Apache bei HTTP-Anfragen mit der Methode TRACE, die eine Liste der zum Erreichen einer URL verwendeten Proxy-Server zurückgibt (siehe Kapitel 2, »Funktionsweise von Webservern«), zu modifizieren. Die Standardeinstellung on besagt, dass TRACE-Anfragen erlaubt sind, aber im Einklang mit RFC 2616 keinen Anfrage-Body enthalten dürfen. TraceEnable off verbietet TRACE-Anfragen ganz und sendet dem Client eine Antwort mit dem Status 405 Method not allowed.

Ein vom HTTP-Standard abweichendes Verhalten können Sie mit dem Wert extended erreichen: Die Anfragen dürfen einen Body enthalten. Dieser ist auf 64 Kilobyte beschränkt; hinzu kommen maximal 8 Kilobyte für Chunk-Header, wenn Transfer-Encoding: chunked verwendet wird. Diese Einschränkungen gelten nicht, wenn Apache als Proxy eingesetzt wird (siehe Kapitel 13, »Proxy- und Cache-Funktionen«). In diesem Modus gibt die Antwort im Body alle Header zurück. Diese Variante ist vor allem für Debugging- und Testzwecke geeignet.

Plattformspezifische Server-Einstellungen

Die Konfigurationsanweisungen in diesem Abschnitt betreffen ebenfalls das allgemeine Verhalten des Server-Programms. Sie sind allerdings nicht im Core, sondern in diversen MPM-Modulen definiert, weil sie nicht für alle Plattformen und Laufzeitmodelle von Apache festgelegt sind. Aufgrund ihrer besonderen Wichtigkeit wurde die Direktive Listen bereits im vorangegangenen Abschnitt behandelt, obwohl sie ebenfalls zu den MPM-Direktiven gehört.

Lesen Sie auch die Beschreibungen der diversen Multiprocessing-Module in Kapitel 3, »Apache 2 im Überblick«. Dort wird erläutert, auf welche Weise die MPMs Gebrauch von Prozessen und Threads machen. Dies verdeutlicht die Zusammenhänge zwischen den zahlreichen Direktiven, die deren Anzahl festlegen.

Beachten Sie, dass sich einige Direktiven in diesem Abschnitt nicht durch einen normalen Neustart von Apache 2 aktivieren lassen. Stattdessen müssen Sie dafür den Server komplett beenden und wieder starten. Dies betrifft vor allem die maximal konfigurierbaren Werte ServerLimit und ThreadLimit.

GracefulShutdownTimeout Wartezeit, nach der Apache bei graceful-stop auf jeden Fall beendet wird

Seit Version 2.2 Modul prefork, worker, event Kontext Server Syntax GracefulShutdownTimeout Sekunden Standardwert 0

Ein neues Feature von Apache 2.2 ist das saubere Beenden, das heißt, der Hauptprozess wird erst beendet, wenn die Worker-Prozesse oder -Threads mit dem Verarbeiten der aktuellen Anfragen fertig sind (siehe Kapitel 5, »Apache in Betrieb nehmen«). Diese Direktive bestimmt optional eine maximale Wartezeit in Sekunden; sobald diese erreicht ist, wird Apache sofort beendet. Der Vorgabewert 0 bedeutet, dass beliebig lange auf die Worker gewartet wird. Das folgende Beispiel legt eine Höchstdauer von zwei Minuten fest:

GracefulShutdownTimeout 120

PidFile Datei für die PID des Apache-Hauptprozesses

Modul beos, mpm_winnt, mpmt_os2, prefork, worker, event Kontext Server Syntax PidFile Dateiname Standardwert logs/httpd.pid

Diese Direktive bestimmt den Pfad der PID-Datei: Wie die meisten UNIX-Daemons legt auch der Apache-HTTP-Server die Prozess-ID (PID) seines Hauptprozesses in einer Datei ab, um beispielsweise bei einem Startbefehl zu kontrollieren, ob der Server noch läuft (oder unsauber beendet wurde). In Kapitel 5, »Apache in Betrieb nehmen«, wird erläutert, wie diese Datei auf einem UNIX-Rechner dazu verwendet werden kann, um Apache zu beenden oder neu zu starten.

Da nicht jedes Betriebssystem UNIX-artige PIDs verwendet und das Verfahren deshalb nicht auf jede beliebige Plattform portierbar ist, ist die Direktive nicht im core, sondern in den passenden MPM-Modulen definiert. Hier ein Beispiel:

PidFile /var/run/httpd.pid

Wenn kein absoluter Pfad angegeben wird, interpretiert Apache die Angabe relativ zur ServerRoot.

User UNIX-User-ID, unter der Apache Anfragen bearbeitet

Seit Version 1.x; seit 2.0 nur noch Server Modul prefork, worker, event; seit 2.3-beta mod_unixd Kontext Server Syntax User Username | #Usernr. Standardwert #-1

Die Direktive User funktioniert nur auf UNIX-Plattformen. Sie legt die User-ID fest, unter der Apache Client-Anfragen beantwortet. Das betrifft nicht den Hauptprozess, der für die Steuerung des Servers sowie für den Start der eigentlichen Arbeitsprozesse beziehungsweise -Threads zuständig ist – dieser läuft in der Regel unter der User-ID root.

Die User-ID kann entweder als Username oder numerisch angegeben werden. Wenn Sie eine Usernummer verwenden, muss diese hinter einer Raute stehen. Beispiele:

User htuser User #103

Per Voreinstellung läuft Apache 2 unter der User-ID -1. Dies entspricht auf den meisten Systemen dem User nobody. Normalerweise ist dies in Ordnung; nobody ist meist eine Benutzerkennung ohne Shell. Selbst wenn sich also jemand über eine Sicherheitslücke die Rechte des Webservers aneignen sollte, wird er es nicht allzu leicht haben, unter dieser User-ID Schaden anzurichten.

Noch besser ist es, einen separaten User nur für den Webserver-Betrieb einzurichten. Auch in diesem Fall sollten Sie darauf achten, dass sich unter diesem Benutzerkonto niemand persönlich anmelden kann – dies erreichen Sie auf vielen Betriebssystemen, indem Sie die Login-Shell des Kontos auf /bin/false setzen. Darüber hinaus sollte der User einer Group angehören, die ebenfalls exklusiv für den Einsatz von Apache eingerichtet wurde. Die beiden folgenden Befehle zur Erstellung einer solchen Group und eines Users sind für Linux geeignet und zeigen sinngemäß, wie es funktioniert:

1. groupadd htgroup
2. useradd -s /bin/false -g htgroup htuser

Anschließend müssen Sie die neu erstellte User- und Group-ID in der ApacheKonfigurationsdatei eintragen:

User htuser Group htgroup

Bitte beachten Sie, dass Sie User niemals auf root setzen sollten!

Group UNIX-Group-ID, unter der Apache Anfragen bearbeitet

Seit Version 1.x; seit 2.0 nur noch Server Modul beos, mpmt_os2, prefork, worker; seit 2.3-beta mod_unixd

Kontext Server Syntax Group Gruppenname | #Gruppennr. Standardwert #-1

Unter UNIX wird ein Prozess nicht nur unter einer User-ID, sondern auch unter einer Group-ID ausgeführt. Diese Direktive setzt die Group-ID, unter der die Prozesse zur Verarbeitung von Anfragen laufen – der Hauptsteuerprozess ist hier, genau wie bei User, nicht betroffen. Gültige Werte für Group sind entweder ein Groupname oder eine Raute mit nachfolgender numerischer ID. Die Verwendung der Group-ID root ist natürlich wiederum tabu. Hier zwei Beispiele:

Group htgroup Group #101

Auch für Group ist der Standardwert -1 (nobody). Bereits bei der Beschreibung von User wurde gezeigt, wie Sie eine separate Group für den Webserver anlegen können, um die Sicherheit noch weiter zu erhöhen.

ListenBackLog Gibt die maximale Länge der Warteschlange für eingehende Verbindungsanfragen an.

Modul beos, mpm_netware, mpm_winnt, mpmt_os2, prefork, worker, event Kontext Server Syntax ListenBackLog Anzahl Standardwert 511

Es wurde in diesem Buch bereits beschrieben, dass zur Verarbeitung eingehender Anfragen normalerweise immer ein gewisser Vorrat an Prozessen oder Threads (je nach MPM) vorhanden ist. Bei Spitzenbelastung des Servers kann es allerdings vorkommen, dass er die Reserve-Prozesse beziehungsweise -Threads nicht schnell genug erzeugt. Ist der Vorrat völlig aufgebraucht, dann werden weitere ankommende Anfragen in eine Warteschlange des lauschenden Sockets gestellt. Diese Direktive definiert die maximale Anzahl wartender Verbindungen in dieser Warteschlange. Sobald wieder Worker verfügbar sind, werden die Anfragen in Eingangsreihenfolge bearbeitet (FIFO-Prinzip).

Normalerweise brauchen Sie den voreingestellten Wert niemals anzupassen. Es kann höchstens angebracht sein, ihn kurzfristig massiv zu erhöhen, wenn Sie von einer SYN-Flood-Attacke betroffen sind (Überschwemmung durch eintreffende TCP-Pakete mit gesetztem SYN-Flag), damit die SYN-Flood-Pakete nicht den gesamten Vorrat für sich beanspruchen, was zum Denial of Service führt.

Der tatsächliche Maximalwert ist übrigens an die Kernel-Konstante SOMAXCONN gebunden, die angibt, wie viele Verbindungen ein lauschendes Socket überhaupt annehmen kann. Wenn für ListenBackLog ein Wert angegeben wird, der SOMAXCONN übersteigt, dann wird dieser ignoriert. Wie sich SOMAXCONN gegebenenfalls anpassen lässt, entnehmen Sie bitte der Dokumentation Ihres Betriebssystems.

AcceptMutex Methode zur Serialisierung von Child-Prozessen, die Anfragen an NetzwerkSockets annehmen

Version 2.0 bis 2.2 Modul prefork, worker, event Kontext Server Syntax AcceptMutex Default|Methode Standardwert Default

Die verschiedenen Worker-Child-Prozesse oder -Threads rufen für jedes lauschende Socket select() auf, um in Erfahrung zu bringen, ob an diesem Socket eine Verbindungsanfrage wartet. Gleichzeitige select()-Aufrufe könnten dazu führen, dass einer oder mehrere von ihnen blockieren. Deshalb bestimmt diese Direktive, auf welche Weise Apache dafür sorgt, dass sie select() nur nacheinander aufrufen.

In Version 2.3.4 wurde die allgemeine Direktive Mutex eingeführt (siehe Seite 261), sodass AcceptMutex und andere spezifische Mutex-Direktiven abgeschafft wurden. Die möglichen Werte entsprechen den in der Beschreibung von Mutex angegebenen Methoden.

CoreDumpDirectory Verzeichnis, in das Apache vor einem CoreDump zu wechseln versucht

Seit Version 2.0 Modul beos, mpm_winnt, prefork, worker, event Kontext Server Syntax CoreDumpDirectory Verzeichnis Standardwert je nach Installationslayout

Wenn ein schwerwiegender Fehler auftritt, können Programme unter einigen Betriebssystemen einen CoreDump (Hauptspeicherauszug) in eine Datei schrei

ben. Die Direktive gibt das Verzeichnis an, in dem der CoreDump abgelegt werden soll. Da die User-ID, unter der Apache ausgeführt wird, in der Regel keine Schreibrechte für die ServerRoot haben sollte, müssen Sie ein anderes Verzeichnis angeben, wenn Sie CoreDumps zu Debugging-Zwecken benötigen.

LockFile Pfad der Lock-Datei zur Serialisierung angenommener Anfragen

Modul prefork, worker Kontext Server Syntax LockFile Dateiname Standardwert logs/accept.lock

Wenn für AcceptMutex über eine der beiden Einstellungen flock oder fcntl eine Dateisperre verwendet wird, um die Socket-Zugriffe von Anfragen zu serialisieren, wird eine Datei benötigt, auf der die Sperre errichtet werden kann. Die Direktive LockFile legt diese Datei fest. Aus Sicherheitsgründen sollte sie sich nicht in einem öffentlich zugänglichen Verzeichnis unterhalb der ServerRoot befinden.

MaxClients (seit 2.3.13 MaxRequestWorkers) Höchstzahl von Child-Prozessen, die zur Verarbeitung von Anfragen gestartet werden

Modul beos, prefork, worker, event Kontext Server Syntax MaxClients Anzahl Standardwert je nach MPM verschieden

Diese Direktive legt die maximale Anzahl von Child-Prozessen beziehungsweise Threads fest, die Apache insgesamt zur Annahme von Client-Anfragen startet. Sie brauchen den hier festgelegten Wert nur dann zu erhöhen, wenn Sie durch Benchmarks oder Logfile-Auswertung feststellen sollten, dass Ihr Server mit der Anzahl der ankommenden Anfragen nicht zurechtkommt. Allerdings müssen Sie in diesem Fall zunächst die Direktive ServerLimit anpassen, um die maximal einstellbare Anzahl von Prozessen oder Threads zu erhöhen. Der Vorgabewert ist je nach MPM unterschiedlich:

• prefork: 256 Child-Prozesse
• worker, event: 16 (ServerLimit) x 25 (ThreadsPerChild)
• beos: 50 Threads

MaxMemFree Maximale Speichermenge, die die Speicherverwaltung ohne free()-Aufruf verwalten darf

Modul beos, mpm_netware, mpm_winnt, prefork, worker, event Kontext Server Syntax MaxMemFree KBytes Standardwert 0

Mithilfe dieser Direktive können Sie die Arbeitsspeichermenge begrenzen, über die die Hauptspeicher-Zuteilungsroutine des Servers verfügen darf, ohne mittels free() wieder Speicher freizugeben. Der Vorgabewert 0 bedeutet, dass keine Beschränkung existiert.

MaxRequestsPerChild (seit 2.3.9 MaxConnectionsPerChild) Maximale Anzahl von Anfragen, die ein Child-Prozess nacheinander abarbeitet

Modul mpm_netware, mpm_winnt, mpmt_os2, prefork, worker, event Kontext Server Syntax MaxRequestsPerChild Anzahl Standardwert meist 10000 (siehe Beschreibung)

Die Direktive bestimmt indirekt die Lebensdauer eines Worker-Prozesses, der für die Bearbeitung von Client-Anfragen zuständig ist: Nach der Verarbeitung der angegebenen Anzahl von Anfragen (beziehungsweise persistenten Verbindungen) wird der Prozess beendet. Dies ermöglicht ein allmähliches Verringern der Prozessanzahl, wenn die Anfragelast nachlässt.

Der spezielle Wert 0 bedeutet, dass die Lebensdauer eines Prozesses nicht eingeschränkt wird. Bei mpm_winnt und mpm_netware ist dieser Wert aufgrund der Plattformbesonderheiten voreingestellt.

MaxSpareThreads Maximale Anzahl von Reserve-Threads

Modul beos, mpm_netware, mpmt_os2, worker, event Kontext Server Syntax MaxSpareThreads Anzahl Standardwert je nach MPM verschieden

Diese Direktive legt bei Thread-basierten MPMs die Höchstzahl von ReserveThreads fest, die für die Verarbeitung einer Verbindung bereitstehen. Für die verschiedenen MPMs sind folgende Werte vorgegeben:

• worker, event: 250. Hier geht es um die Anzahl der Threads insgesamt. Der

Wert kann nicht kleiner als MinSpareThreads + ThreadsPerChild sein.

• mpm_netware: 100 (Gesamtzahl). Der Wert muss größer sein als

MinSpareThreads.

• beos: 50 (Gesamtzahl)
• mpmt_os2: 10 (Gesamtzahl)

MinSpareThreads Mindestzahl von Reserve-Threads

Modul beos, mpm_netware, mpmt_os2, worker, event Kontext Server Syntax MinSpareThreads Anzahl Standardwert je nach MPM verschieden

Die Direktive MinSpareThreads bestimmt bei Thread-basierten MPMs die Mindestzahl der Reserve-Threads. Wie bei MaxSpareThreads gibt es Unterschiede zwischen den Standardwerten der einzelnen MPM-Module:

• worker, event: Gesamtwert 75
• mpm_netware: insgesamt 10
• beos: 1 (Gesamtwert)
• mpmt_os2: Gesamtwert 5

ScoreBoardFile Pfad der Datei zur Koordination von Child-Prozessen

Modul mpm_common Kontext beos, mpm_winnt, prefork, worker, event Syntax ScoreBoardFile Dateiname Standardwert logs/apache_status

Ein ScoreBoardFile ist eine Datei, die zur Kommunikation zwischen Parent- und Child-Prozessen eingesetzt wird. Wenn die Direktive nicht in der Konfigurationsdatei steht, wird anstelle einer Datei ein Shared-Memory-Segment verwendet.

Solange Sie kein externes Modul verwenden, das explizit auf das ScoreBoard zugreifen muss, ist dies aus Performance- und Sicherheitsgründen zu bevorzugen.

SendBufferSize Größe des TCP-Sendepuffers

Modul beos, mpm_netware, mpm_winnt, mpmt_os2, prefork, worker, event Kontext Server Syntax SendBufferSize Bytes Standardwert 0

Die Größe des TCP-Sendepuffers wird auf den angegebenen Wert gesetzt. Die Voreinstellung 0 bedeutet, dass der Standardwert des zugrunde liegenden Betriebssystems verwendet werden soll. Das ist normalerweise in Ordnung. Es sei denn, Sie verwenden ein veraltetes Betriebssystem mit einer sehr schnellen Netzwerkverbindung – dann sollten Sie aus Performance-Gründen manuell einen höheren Wert angeben als die Systemvorgabe.

ReceiveBufferSize Größe des TCP-Empfangspuffers

Modul beos, mpm_netware, mpm_winnt, mpmt_os2, prefork, worker, event Kontext Server Syntax ReceiveBufferSize Bytes Standardwert 0

Diese Direktive stellt analog zu SendBufferSize die Größe des TCP-Empfangspuffers ein. Auch hier steht der Standardwert 0 für den Standard des Betriebssystems.

ServerLimit Absolute Höchstgrenze für die Anzahl von Prozessen

Modul prefork, worker Kontext Server Syntax ServerLimit Anzahl Standardwert je nach MPM verschieden

Diese Direktive legt den Höchstwert fest, der überhaupt für MaxClients (beziehungsweise NumServers beim MPM perchild) eingestellt werden darf. Für die einzelnen MPM-Module hat dies unterschiedliche Auswirkungen:

• prefork: Die Voreinstellung ist 256. Wenn Sie für MaxClients – bei diesem

MPM die Höchstzahl der Child-Prozesse insgesamt – einen höheren Wert einstellen möchten, müssen Sie zuerst ServerLimit auf diesen Wert setzen.

• worker, event: Der Standardwert ist 16 für die höchste einstellbare Anzahl von

Thread-verwaltenden Child-Prozessen. Die Gesamtzahl der Worker-Threads ist das Produkt von ServerLimit und ThreadsPerChild. Erhöhen Sie im Bedarfsfall einen dieser beiden Werte, wenn Sie insgesamt mehr Threads benötigen.

Wie bereits erwähnt, muss Apache komplett beendet und wieder gestartet werden, um diesen Wert anzupassen; ein automatischer Neustart genügt nicht.

Wenn Sie einen ungewöhnlich hohen Wert einstellen möchten, müssen Sie configure bei der Kompilierung mit dem Compiler-Flag HARD_SERVER_LIMIT aufrufen. Beispiel:

./configure ... CFLAGS="-D HARD_SERVER_LIMIT=2048"

StartServers Anzahl von Child-Prozessen, die beim Start erzeugt werden

Modul mpmt_os2, prefork, worker, event Kontext Server Syntax StartServers Anzahl Standardwert je nach MPM verschieden

Über diese Direktive wird festgelegt, wie viele Child-Prozesse beim Start des Servers erzeugt werden. Diese Anzahl wird zur Laufzeit gemäß den Angaben in den anderen Direktiven für die Prozessanzahl der Server-Last angepasst. Deshalb gibt es in der Regel wenig Veranlassung, die Voreinstellung zu ändern. Für die einzelnen MPMs gelten folgende Standardwerte:

• prefork: 5
• worker: 3
• mpmt_os2: 2

StartThreads Anzahl von Threads, die beim Start erzeugt werden

Modul beos, mpm_netware Kontext Server Syntax StartThreads Anzahl Standardwert je nach MPM verschieden

Bei den Thread-basierten MPMs beos und mpm_netware übernimmt diese Direktive die Aufgabe von StartServers: Sie bestimmt, wie viele Threads beim Start des Servers erzeugt werden. Da Apache bei Bedarf zusätzliche Threads startet, muss auch dieser Wert normalerweise nicht geändert werden. Hier die Standardwerte:

• mpm_netware: 50 (Gesamtzahl der gestarteten Threads)
• beos: 10 (ebenfalls insgesamt)

ThreadLimit Absolute Höchstzahl von Threads

Seit Version 2.0; für mpm_winnt seit 2.0.41 Modul mpm_winnt, worker, event Kontext Server Syntax ThreadLimit Anzahl Standardwert je nach MPM verschieden

Dieser Wert bestimmt die maximale Anzahl von Threads, die für ThreadsPerChild angegeben werden kann. Sie sollten die Direktive nur anpassen, wenn Sie den Wert von ThreadsPerChild erhöhen müssen. Um kein unnötiges Shared Memory zu vergeuden, sollte ThreadLimit keinen höheren Wert erhalten als den für ThreadsPerChild benötigten.

Der Standardwert ist für mpm_winnt 1.920 und für alle anderen MPMs 64. Der Quellcode enthält einen fest einprogrammierten Maximalwert von 20.000 (beziehungsweise 15.000 bei mpm_winnt).

Es wurde bereits darauf hingewiesen, dass der Server komplett beendet und wieder gestartet werden muss, um diesen Wert anzupassen.

ThreadsPerChild Anzahl der Threads pro Child-Prozess

Modul mpm_winnt, worker, event Kontext Server

Syntax ThreadsPerChild Anzahl Standardwert je nach MPM verschieden

Diese Direktive legt fest, wie viele Threads ein einzelner Verwaltungs-Child-Prozess startet. Dies hat je nach MPM unterschiedliche Folgen:

• worker, event: Bei diesen MPM-Modulen existieren mehrere Child-Prozesse.

Der Standardwert beträgt 25 und kann erhöht werden, wenn die Gesamtzahl der Worker (Child-Prozesse * Threads) für die Server-Last nicht ausreicht.

• mpm_winnt: Da unter Windows nur ein einziger Child-Prozess zur Verwaltung

der Worker-Threads existiert, muss der hier angegebene Wert der maximalen Anzahl gleichzeitiger Anfragen entsprechen, die der Server bewältigen muss. Die Voreinstellung liegt bei 64, und es ist wahrscheinlich, dass Sie sie für einen Produktionsserver erhöhen müssen.

MaxSpareServers Maximale Anzahl von Reserve-Child-Prozessen

Modul mpm_prefork Kontext Server Syntax MaxSpareServers Anzahl Standardwert 10

Diese Direktive bestimmt, wie viele unbeschäftigte Prozesse maximal als Reserve auf Anfragen warten sollen. Sollte die Anzahl über den hier eingestellten Wert hinausgehen, werden die überschüssigen Prozesse beendet.

Sie brauchen nur bei sehr stark beanspruchten Servern einen höheren Wert als voreingestellt. Wenn Sie einen Wert verwenden, der kleiner als MinSpareServers ist, wird er auf MinSpareServers +1 gesetzt.

MinSpareServers Mindestzahl von Reserve-Child-Prozessen

Modul mpm_prefork Kontext Server Syntax MinSpareServers Anzahl Standardwert 5

Mithilfe von MinSpareServers können Sie festlegen, wie viele unbeschäftigte Child-Prozesse mindestens als Reserve auf Client-Anfragen warten sollen. Wenn

weniger Prozesse frei sind als hier eingestellt, erzeugt Apache neue, und zwar höchstens einen pro Sekunde. In der Regel muss der Wert nicht geändert werden. Nur bei besonders belasteten Sites müssen Sie ihn möglicherweise erhöhen.

MaxRequestsPerThread Maximale Anzahl von Anfragen, die ein Thread nacheinander abarbeitet

Version 2.0 und 2.2 (nur BeOS) Modul mpm_beos Kontext Server Syntax MaxRequestsPerThread Anzahl Standardwert 0

Diese Direktive bestimmt unter BeOS indirekt die Lebensdauer eines Threads und ähnelt damit der für Prozesse zuständigen Einstellung MaxRequestsPerChild: Sie legt fest, wie viele Anfragen beziehungsweise persistente Verbindungen ein Thread verarbeitet, bevor er beendet wird. Wenn Sie die Voreinstellung 0 (unbegrenzte Lebensdauer) ändern, kann der Server schneller auf eine Verringerung der Anfragelast reagieren und so Ressourcen freigeben.

MaxThreads Maximale Anzahl von Worker-Threads

Seit Version 2.0 (nur NetWare) Modul mpm_netware Kontext Server Syntax MaxThreads Anzahl Standardwert 2.048

Diese Direktive ist nur unter Novell NetWare verfügbar. Sie bestimmt die maximale Anzahl von Threads, die Anfragen beantworten, und ähnelt so der für andere MPMs definierten Direktive ThreadsPerChild. Da der Standardwert dem einkompilierten Maximum entspricht, können Sie den Wert lediglich verringern.

ThreadStackSize Größe des Stacks pro Thread

Seit Version 2.0 (nur NetWare) Modul mpm_netware Kontext Server

Syntax ThreadStackSize Anzahl Standardwert 65.536

Mit dieser Direktive wird die maximale Größe des Stacks für einen einzelnen Thread festgelegt. Sie muss nur erhöht werden, falls ein Stack-Overflow auftreten sollte.

Win32DisableAcceptEx AcceptEx() deaktivieren, falls inkompatibel

Seit Version 2.0.49 bis 2.2.x Modul mpm_winnt Kontext Server Syntax Win32DisableAcceptEx Standardwert nicht gesetzt

Unter Windows wird standardmäßig die Winsock2-Funktion AcceptEx() verwendet, die gegenüber dem klassischen BSD-Systemaufruf accept() einen Performance-Gewinn liefert. Dies kann allerdings zur Inkompatibilität mit einigen anderen Programmen führen, z.B. mit VPN-Software oder Antivirus-Programmen. Ein solches Problem kann sich in einer Fehlermeldung wie dieser äußern:

[error] (730038)An operation was attempted on something that is not a socket.: winnt_accept: AcceptEx failed. Attempting to recover.

Wenn Sie diese Direktive (ohne Wert) in Ihre Konfigurationsdatei setzen, wird AcceptEx() deaktiviert. Sie sollten sie also verwenden, falls das geschilderte Problem bei Ihnen auftritt. Ab Apache 2.3 wird AcceptFilter für die entsprechenden Einstellungen verwendet.

Hauptserver

Der zweite Abschnitt der Konfigurationsdatei httpd.conf ist wie erwähnt für die Einstellungen der Standard-Website zuständig, die der Server veröffentlicht. Hier befinden sich also beispielsweise die DocumentRoot (das Basisverzeichnis) der Site sowie sämtliche Zugriffs- und Authentifizierungseinstellungen. In der offiziellen Vorlage der httpd.conf hieß es früher über diesen Abschnitt:

1. 1. 1. Section 2: 'Main' server configuration
3. The directives in this section set up the values used by the
4. 'main' server, which responds to any requests that aren't

1. handled by a <VirtualHost> definition. These values also
2. provide defaults for any <VirtualHost> containers you may
3. define later in the file.

Der »Hauptserver« behandelt nach dieser Beschreibung sämtliche Anfragen, für die kein spezieller virtueller Host konfiguriert ist. Außerdem werden alle hier vorgenommenen Grundeinstellungen zunächst von jedem virtuellen Host übernommen, sofern sie in dessen Konfiguration nicht überschrieben werden. Umgekehrt gilt natürlich, dass viele der hier vorgestellten Direktiven für einzelne virtuelle Hosts überschrieben werden können und oft sogar sollten.

ServerAdmin

E-Mail-Adresse des Server-Administrators für automatisch generierte Fehlermeldungsseiten

Modul core Kontext Server, <VirtualHost> Syntax ServerAdmin E-Mail-Adresse Standardwert nicht gesetzt

Wenn Apache bei der Beantwortung von Anfragen auf Probleme stößt, erzeugt er angepasste Fehlermeldungsseiten (festgelegt durch die Direktive ErrorDocument). Auf Wunsch kann eine solche Seite einen Link auf Ihre E-Mail-Adresse enthalten, damit Benutzer der Website Ihnen Probleme mitteilen können. Die Direktive ServerAdmin legt diese Adresse fest. Beispiel:

ServerAdmin webmaster@mynet.de

ServerName Hostname und TCP-Port des Servers

Seit Version 2.0 (früher Port) Modul core Kontext Server, <VirtualHost> Syntax ServerName voll.qualifizierter.domain.name [:Port] Standardwert nicht gesetzt

Mithilfe dieser Direktive wird der Domain-Name des Servers angegeben, optional gefolgt von einer TCP-Portnummer. Die Konfigurationsanweisung bestimmt nicht etwa, wie Listen, auf welche Anfragen Apache überhaupt reagiert. Sie legt den Server-Namen auch nicht nach außen fest – das funktioniert im Internet nur

über DNS. Der hier angegebene Name dient vielmehr der Selbstidentifikation des Servers. Ob er auch für selbst referenzierte URLs benutzt wird, regelt die Direktive UseCanonicalName.

Es ist auf jeden Fall wichtig, dass der festgelegte Name auf irgendeine Weise in eine IP-Adresse aufgelöst werden kann: bei einem öffentlich zugänglichen Produktionsserver natürlich über DNS; bei einem neu eingerichteten Server, den Sie testen möchten, können Sie den Namen dagegen in Ihre hosts-Datei eintragen (siehe Kapitel 5, »Apache in Betrieb nehmen«). Hier ein Beispiel:

ServerName www.mynet.de:80

UseCanonicalName Legt fest, woher der Server seinen eigenen Hostnamen für selbst referenzierte URLs erhält.

Modul core Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files> Syntax UseCanonicalName On|Off|DNS Standardwert Off (bis 2.0 On)

Bei Weiterleitungen, automatisch generierten Fehlermeldungsseiten und ähnlichen Gelegenheiten muss Apache selbst referenzierte URLs erzeugen, also absolute URLs, die wieder auf den Server-Host selbst zeigen. Diese Direktive bestimmt, wie der Host- beziehungsweise Domain-Name für diese URLs bestimmt wird. Es gibt drei mögliche Werte:

• On: Apache verwendet den Hostnamen und den Port, der mithilfe der Direktive ServerName festgelegt wurde.
• Off: Es werden der Hostname und der Port benutzt, die der Client in der

Anfrage übermittelt hat.

• DNS: Der Hostname wird durch einen Reverse-DNS-Lookup ermittelt, das

heißt, er erfragt über das Domain Name System den Hostnamen zur IPAdresse.

In der Regel ist die Einstellung On in Ordnung. Der Default-Wert wurde in Version 2.2 jedoch umgestellt, da On manchmal Probleme mit schlecht geschriebenen CGI-Skripten oder Webanwendungen bereitet, die für selbst referenzierte URLs nicht die Umgebungsvariable SERVER_NAME verwenden. Darüber hinaus kann Off nützlich sein, wenn die Clients im Intranet über einen anderen Hostnamen auf den Server zugreifen als diejenigen im Internet (z.B. www statt www.mynet.de), da die Intranet-Clients bei Weiterleitungen und ähnlichen Vor

gängen sonst auf den externen Domain-Namen www.mynet.de umgeleitet würden. DNS sorgt für Kompatibilität mit HTTP/1.0-Clients, die keinen Host-Header senden, und sollte eigentlich nur beim Einsatz IP-basierter virtueller Hosts verwendet werden, zumal der Reverse Lookup für Performance-Nachteile sorgt.

UseCanonicalPhysicalPort Legt fest, woher der Server die Portnummer für selbst referenzierte URLs erhält.

Seit Version 2.2 Modul core Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files> Syntax UseCanonicalPhysicalPort On|Off Standardwert Off

Wenn Sie diese Direktive auf On setzen, wird bei der Erzeugung selbst referenzierter URLs der tatsächliche, physische TCP-Port der Anfrage gewürdigt. Die genaue Reihenfolge zur Ermittlung des Ports hängt auch von der Einstellung der Direktive UseCanonicalName ab. Hat diese den Wert On, dann versucht Apache, den Port in folgender Reihenfolge zu bestimmen:

1. Port aus dem Wert von ServerName 2. Physischer Port 3. Standardport

Hat UseCanonicalName dagegen einen der Werte Off oder DNS, wird folgende Reihenfolge verwendet:

1. Port aus dem Host-Header 2. Physischer Port 3. Port aus dem Wert von ServerName 4. Standardport

Bei UseCanonicalPhysicalPort Off wird der physische Port nicht berücksichtigt; ansonsten bleibt die Reihenfolge je nach Einstellung für UseCanonicalName gleich.

ServerTokens Ausführlichkeit der Versionsangabe für den HTTP-Antwort-Header Server

Modul core Kontext Server

Syntax ServerTokens Major | Minor | Min[imal] | Prod[uctOnly] | OS | Full Standardwert Full

Diese Direktive legt fest, wie ausführlich der Apache-Webserver seine Versionsinformationen im HTTP-Antwort-Header Server und in der durch ServerSignature definierten Fußzeile automatisch generierter Dokumente angibt. Folgende Werte sind dafür definiert:

• Prod oder ProductOnly: Es wird nur der Programmname ausgegeben: Apache.
• Major: Die Hauptversionsnummer wird angegeben, z.B. Apache/2.
• Minor: Haupt- und Unterversionsnummer werden kombiniert, z.B. Apache/2.2.
• Min oder Minimal. Es werden Hauptversions-, Unterversions- und Releasenummer angegeben. Beispiel: Apache/2.2.10.
• OS: Die vollständige Versionsnummer wie bei Minimal wird angegeben, zusätzlich steht in Klammern die Systemplattform. Beispiel:

Apache/2.2.21 (UNIX)

• Full: Zusätzlich zur vollen Versionsnummer und zum Betriebssystem werden

die Versionsdaten wichtiger Zusatzmodule angezeigt. Beispiel: Apache/2.2.21 (UNIX) mod_perl/2.0.4 Perl/v5.10.0 PHP/5.3.8

In den meisten Fällen sollten Sie sich für Minimal oder OS entscheiden. Full verrät womöglich zu viele Details über die Server-Konfiguration.

Falls Sie sich allerdings Hoffnungen machen, durch die Veröffentlichung von weniger Informationen (im Extremfall ProductOnly) Angriffe auf Ihren Webserver abzuwehren, handelt es sich um einen Fall von »Security by Obscurity«: Durch Verschleierung der Softwareinfrastruktur soll Crackern die Arbeit erschwert werden. Dies beeindruckt allerdings höchstens ein paar automatisierte Angriffs-Tools, die von Anfängern verwendet werden.

Aus diesem Grund wird auch keine Direktive angeboten, die eine grundlegende Änderung der Server-Informationen ermöglicht. Wenn Sie möchten, dass Ihr Server sich unter falschem Namen meldet, müssen Sie die entsprechenden Daten vor der Kompilierung im Quellcode ändern. Die Definitionen befinden sich am Ende der Datei ap_release.h im Verzeichnis include der Source-Distribution und lauten in der aktuellen Version folgendermaßen:

1. define AP_SERVER_BASEVENDOR "Apache Software Foundation"
2. define AP_SERVER_BASEPRODUCT "Apache"
3. define AP_SERVER_MAJORVERSION "2"
4. define AP_SERVER_MINORVERSION "2"
5. define AP_SERVER_PATCHLEVEL "9"

Die Werte lassen sich natürlich beliebig ändern. Beispiel:

1. define AP_SERVER_BASEVENDOR "Sirius Cybernetics Corp."
2. define AP_SERVER_BASEPRODUCT "The Hitchhiker's Web Server"
3. define AP_SERVER_MAJORVERSION "3"
4. define AP_SERVER_MINORVERSION "1"
5. define AP_SERVER_PATCHLEVEL "42"

Wenn Sie Apache anschließend gemäß den Anweisungen aus Kapitel 4, »Apache kompilieren und installieren«, kompilieren, meldet er sich als The Hitchhiker's Web Server/3.1.42.

ServerSignature Fußzeile automatisch generierter Server-Dokumente

Modul core Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (All) Syntax ServerSignature On|Off|Email Standardwert Off

Diese Direktive legt fest, ob Apache in automatisch generierte Dokumente wie Index- oder Fehlermeldungsseiten eine Fußzeile einfügen soll, die Informationen über die Server-Software, den Hostnamen und eventuell die E-Mail-Adresse des Administrators enthält. Es gibt drei mögliche Werte:

• Off: Apache erzeugt keine Informationsfußzeile.
• On: Es wird eine Fußzeile ohne E-Mail-Adresse generiert. Beispiel:

Apache/2.2.10 (UNIX) Server at www.mynet.de Port 80

• EMail: Die Fußzeile sieht genauso aus wie bei On, allerdings ist der Hostname

gleichzeitig ein Hyperlink auf die unter ServerAdmin angegebene E-MailAdresse.

Der Hostname wird gemäß der Direktive UseCanonicalName angegeben. Seit Apache 2.0.44 bestimmt ServerTokens, wie ausführlich die Information über den Server ausfällt.

DocumentRoot Stammverzeichnis der Website

Modul core Kontext Server, <VirtualHost>

Syntax DocumentRoot Verzeichnis Standardwert variiert je nach Layout

Dies ist die wichtigste Konfigurationsanweisung für die Website des Hauptservers oder eines virtuellen Hosts: Sie legt das Basisverzeichnis fest, aus dem Apache die angeforderten Dokumente ausliefert. Das bedeutet, dass Pfadangaben aus der URL der Client-Anfrage an dieses Verzeichnis angehängt werden, um die gewünschte Ressource zu ermitteln. Angenommen, Sie haben DocumentRoot auf /usr/local/share/apache2/htdocs gesetzt (Standard beim GNU-Installationslayout; siehe Kapitel 4, »Apache kompilieren und installieren«). Wenn ein Client nun beispielsweise die URL http://www.mynet.de/info/news.html anfordert, liefert der Server die Datei /usr/local/share/apache2/htdocs/info/news.html aus – oder eine Fehlermeldung, falls das Dokument an der angegebenen Stelle nicht existiert. Beispiel:

DocumentRoot /usr/share/web

Mithilfe von Direktiven wie Alias oder UserDir (siehe Kapitel 8, »Weiterleitungen und Indizes«) können Sie übrigens auch solche Dateien und Verzeichnisse im Bereich der Website abbilden, die sich eigentlich außerhalb der DocumentRoot befinden.

DirectoryIndex Name der Indexseite

Modul mod_dir Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (Indexes) Syntax DirectoryIndex lokale_URL [lokale_URL ...] Standardwert index.html

Dies ist eine der beiden Direktiven, die das Standardmodul mod_dir zur Verfügung stellt. Sie definiert die Namen von Dokumenten, die Apache automatisch ausliefert, wenn anstelle einer Datei ein Verzeichnis angefordert wurde. Dies ist erforderlich, damit Benutzer einfach eine Website wie http://www.mynet.de/ anfordern können, anstatt den Namen der gewünschten Datei selbst anzugeben. Wenn Sie hier mehrere Dateien angeben, sucht Apache in der angegebenen Reihenfolge nach ihnen und liefert die erste aus, die er findet. Beispiel:

DirectoryIndex index.html index.html.var index.php

Ist eine Datei mit dem Namen index.html vorhanden, dann wird diese an den Client geliefert. Bei der Angabe index.html.var handelt es sich um eine TypeMap

(siehe Kapitel 7, »Header und MIME-Einstellungen«) – je nach Sprach- oder Zeichensatzpräferenz des Clients können auf diese Weise unterschiedliche Dateien serviert werden. Der Eintrag index.php ist interessant, wenn Sie mit PHP (siehe Kapitel 15, »Technologien zur Webprogrammierung«) arbeiten – auf diese Weise können auch PHP-Skripte als Indexdateien dienen.

Selbstverständlich braucht der Name vor der Dateiendung nicht unbedingt index zu lauten – wenn Sie z.B. von Microsoft Internet Information Services auf Apache umgestiegen sind, möchten Sie vielleicht lieber den bei Microsoft üblichen Dateinamen default.html weiterverwenden, um Ihre alte Website mit möglichst wenigen Änderungen zu übernehmen.

Übrigens können Sie in der Liste auch einen absoluten URL-Pfad angeben. Dieser sollte natürlich den letzten Eintrag bilden, damit die entsprechende Datei immer dann ausgeliefert wird, wenn das aktuelle Verzeichnis keine eigene Indexdatei enthält. Das folgende Beispiel weist Apache an, die Datei index.html im angeforderten Verzeichnis an die Clients zu liefern oder aber die Datei defaultindex.html in der DocumentRoot, falls index.html nicht existiert:

DirectoryIndex index.html /defaultindex.html

Auf Wunsch kann Apache auch automatisch einen Verzeichnisindex generieren – diese Funktion wird vom Modul mod_autoindex bereitgestellt, das in Kapitel 8, »Weiterleitungen und Indizes«, ausführlich beschrieben wird.

mod_dir und Verzeichnisanfragen

• Neben der Definition der Indexseite hat das Modul mod_dir übrigens auch noch die

wichtige Aufgabe, Anfragen umzuleiten, die ein Verzeichnis betreffen.

• Wenn eine Anfrage mit einer URL ohne abschließenden Slash eintrifft, behandelt

Apache diese normalerweise nicht als Anforderung eines Verzeichnisses. Angenommen, ein Client fordert die Ressource /test an. Der Server sucht daraufhin in der DocumentRoot nach einer Datei mit diesem Namen.

• Falls aber keine Datei, sondern nur ein Verzeichnis mit diesem Namen vorhanden

ist, geht es unterschiedlich weiter: Wenn mod_dir nicht aktiv ist, erhält der Client einfach die Fehlermeldung »404 Not Found«. Ist mod_dir dagegen geladen, wird eine Weiterleitung (301 Moved Permanently) gesendet, die einen Location-Header mit der kompletten URL einschließlich des Slashs enthält, in diesem Fall also z.B. http:// www.mynet.de/test/ (der Hostname wird gemäß der bereits beschriebenen Direktive UseCanonicalName gebildet). So gut wie alle Browser folgen dieser Weiterleitung automatisch. Wenn ein Client ein Verzeichnis mit abschließendem Slash anfordert, beispielsweise /test/, wird natürlich sofort dessen Index geliefert.

DirectorySlash Weiterleitung bei fehlendem Abschluss-Slash ein-/ausschalten

Seit Version 2.0.51 Modul mod_dir Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (Indexes) Syntax DirectorySlash On|Off Standardwert On

Diese Direktive erlaubt es Ihnen in Ausnahmefällen, die unter »mod_dir und Verzeichnisanfragen« soeben beschriebene Weiterleitung bei fehlendem Slash zu deaktivieren. Dazu müssen Sie im entsprechenden Kontext folgende Direktive setzen:

DirectorySlash Off

Da die URL ohne abschließenden Slash nun nicht mehr auf Inhalte verweist, könnte es sinnvoll sein, für diesen Kontext einen speziellen Handler zu setzen, der sich um die Beantwortung solcher Anfragen kümmert (siehe Kapitel 7, »Header und MIME-Einstellungen«).

AccessFileName Name der ausgelagerten Verzeichniskonfigurationsdatei

Modul core Kontext Server, <VirtualHost> Syntax AccessFileName Dateiname Standardwert .htaccess

Mithilfe dieser Direktive können Sie den Namen einer Datei angeben, die innerhalb eines Verzeichnisses der DocumentRoot zum Überschreiben von Konfigurationsdirektiven dient. Standardmäßig ist der Name dieser Datei .htaccess, und es gibt im Allgemeinen keinen Grund, dies zu ändern.3 Erlaubt ist jeder beliebige Dateiname – er sollte aber zumindest mit einem Punkt beginnen, um wenigstens einen geringfügigen Schutz zu gewährleisten. Beispiel:

AccessFileName .override

3 Wieder einmal ein Fall von »Security by Obscurity«, der allenfalls vor Skript-Kiddies schützt.

Vergessen Sie nicht, die Auslieferung von Dateien mit dem gewählten Namen an Clients generell zu deaktivieren:

<Files .override> Order Deny,Allow Deny from all </Files>

Wichtige Verzeichniseinstellungen

Auch die Konfigurationsanweisungen, die in diesem Abschnitt besprochen werden, gehören zur zweiten Abteilung der Datei httpd.conf. Der Unterschied besteht darin, dass sie üblicherweise innerhalb von <Directory>-Containern stehen, um die Einstellungen für die DocumentRoot und ihre Unterverzeichnisse sowie für einige andere Verzeichnisse festzulegen.

Hier werden zunächst alle entsprechenden Direktiven behandelt; im Anschluss daran finden Sie einige Beispiele für übliche Verzeichniskonfigurationen.

Options Verzeichnisoptionen

Modul core Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>, .htaccess (Options) Syntax Options All|[+|-]Option [[+|-]Option ...] Standardwert All

Die Direktive Options legt fest, welche besonderen Eigenschaften ein bestimmtes Verzeichnis (mitsamt seinen Unterverzeichnissen) besitzen soll. Das nähere Verhalten einiger dieser Optionen wird durch andere Direktiven geregelt; hier geht es zunächst einmal darum, ob eine bestimmte Eigenschaft grundsätzlich unterstützt werden soll oder nicht. Im Einzelnen sind folgende Optionen definiert, die Sie als Werte der Direktive angeben können:

• None: Schaltet sämtliche Optionen ab.
• Indexes: Wenn die angeforderte URL ein Verzeichnis ist, wird die mittels

DirectoryIndex festgelegte Indexdatei ausgeliefert oder – falls diese nicht vorhanden ist – ein durch mod_autoindex generierter Index.

• FollowSymLinks: Symbolische Links innerhalb des Verzeichnisses werden aufgelöst – Apache liefert das entsprechende Ziel des Links aus.

• SymLinksIfOwnerMatch: Symbolische Links werden nur dann verfolgt, wenn

der Eigentümer des SymLinks demjenigen der Zieldatei entspricht.

• ExecCGI: Innerhalb des Verzeichnisses soll die Ausführung von CGI-Skripten

gestattet sein: Dateien mit bestimmten Endungen oder MIME-Types werden von Apache als ausführbare Skripte betrachtet; ihre Ausgabe wird als dynamisch erzeugtes Dokument an den Client ausgeliefert. Es ist erheblich sicherer, über die Direktive ScriptAlias separate CGI-Verzeichnisse einzurichten und diese Option für Verzeichnisse innerhalb der DocumentRoot zu deaktivieren. Näheres zur CGI-Konfiguration erfahren Sie in Kapitel 14, »CGI«.

• Includes: Server Side Includes (siehe Kapitel 16, »SSI und Filter«) sind in diesem Verzeichnis gestattet.
• IncludesNOEXEC: Auch in einem Verzeichnis mit dieser Option sind SSI grundsätzlich erlaubt, allerdings mit Ausnahme von #exec (Programmausführung)

und #exec cgi (CGI-Ausführung).

• MultiViews: Aktiviert die Auslieferung alternativer Dokumente für unterschiedliche Sprach-, Zeichensatz- oder Dateityp-Präferenzen eines Clients

durch mod_negotiation. Näheres dazu finden Sie in Kapitel 7, »Header und MIME-Einstellungen«.

• All: Alle genannten Optionen außer MultiViews. Wenn Options für ein Verzeichnis nicht angegeben wird, ist dies der Standardwert.

Wenn Sie Optionen für mehrere ineinander verschachtelte Verzeichnisse festlegen, gelten für ein gegebenes Verzeichnis jeweils die speziellsten (für das am weitesten untergeordnete Verzeichnis angegebenen) Werte. Näheres zur Reihenfolge der Abarbeitung unterschiedlicher Container erfahren Sie in Abschnitt 6.2, »Kontexte und Container«. Das folgende Beispiel illustriert ein Missverständnis, das in diesem Zusammenhang auftreten kann:

<Directory /usr/share/web> Options FollowSymLinks Indexes IncludesNOEXEC

1. ... weitere Einstellungen für /usr/share/web

</Directory>

<Directory /usr/share/web/test> Options Includes

1. ... weitere Einstellungen für /usr/share/web/test

</Directory>

Im Verzeichnis /usr/share/web sind die Optionen FollowSymLinks, Indexes und IncludesNOEXEC aktiviert. Im Unterverzeichnis /usr/share/web/test gilt dagegen nur die Option Includes – das ist wahrscheinlich nicht das gewünschte Verhal

ten. Um Includes hinzuzufügen, anstatt die anderen Optionen durch Includes zu ersetzen, müssten Sie für /usr/share/web/test diese Variante angeben:

<Directory /usr/share/web/test> Options FollowSymLinks Indexes Includes

1. ... weitere Einstellungen für /usr/share/web/test

</Directory>

Natürlich können Sie die im übergeordneten Verzeichnis gesetzte Option IncludesNOEXEC hier zufälligerweise weglassen, da Includes deren Fähigkeiten enthält (und ausweitet).

Speziell für untergeordnete Verzeichnisse wird die spezielle Schreibweise +Option beziehungsweise -Option definiert: Damit lässt sich eine einzelne Option zu den bereits im übergeordneten Kontext gesetzten Optionen hinzufügen beziehungsweise hiervon entfernen. Mithilfe dieser Möglichkeit lässt sich das gerade zitierte Beispiel einfacher schreiben:

<Directory /usr/share/web> Options FollowSymLinks Indexes IncludesNOEXEC

1. ... weitere Einstellungen für /usr/share/web

</Directory>

<Directory /usr/share/web/test> Options +Includes

1. ... weitere Einstellungen für /usr/share/web/test

</Directory>

AllowOverride Festlegung der lokal überschreibbaren Konfigurationsdirektiven

Modul core Kontext <Directory> Syntax AllowOverride All|None|Direktiventyp [Direktiventyp ...] Standardwert All

Diese Direktive legt fest, welche Arten von Konfigurationsdirektiven in .htaccessDateien überschrieben werden dürfen. Da diese Dateien nur in Verzeichnissen innerhalb der DocumentRoot erlaubt sind, ist auch AllowOverride nur in <Directory>-Abschnitten gültig.

Es ist nicht möglich, die in .htaccess-Dateien gestatteten Direktiven einzeln anzugeben. Stattdessen definiert AllowOverride zahlreiche Gruppenbezeichnungen, die jeweils Konfigurationsanweisungen mit bestimmten Aufgaben zusammenfas

sen. Damit Sie genau wissen, welche das jeweils sind, finden Sie in diesem Buch bei der Übersicht jeder einzelnen Direktive, die den Kontext .htaccess besitzt, in Klammern den Wert, den AllowOverride beinhalten muss, um diese Direktive in einer .htaccess-Datei zuzulassen.

Hier die einzelnen Werte, die Sie mit Ausnahme von All und None beliebig mischen können:

• None: Im angegebenen Verzeichnis und in allen Unterverzeichnissen ohne

anderweitige Einstellung akzeptiert Apache gar keine .htaccess-Dateien.

• FileInfo: Ermöglicht das Überschreiben der Direktiven, die sich um Dateitypen und -inhalte kümmern.
• Indexes: Gestattet das Überschreiben von Direktiven zur automatischen

Erzeugung von Verzeichnisindizes (meist in mod_autoindex definiert).

• Limit: Diese Option erlaubt das Überschreiben der Direktiven Order, Allow

und Deny zur hostbasierten Zugriffskontrolle.

• AuthConfig: Wenn dieser Wert angegeben wird, dürfen alle Direktiven zur

Authentifizierung überschrieben werden (siehe Kapitel 9, »Authentifizierung, Autorisierung und Zugriffskontrolle«).

• Options: Ermöglicht das Überschreiben der bereits besprochenen Direktive

Options und anderer Verzeichnisoptions-Direktiven.

• All: Diese Einstellung gestattet die Verwendung aller bereits genannten Einzelgruppen sowie einiger zusätzlicher Direktiven.

Hier ein Beispiel:

<Directory /usr/local/share/apache2/htdocs> AllowOverride FileInfo Limit AuthConfig

1. ... weitere Einstellungen für die DocumentRoot

</Directory>

Näheres zu .htaccess-Dateien finden Sie in Abschnitt 6.2, »Kontexte und Container«.

Order Reihenfolge, in der Allow- und Deny-Direktiven beachtet werden

Modul mod_access_compat; bis 2.2.x: mod_authz_host; bis 2.0.x: mod_access Kontext <Directory>, <Location>, <Files>, .htaccess (Limit) Syntax Order Deny,Allow | Allow,Deny | Mutual-failure Standardwert Deny,Allow

Hinweis: Diese Direktive ist seit Version 2.3-beta veraltet; sie wurde durch zusätzliche Werte für die in Kapitel 9, »Authentifizierung, Autorisierung und Zugriffskontrolle«, besprochene Direktive Require ersetzt. Zurzeit wird sie aus Kompatibilitätsgründen noch im Modul mod_access_compat unterstützt, dürfte aber mittelfristig ganz abgeschafft werden.

Bis Version 2.2 ist diese Direktive allerdings äußerst wichtig. Order legt die Reihenfolge fest, in der die Regeln aus den Konfigurationsanweisungen Allow und Deny angewendet werden, die wiederum bestimmen, welche Hosts auf die entsprechende Ressource zugreifen dürfen.

• Deny,Allow: Diese Reihenfolge ist die Voreinstellung. Sie besagt, dass zuerst

die Deny-Liste und dann die Allow-Liste ausgewertet werden. Das bedeutet in der Praxis, dass die Regeln nach folgendem Schema ausgewertet werden: »Der Zugriff ist den angegebenen Hosts verboten mit den folgenden Ausnahmen: …« Die sinnvolle Verwendung setzt natürlich voraus, dass für Deny eine allgemeinere Angabe gemacht wird (vorzugsweise Deny from all) als für Allow. Wenn Sie keine weiteren Direktiven verwenden, ist der Standard bei dieser Einstellung Allow from all – alle Hosts dürfen zugreifen.

• Allow,Deny: Dies ist die umgekehrte Reihenfolge, die dafür sorgt, dass die

Allow-Liste vor der Deny-Liste ausgewertet wird. Mit anderen Worten: Der Zugriff wird zunächst den angegebenen (üblicherweise allen) Hosts gestattet, bevor er einer kleineren Anzahl verboten wird. Das Standardverhalten ist in diesem Fall Deny from all, das heißt, alle müssen zunächst draußen bleiben.

• Mutual-failure: veraltetes Synonym für Allow,Deny

Bitte beachten Sie, dass zwischen den Aufzählungen Deny,Allow und Allow,Deny kein Leerzeichen nach dem Komma stehen darf.

Allow Bestimmt, welche Hosts auf einen Site-Bereich zugreifen dürfen.

Modul mod_access_compat; bis 2.2.x: mod_authz_host; bis 2.0.x: mod_access Kontext <Directory>, <Location>, <Files>, .htaccess (Limit) Syntax Allow from all | Host | env=Umgebungsvariable [Host | env=Umgebungsvariable ...] Standardwert nicht gesetzt

Hinweis: Diese Direktive ist seit Version 2.3-beta veraltet; sie wurde durch zusätzliche Werte für die in Kapitel 9, »Authentifizierung, Autorisierung und Zugriffskontrolle«, ersetzt. Zurzeit wird sie aus Kompatibilitätsgründen noch im Modul mod_access_compat unterstützt, dürfte aber mittelfristig ganz abgeschafft werden.

Bis Apache 2.2 legt die Direktive Allow fest, wer auf eine bestimmte Ressource des Servers zugreifen darf. Die Werte können eines der folgenden Formate annehmen:

• All

Grundsätzlich darf jeder Host auf die Inhalte des Kontextes zugreifen, in dem die Direktive definiert ist. Die entsprechende Apache-2.4-Schreibweise lautet:

Require all granted

• Domain-Name

Bezeichnet Hosts, deren Name der angegebenen Domain und ihren Subdomains entspricht. Apache führt zur Ermittlung des Hostnamens eines zugreifenden Rechners zunächst einen Reverse-DNS-Lookup durch, um den zur IPAdresse gehörenden Hostnamen zu ermitteln. Anschließend wird zur Sicherheit noch einmal ein Forward-Lookup ausgeführt, um sicherzugehen, dass der Hostname wiederum der IP-Adresse entspricht. Die DNS-Lookups finden in diesem Fall auch dann statt, wenn HostNameLookups (siehe Kapitel 11, »Logging«) deaktiviert ist. Betrachten Sie das folgende Beispiel:

Allow from office.mynet.de

Client-Rechner aus den Subdomains office.mynet.de und billing.office.mynet.de dürfen zugreifen, während Clients aus der Domain sales.mynet.de der Zugriff verweigert wird. Die 2.4-Variante ist:

Require host office.mynet.de

• Vollständige IP-Adresse

Ein solcher Wert gibt die IP-Adresse eines einzelnen Hosts an, der auf den Server zugreifen darf. Beispiel:

Allow from 196.17.8.3

Schreiben Sie für Apache 2.4 stattdessen:

Require ip 196.17.8.3

Wenn Sie in einem Bereich Ihrer Website (oder auf dem ganzen Server) zu Testzwecken nur Zugriffe durch den lokalen Rechner selbst gestatten möchten, müssen Sie im entsprechenden Kontext folgende Direktivenfolge verwenden:

Order Deny,Allow Deny from all Allow from 127.0.0.1

In 2.4 funktioniert es folgendermaßen:

Require ip 127.0.0.1

• Unvollständige IP-Adresse

Wenn Sie Zugriffe auf ein bestimmtes IP-Teilnetz beschränken möchten, genügt es oft, den gemeinsamen Netzwerkteil der entsprechenden IP-Adressen anzugeben. Das folgende Beispiel erlaubt Zugriffe aus dem Netz 196.17.8.0/24:

Allow from 196.17.8

Apache 2.4:

Require ip 196.17.8

• CIDR-Adresse

Sie können ein Teilnetz auch nach der CIDR-Logik angeben (siehe Kapitel 1, »TCP/IP-Netzwerke, Internet und WWW«). Wenn die Grenze zwischen Netzwerk- und Hostteil im gewünschten IP-Teilnetz nicht genau an einer ByteGrenze liegt, ist dies sogar erforderlich. Dieses Beispiel gestattet Zugriffe aus dem Teilnetz 160.76.32.0/19 (Adressbereich 160.76.32.0 bis 160.76.63.255):

Allow from 160.76.32.0/19

Version 2.4:

Require ip 160.76.32.0/19

• IP-Adresse/Teilnetzmaske

Dies ist eine alternative Schreibweise für CIDR-Adressen. Beispielsweise können Sie das Netzwerk 160.76.32.0/19 auch folgendermaßen angeben:

Allow from 160.76.32.0/255.255.224.0

Ab 2.3-beta:

Require ip 160.76.32.0/255.255.224.0

• env=Umgebungsvariable

Diese spezielle Form erlaubt Zugriffe nur dann, wenn die angegebene Umgebungsvariable gesetzt ist. Sinnvoll ist dieses Verfahren im Zusammenhang mit der Direktive SetEnvIf (siehe Kapitel 14, »CGI«). Diese setzt eine Variable, wenn die Client-Anfrage eine bestimmte Bedingung erfüllt. Das folgende Beispiel erlaubt den Zugriff nur, wenn das Referer-Feld der Client-Anfrage mit

http://www.mynet.de beginnt, das heißt, wenn die aktuelle Anfrage durch einen Hyperlink von der eigenen Website aus zustande kam:

SetEnvIf Referer "^http://www.mynet.de" locallink Order Deny,Allow Deny from all Allow from env=locallink

Dies ist eine mögliche Methode, um Gefahren durch Cross-Site-Scripting zu verringern. Ab Version 2.3 kann folgende Variante verwendet werden:

SetEnvIf Referer "^http://www.mynet.de" locallink Require env locallink

Oder sogar noch kürzer:

Require expr "%{HTTP_REFERER} =~ m#^http://www.mynet.de"

Deny Legt fest, welche Hosts nicht auf einen Site-Bereich zugreifen dürfen.

Modul mod_access_compat; bis 2.2.x: mod_authz_host; bis 2.0.x: mod_access Kontext <Directory>, <Location>, <Files>, .htaccess (Limit) Syntax Deny from all | Host | env=Umgebungsvariable [Host | env=Umgebungsvariable ...] Standardwert nicht gesetzt

Hinweis: Diese Direktive ist seit Version 2.3-beta veraltet; sie wurde durch zusätzliche Werte für die in Kapitel 9, »Authentifizierung, Autorisierung und Zugriffskontrolle«, ersetzt. Zurzeit wird sie aus Kompatibilitätsgründen noch im Modul mod_access_compat unterstützt, dürfte aber mittelfristig ganz abgeschafft werden.

Die Syntax von Deny ist mit Allow identisch. Die Direktive bestimmt, welche Hosts vom Zugriff auf eine Server-Ressource ausgeschlossen sind. In welcher Reihenfolge Allow und Deny ausgewertet werden, regelt die bereits besprochene Direktive Order.

Das folgende Beispiel verbietet zunächst einmal allen Hosts den Zugriff und erlaubt ihn anschließend Hosts aus den Domains office.mynet.de und external.mynet.de:

Order Deny,Allow Deny from all Allow from office.mynet.de external.mynet.de

In Apache 2.4 genügt dazu folgende Zeile:

Require host office.mynet.de external.mynet.de

Dieses Beispiel erlaubt dagegen allen Hosts den Zugriff, die nicht zur Domain unsere-konkurrenz.de4 gehören:

Order Allow,Deny Allow from all Deny from unsere-konkurrenz.de

In Versionen ab 2.3-beta können Sie dies folgendermaßen ausdrücken:

<RequireAll> Require all granted Require not host unsere-konkurrenz.de </RequireAll>

AllowMethods Legt fest, welche HTTP-Zugriffsmethoden in einem bestimmten Kontext erlaubt sind.

Seit Version 2.3 Modul mod_allowmethods Kontext <Directory>, <Location>, <Files> Syntax AllowMethod HTTP-Methode [HTTP-Methode ...] Standardwert nicht gesetzt

Das neue Modul mod_allowmethods stellt die Direktive AllowMethods zur Verfügung. Diese ermöglicht innerhalb eines Verzeichniskontextes die Angabe der HTTP-Anfragemethoden, mit denen Benutzer auf die Ressourcen innerhalb des Verzeichnisses zugreifen dürfen. Dies ist einfacher als mit <Limit>-Containern, aber zurzeit gilt das Modul noch als experimentell.

Das folgende Beispiel erlaubt im aktuellen Kontext die Methoden GET, POST und HEAD:

AllowMethods GET POST HEAD

4 Natürlich nützt das in dieser Form nichts, weil die normalen Büro-PCs der auszuschließenden Konkurrenzfirma wahrscheinlich mit temporären IP-Adressen und Domain-Namen wie xdsl-client-08-15.t-online.de im Netz unterwegs sind. Überdies könnten Sie rechtliche Probleme bekommen (unlauterer Wettbewerb), wenn Sie die Konkurrenz explizit vom Zugriff auf Seiten ausschließen, die ansonsten für alle Welt zugänglich sind.

Voreinstellung für alle Verzeichnisse Aus Sicherheitsgründen sollten Sie – wie in einigen speziellen Zusammenhängen bereits erwähnt – zunächst einmal Einstellungen für das Wurzelverzeichnis (/) vornehmen. Sämtliche Zugriffe und Optionen sollten hier verboten werden. Diese Einstellungen werden von allen unspezifizierten Verzeichnissen sowie allen <Directory>-, <Files>- und <Location>-Containern automatisch übernommen. Anschließend können Sie für einzelne untergeordnete Ressourcen jeweils die benötigten Optionen freischalten.

Ein üblicher Grundeinstellungs-Container sieht beispielsweise so aus:

<Directory />

1. Alle Optionen deaktivieren

Options None

1. Sämtliches Überschreiben durch .htaccess dekativieren

AllowOverride None

1. Zugriffe aller Clients verbieten

Require all denied

1. Bis 2.2 werden statt "Require all denied"
2. folgende zwei Zeilen verwendet:
3. Order Deny,Allow
4. Deny from all

</Directory>

Die vorgefertigte Konfigurationsdatei enthält normalerweise nicht die Angabe Options None, sondern Options FollowSymLinks. Auf einem Server, den Sie allein verwalten, ist dies kein großes Problem, da Sie selbst entscheiden können, welche symbolischen Links Sie überhaupt anlegen möchten. Andererseits schadet es auch nichts, FollowSymLinks global zu deaktivieren und dann zusammen mit den anderen Optionen jeweils im Einzelfall einzuschalten.

Sinnvolle Einstellungen für die DocumentRoot Die DocumentRoot bildet, wie erwähnt, das Wurzelverzeichnis der Website, die Apache ausliefert, wenn kein virtueller Host angesprochen wurde. Für dieses Verzeichnis müssen Sie demzufolge einige Einstellungen der globalen Verzeichniskonfiguration überschreiben, um die Website im Internet zu veröffentlichen. Hier zunächst ein typisches Beispiel:

<Directory /usr/local/share/apache2/htdocs> Options Indexes FollowSymLinks MultiViews AllowOverride None Require all granted

1. Bis 2.2 folgende zwei Zeilen anstelle von "Require all granted":
2. Order allow,deny
3. Allow from all

</Directory>

Bei dieser Konfiguration sind die Optionen Indexes, FollowSymLinks und MultiViews eingeschaltet. Wenn Sie mit Server Side Includes arbeiten möchten (siehe Kapitel 16, »SSI und Filter«), müssen Sie zusätzlich Includes aktivieren. Für CGI sollte dagegen in der Regel nicht ExecCGI verwendet werden, sondern ein per ScriptAlias in die DocumentRoot abgebildetes cgi-bin-Verzeichnis (Genaueres dazu in Kapitel 14, »CGI«).

Die Verwendung von .htaccess-Dateien wurde hier ebenfalls abgeschaltet. In Abschnitt 6.2, »Kontexte und Container«, wurde bereits begründet, warum dies in den meisten Fällen ratsam ist.

Zu guter Letzt wurde der Zugriff auf die Site für beliebige Hosts gestattet.

Anhang

Siehe auch

• Apache/06 Grundkonfiguration/3 Allgemeine Direktiven
• Apache/06 Grundkonfiguration/3 Allgemeine Direktiven/Hauptserver
• Apache/06 Grundkonfiguration/3 Allgemeine Direktiven/Server-Umgebung
• Apache/06 Grundkonfiguration/3 Allgemeine Direktiven/Verzeichnis