Webserver/Apache
Der Apache HTTP Server [əˈpætʃi] ist einer der meistbenutzten Webserver im Internet. Die Assoziation, dass der Name des Servers vom Namen eines Indianerstammes abgeleitet sein könnte, wird dabei wohl ins Kalkül gezogen worden sein.
Die Apache Software Foundation pflegt eine umfangreiche Dokumentation, auf die Sie sicher zurückgreifen wollen, wenn Ihnen irgendetwas bei der Administration Ihres Apache nicht klar ist.
- download
- deutschsprachige Dokumentation zur Version 2.0 (wird nicht mehr gepflegt)
- deutschsprachige Dokumentation zur Version 2.2
- deutschsprachige Dokumentation zur Version 2.4
Inhaltsverzeichnis
Die Apache-Module
Für jede Plattform lassen sich sowohl bereits vorkompilierte Pakete wie auch der komplette Sourcecode downloaden, sodass jeder Benutzer selbst entscheiden kann, wie er sich "seinen" Apache kompilieren möchte. Das setzt allerdings bereits etwas Erfahrung im Umgang mit einem C-Compiler und Makefiles voraus. Aber gerade dadurch lassen sich auch nur bedingt Aussagen über eine "Standard"-Installation treffen. Der Server selbst ist in der Regel nur eine relativ kleine ausführbare Datei. Sie kann aber je nach Konfiguration eine Vielzahl von Modulen mit teilweise sehr umfangreichen weiteren Funktionen ansprechen – und es kann auch sein, dass Sie solche Module selbst gleich "fest" mit in die ausführbare Datei einbinden möchten. Dieser modulare Aufbau birgt enorme Vorteile in sich und hat sich möglicherweise nur deshalb durchgesetzt, weil der Apache von Anfang an eben nichts wesentlich anderes als eine Sammlung von Patches rund um eine zentrale ausführbare Datei war.
Das Modul-Konzept war von Anfang an Bestandteil der "Bauweise" des Apache und gilt als eine seiner großen Stärken. Er nutzt konsequent den Einsatz von Multiprocessing-Modulen (MPM), die speziell dafür entwickelt wurden, dass der Apache Eigenarten der Plattform, auf der er eingesetzt wird, berücksichtigen kann. Gleichzeitig steuern diese MPM eine Reihe zentraler Anweisungen, die nahezu immer in der Apache-Konfiguration benötigt werden.
Es gibt unterschiedliche Gruppen von Modulen: Basismodule (oder Kernmodule) und andere Module. Eine andere Gruppeneinteilung kann entsprechend dem Status vorgenommen werden – also entsprechend der Art, wie sie kompiliert werden: Multiprocessing-Module (MPM), Basismodule, Erweiterungsmodule, experimentelle und externe Module. Obwohl in den Sourcen mehrere solcher MPM-Module zur Verfügung stehen, wird immer nur genau eines benötigt, das auf die Einsatzplattform zugeschnitten ist. Auf einer Windows-Maschine kann daher immer nur mpm_winnt
eingesetzt werden. Das hat damit zu tun, dass Windows kein echtes Multiprozess-System ist und für den Apache immer nur zwei Prozesse gestartet werden können – der eigentliche Server-Prozess und ein "Child"-Prozess. Auf einer Linux-Maschine können dagegen unterschiedliche "Child"-Prozesse gleichzeitig nebeneinander laufen.
Zur Laufzeit des Servers stehen die Kernmodule (und die eventuell statisch einkompilierten Module) immer zur Verfügung. Es gibt derzeit nur drei Kernmodule, die aber enorme Bedeutung haben:
core
: lässt den Einsatz von Containern in derhttpd.conf
zu, das Ansprechen von Serververzeichnissen und Dateien, die Festlegung von ServerRoot und DocumentRoot, das Anlegen von Protokolldateien, das Ansprechen eines Ports, Aliasnamen... kurz: die wirklich wichtigen Funktionen, die man als Administrator auch in der httpd.conf festlegen möchte, werden damit überhaupt erst ermöglicht.http_core
: ist für KeepAlive zuständig und damit für die Lebensdauer von HTTP-Verbindungen.mod_so
: erlaubt den Zugriff auf andere Module, die mit der LoadModule-Anweisung als DSO Verwendung finden sollen- MP-Modul
Andere Module können entsprechend dem Konzept der "dynamic shared objects" (DSO) mit Hilfe der LoadModule
-Anweisung in der httpd.conf
dazugeladen werden. Einige dieser Module wird man in fast allen Fällen benutzen wollen, beispielsweise mod_alias
, das solche wichtigen Befehle wie ScriptAlias
konfiguriert, mod_access
, das die Anweisung Order Allow,Deny
konfiguriert oder mod_dir
, mit dem ein DirectoryIndex
erst ermöglicht wird. Wenn Sie wissen möchten, wie Ihr Apache kompiliert wurde, steht Ihnen dazu der Konsolenbefehl apache -l
zur Verfügung (je nach installierter Version kann der Befehl auch httpd -l oder apache2 -l lauten). Auf einer Windows-Maschine mit installiertem Apache 2.2.4 ergibt das beispielsweise folgende Anzeige:
Compiled in modules: core.c mod_win32.c mpm_winnt.c http_core.c mod_so.c
Abhängig davon, wie der Apache konfiguriert wurde, kann man sich auch mit server-info als Bestandteil der aufgerufenen URL – in der Form http://domain.tld/server-info
– wesentlich umfangreichere Informationen anzeigen lassen. Diese Liste enthält auch Angaben über diejenigen Module, die zur Server-Laufzeit mit Hilfe der LoadModule-Anweisung eingebunden werden und ist sehr nützlich, wenn man sich rasch darüber informieren möchte, welche Anweisungen in der httpd.conf überhaupt verwendet werden dürfen.
In der Apache-Online-Dokumentation gibt es eine bereits übersetzte Auflistung aller möglichen Module. Die Seite mit den Erläuterungen zu core ist ebenfalls in deutscher Sprache verfügbar und sollte bei auftretenden Fragen oder Unklarheiten immer konsultiert werden.
Die Konfigurationsdatei httpd.conf
Sobald der Apache startet, fragt er eine zentrale Konfigurationsdatei nach Anweisungen ab, wie er sich verhalten soll. Diese zentrale Konfigurationsdatei trägt in der Regel den Namen httpd.conf
. Sie kann aber auch einen anderen Namen tragen, wenn der Webserver mit entsprechenden Anweisungen kompiliert wurde. Einige jüngere Linux-Distributionen verwenden in ihren distributionsspezifischen Paketen beispielsweise Namen wie "apache.conf".
Diese zentrale Konfigurationsdatei ist eine Textdatei, in der eine Reihe von Anweisungen notiert wird, an denen sich der Apache orientiert. Bei jeder Installation wird sie in einer Standard-Form angelegt und enthält zusätzlich zu den Anweisungen auch noch kurze erläuternde Kommentare (von einigen Linux-Distributionen wird die Konfigurationsdatei seit Apache 2.0.50 in mehrere kleinere Dateien aufgesplittet). Im wesentlichen enthält die httpd.conf drei größere Funktionsabschnitte, in denen die unbedingt nötigen Festlegungen stehen.
Global Environment (Globale Umgebung)
Unter "Globale Umgebung" werden die Bedingungen verstanden, unter denen der Apache Webserver arbeiten soll. Zu dieser Arbeitsumgebung gehören:
- Angaben zum Servertyp
(wobei für den Einsatz auf einem Windows-Rechner ausschließlich der Typ "standalone" gewählt werden kann) - die Definition des Verzeichnisses bzw. Laufwerks auf dem Rechner, in dem sich die Programm-, Konfigurations- und Protokolldateien befinden
- ein paar Festlegungen für Zugriffszeiten und -zahlen
- die Liste der zur Laufzeit einzubindenden Module
- Angabe der IP-Schnittstelle(n) und des/der zugewiesenen Ports
In der Regel Port 80, es kann sinnvoll sein, einen anderen Port für ein lokales Netzwerk zu wählen, um möglichen Konflikten auszuweichen. Dann sollte es einer der nicht für Standards vorgesehenen Ports über 1024 sein.
Bei diesen Definitionen der Arbeitsumgebung gibt es noch nicht allzu viele Variationsmöglichkeiten. Wichtig ist die Liste der Module, die nicht ohne Grund zur globalen Umgebung zählen. Im Standardfall ist die Liste der zuladbaren Module erst einmal weitgehend deaktiviert. Es lohnt sich aber, die Dokumentation zu den Modulen gründlich nachzulesen und dann diejenigen Module zu aktivieren, mit denen man arbeiten möchte. Auch das Einbinden individuell erstellter oder aus dem Internet heruntergeladener weiterer Module ist hier möglich.
"Main" server configuration (Hauptserver-Konfiguration)
Nachdem die Arbeitsumgebung definiert worden ist, folgen als nächstes die Anweisungen zur Arbeitsweise. Arbeitsweise bedeutet dabei im wesentlichen:
- Servername und Administrator-Adresse
- Pfadangaben zu Dokument-, Benutzer- und Scriptverzeichnissen
- Formatierung der Protokolldateien
- Aufgabenzuweisung an die geladenen Module
Während die Festlegung des Ports, die Namensgebung (ein Servername wird zwingend verlangt, sonst startet Apache nicht) sowie die Bestimmung der Pfade von Server-Verzeichnissen und die Inhaltsvorgabe für die Protokolldateien (Logs) in der Regel keine Probleme darstellen, liegt die Hauptarbeit eines Administrators wahrscheinlich darin, den Modulen die gewünschten Aufgaben zur Erledigung zuzuweisen. Ob diese Zuweisungen von Apache befolgt werden können, ist davon abhängig, ob das entsprechende Modul überhaupt geladen ist.
Virtual Hosts (virtuelle Hosts)
Der Begriff virtueller Host wurde eingeführt, um das Konzept zu kennzeichnen, mit dem auf ein und derselben Maschine mehrere unterschiedliche Webangebote verfügbar gemacht werden können. Der Apache gilt als einer der ersten Server überhaupt, die IP-basierte virtuelle Hosts direkt unterstützt haben (seit Version 1.1).
Es gibt grundsätzlich zwei Methoden, virtuelle Hosts einzurichten:
- namensgestützte virtuelle Hosts
- IP-gestützte virtuelle Hosts
IP-Adressen werden benötigt, damit die Datenpakete des Übertragungsprotokolls (TCP/IP) tatsächlich nur von dem Rechner (bzw. der Netzwerk-Schnittstelle) angenommen werden, dem eine solche individuelle Adresse zugeordnet ist. Dazu müssen Domainname und IP-Adresse der Registrierung entsprechen, die in einer Datenbank archiviert ist. Diese Aufgabe fällt dem Domain Name Service (DNS) zu. Nur wenn auf einem Rechner IP-Adresse und Domainname mit diesen DNS-Daten übereinstimmen, kann der Rechner, der über die gesuchte IP-Adresse und den Domainnamen verfügt, die Datenpakete auch erhalten und weiterbearbeiten.
Namensgestützte virtuelle Hosts machen es möglich, mehrere unterschiedliche Domainnamen einer einzelnen IP-Adresse zuzuordnen. Der Webserver wird damit in die Lage versetzt, die Verwaltung der Domains auch auf unterschiedliche Art zu realisieren – beispielsweise könnte eine Domain für CGI-Scripts eingerichtet werden, eine andere dagegen keine solchen Scripts zulassen. Das Konzept für namensbasierte virtuelle Hosts ist relativ einfach und wird auch am häufigsten genutzt.
IP-gestützte virtuelle Hosts erhalten unterschiedliche IP-Adressen. Die Zahl der verfügbaren IP-Adressen ist jedoch eng begrenzt, da den Netzwerk-Schnittstellen einer (physischen) Maschine ja immer nur eine individuelle IP-Adresse zugeordnet werden kann. Werden mehrere IP-Adressen benötigt, kann das mit einer Methode, die IP-Aliasing genannt wird, erreicht werden. Solche IP-Aliase können nun einer Domain zugewiesen werden, zusätzlich aber auch für weitere namensgestützte virtuelle Hosts Verwendung finden.
Die Container mit den einzelnen Anweisungen
Wenn man das erste Mal einen Blick in die httpd.conf
wagt, ist es durchaus möglich, dass ihr grundsätzlicher Aufbau an ein HTML-Dokument erinnert. Sie enthält eine Reihe von Eintragungen, die von den gewohnten < spitzen Klammern > umschlossen werden und wie "Tags" wirken. Selbstverständlich sind sie das nicht. Sondern es handelt sich um so genannte Container, in denen jeweils ganz bestimmte Anweisungen zusammengefasst werden.
Folgende Container sind derzeit möglich: <Directory>
, <DirectoryMatch>
, <Files>
, <FilesMatch>
, <IfDefine>
, <IfModule>
, <Location>
, <LocationMatch>
, <Proxy>
, <ProxyMatch>
und <VirtualHost>
. Man kann sie nach zwei Gruppen ordnen: <IfDefine>
und <IfModule>
werden ausgewertet, sobald der Server selbst startet und müssen nicht bei Anfragen berücksichtigt werden. Darin enthaltene Anweisungen werden nur wirksam, wenn eine Bedingung zutrifft. Die anderen Container enthalten Anweisungen, mit denen Verzeichnisse angesprochen werden können und die das Verhalten bei Zugriffen auf bereitgestellten Webspace bestimmen. Sie werden bei Anfragen ausgewertet.
<IfDefine> und <IfModule>
<IfDefine>
reagiert auf Parameter, die bei Serverstart in der Befehlszeile eingegeben werden (können). Dabei gibt es zwei unterschiedliche Reaktionsweisen: es kann festgelegt werden, ob eine Bedingung zutrifft oder ob sie nicht zutrifft, abhängig davon werden die im Container enthaltenen Anweisungen ausgeführt – oder eben nicht ausgeführt. Die Startparameter selbst kann man auch in einem Startscript vorgeben. Im Standardfall wird <IfDefine>
nicht benötigt und ist auch nicht in einer Standard-httpd.conf
enthalten.
<IfModule>
werden Sie dagegen häufiger nutzen wollen, da mindestens die Festlegung für eines der Multi-Prozessing-Module benötigt wird sowie nahezu immer auch weitere Module angesprochen werden sollen. Die Module selbst stellen erst die benötigten Anweisungen bereit, es ist sicherer, modul-spezifische Anweisungen innerhalb eines <IfModule>
-Containers zu notieren, da der Apache auf diese Anweisungen nur dann zugreift, wenn das entsprechende Modul tatsächlich geladen ist.
<Directory> und <DirectoryMatch>
<Directory>
wird eingesetzt, um Anweisungen zusammenzufassen, die nur für das genannte Verzeichnis und dessen Unterverzeichnisse gelten. Die Verzeichnisnamen werden unmittelbar im Container notiert. "Verzeichnisname" ist dabei entweder der vollständige Pfad zu einem Verzeichnis oder eine Zeichenkette mit Platzhaltern. In einer Zeichenkette mit Platzhaltern entspricht ? einem einzelnen Zeichen und * einer Zeichenkette beliebiger Länge.<Directory>
-Container sind so gut wie immer in einer httpd.conf enthalten.
<DirectoryMatch>
erfüllt dieselben Aufgaben wie <Directory>
, mit dem Unterschied, dass als "Verzeichnisname" hier ein Regulärer Ausdruck Verwendung findet und kein Verzeichnisname.
<Files> und <FilesMatch>
Der Container <Files>
enthält Anweisungen, die nur für ganz bestimmte Dateien gültig werden sollen. Dieser Container wird beispielsweise benutzt, um .htaccess
-Dateien vor unbefugten Zugriffen zu verbergen. Das Pendant <FilesMatch>
erfüllt dieselbe Aufgabe, wiederum mit dem Unterschied, dass anstelle eines bestimmten Dateinamens ein Regulärer Ausdruck eingegeben werden kann, womit beispielsweise mehrere Dateinamen – eventuell Grafikformate – auf identische Weise behandelt werden können.
<Location> und <LocationMatch>
Der Container <Location>
gilt für URLs. Das ist bisweilen nicht leicht verständlich, da ja der Apache in der Regel auf Anfragen reagiert, die ein Client (ein Browser) mit der Angabe einer URL an ihn schickt. Es wird jedoch klar, wenn man sich vor Augen hält, dass <Directory>
und <Files>
für Dateien gelten, die innerhalb von Serververzeichnissen liegen, <Location>
dagegen Informationen abruft, die nicht zum Serverdateisystem gehören (müssen). Verdeutlichen kann man sich diesen Unterschied anhand der vorformulierten <Location>
-Container für server-info
und server-status
. Auch hier gilt wieder, dass das Pendant <LocationMatch>
eingesetzt wird, wenn Reguläre Ausdrücke eingesetzt werden sollen.
<Proxy> und <ProxyMatch>
Ein <Proxy>
-Container kann nur eingesetzt werden, wenn zuvor das entsprechende Modul mod_proxy
geladen wurde. Es gibt noch weitere Module für den Umgang mit Proxy-Inhalten, beispielsweise mod_proxy_ftp
, mit dem der Apache in die Lage versetzt werden kann, FTP-Inhalte auszuliefern – sofern sie denn im Proxy-Cache gespeichert sind. Gelegentlich wird darauf hingewiesen, dass <Proxy>
nicht genutzt werden sollte, wenn gleichzeitig SSL aktiviert ist. Auch hier findet das Pendant <ProxyMatch>
dann Verwendung, wenn Reguläre Ausdrücke genutzt werden sollen.
<VirtualHost>
Dies ist der vielleicht am besten bekannte Container. Innerhalb von <VirtualHost>
-Containern kann nahezu alles andere ebenfalls enthalten sein, was im Hauptabschnitt der httpd.conf
(main server configuration) Verwendung finden darf.
Die Standard-Datei, die Sie während der Installation des Apache erhalten, sollten Sie unbedingt bearbeiten, da eine Reihe von Einstellungen, auf die Sie vielleicht Wert legen (z.B. die Erlaubnis zum Ausführen von Scripts), erst aktiviert werden muss. Sie haben weitgehende Freiheiten, aus der httpd.conf
eventuell kleinere Dateien auszugliedern, die Sie dann mit Include in die httpd.conf
wieder einbinden. Wenn Sie beispielsweise viele virtuelle Hosts zu betreuen haben, werden Sie mindestens dafür eine gesonderte Datei anlegen wollen - einfach deshalb, weil Sie damit einen besseren Überblick haben.
httpd.conf
unter anderem Dateinamen und möglichst auch an einer anderen Stelle auf Ihrem Rechner abspeichern. Geht dann irgendetwas schief, können Sie sie zurückkopieren und haben wenigstens den Ausgangszustand wiederhergestellt. Haben Sie eine solche Kopie abgelegt, sollten Sie aus der httpd.conf
alle Kommentare entfernen (da Sie sie ja bei Bedarf in Ihrer Kopie immer noch nachlesen können) sowie die Anweisungen streichen, bei denen Sie sicher sind, dass Sie sie nicht brauchen werden. Sie werden sehen, dass dann Ihre resultierende httpd.conf
bereits eine relativ "handliche" Größe aufweist. Bei allen Fragen, die sich Ihnen dann eventuell stellen, lesen Sie bitte in der Apache-Dokumentation nach, die Sie auch auf Ihrem Rechner vorfinden.Weblinks
Die Apache Software Foundation pflegt eine umfangreiche Dokumentation, auf die Sie sicher zurückgreifen wollen, wenn Ihnen irgendetwas bei der Administration Ihres Apache nicht klar ist.