|
|
| (23 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''Apache2.4/06 Grundkonfiguration/3 Allgemeine Direktiven''' - Allgemeine Konfigurationsdirektiven | | '''Apache/06 Grundkonfiguration/3 Allgemeine Direktiven''' - Allgemeine Konfigurationsdirektiven |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| In diesem Abschnitt werden die Direktiven behandelt, die für den grundlegenden Betrieb von Apache und einer einfachen Website aus statischen Dokumenten
| | Direktiven 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
| | * Es handelt sich ausschließlich um solche Konfigurationsanweisungen, die zum Kern des Servers ([[core]]) gehören oder |
| gehören und aktiviert sind. | | * in MPM-Modulen und 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:
| |
|
| |
| ### Section 1: Global Environment
| |
| #
| |
| # The directives in this section affect the overall operation
| |
| # of Apache, such as the number of concurrent requests it can
| |
| # 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.
| |
|
| |
| === 6.3.2 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:
| |
|
| |
| # groupadd htgroup
| |
| # 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.
| |
|
| |
| === 6.3.3 Konfiguration des »Hauptservers« ===
| |
| 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:
| |
|
| |
| ### Section 2: 'Main' server configuration
| |
| #
| |
| # The directives in this section set up the values used by the
| |
| # 'main' server, which responds to any requests that aren't
| |
|
| |
| # handled by a <VirtualHost> definition. These values also
| |
| # provide defaults for any <VirtualHost> containers you may
| |
| # 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:
| |
|
| |
| #define AP_SERVER_BASEVENDOR "Apache Software Foundation"
| |
| #define AP_SERVER_BASEPRODUCT "Apache"
| |
| #define AP_SERVER_MAJORVERSION "2"
| |
| #define AP_SERVER_MINORVERSION "2"
| |
| #define AP_SERVER_PATCHLEVEL "9"
| |
|
| |
| Die Werte lassen sich natürlich beliebig ändern. Beispiel:
| |
|
| |
| #define AP_SERVER_BASEVENDOR "Sirius Cybernetics Corp."
| |
| #define AP_SERVER_BASEPRODUCT "The Hitchhiker's Web Server"
| |
| #define AP_SERVER_MAJORVERSION "3"
| |
| #define AP_SERVER_MINORVERSION "1"
| |
| #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>
| |
|
| |
| === 6.3.4 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
| |
| # ... weitere Einstellungen für /usr/share/web
| |
| </Directory>
| |
|
| |
| <Directory /usr/share/web/test>
| |
| Options Includes
| |
| # ... 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
| |
| # ... 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
| |
| # ... weitere Einstellungen für /usr/share/web
| |
| </Directory>
| |
|
| |
| <Directory /usr/share/web/test>
| |
| Options +Includes
| |
| # ... 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
| |
| # ... 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 />
| |
| # Alle Optionen deaktivieren
| |
| Options None
| |
| # Sämtliches Überschreiben durch .htaccess dekativieren
| |
| AllowOverride None
| |
| # Zugriffe aller Clients verbieten
| |
| Require all denied
| |
| # Bis 2.2 werden statt "Require all denied"
| |
| # folgende zwei Zeilen verwendet:
| |
| #Order Deny,Allow
| |
| #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
| |
|
| |
| # Bis 2.2 folgende zwei Zeilen anstelle von "Require all granted":
| |
| #Order allow,deny
| |
| #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.
| |
|
| |
|
| <noinclude> | | <noinclude> |
| Zeile 1.578: |
Zeile 11: |
| == Anhang == | | == Anhang == |
| === Siehe auch === | | === Siehe auch === |
| {{Special:PrefixIndex/{{BASEPAGENAME}}}} | | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
| ==== Links ====
| | === Links === |
| ===== Weblinks =====
| | ==== Weblinks ==== |
| </noinclude> | | </noinclude> |
| | |
| | [[Kategorie:Apache/HTTP/06]] |