 SELFHTML aktuell Artikel Serverkonfiguration Die Apache-Konfigurationsdatei | |
 |
Die Apache-Konfigurationsdatei:
|
 |
|
 | |
Die httpd.conf ist eine Konfigurationsdatei und kein "Script", daher lassen sich Vergleiche zum Aufbau von Scripts nur sehr bedingt anstellen. Prinzipien wie die der objektorientierten Programmierung gelten hier nicht. Es mag jedoch manchmal helfen, sich solcher Prinzipien zu erinnern, da der Aufbau der httpd.conf in weiten Bereichen einer strengen Hierarchie folgt und es durchaus nicht gleichgültig ist, in welcher Reihenfolge bzw. innerhalb welches Containers die verschiedenen Befehlszeilen erscheinen. Diese Befehlszeilen können einzelne Anweisungen oder Festlegungen enthalten oder kleinere Unterabschnitte (Container) einleiten, die dann wiederum verschiedene Befehlsblöcke enthalten können. Alle diese Container sind vielfältig konfigurierbar, womit sehr unterschiedliche individuelle Einstellungen möglich sind.
Wenn man das erstemal einen Blick in die httpd.conf wagt, ist es durchaus möglich, daß 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 sogenannte Container, in denen jeweils ganz bestimmte Anweisungen zusammengefaßt 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> reagiert auf Parameter, die bei Serverstart in der Befehlszeile eingegeben werden. 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. Meist soll ja der Apache mit dem Systemstart schon hochgefahren werden, was ein entsprechendes Startscript regelt. Es wird dann in der Regel das zu den Apache-Sourcen gehörende Script /usr/sbin/apachectl bzw. /usr/sbin/apache2ctl aufgerufen, in dem diese Startparameter eingetragen werden können.
Im Standardfall wird <IfDefine> nicht benötigt und ist auch nicht in einer "default"-httpd.conf enthalten.
<IfModule> dagegen ist immer enthalten, da mindestens die Festlegung für eines der Multi-Prozessing-Module (für Apache 2.x.x) benötigt wird sowie nahezu immer auch weitere Module angesprochen werden sollen. Die Module selbst stellen erst die benötigten Anweisungen bereit, es ist nicht möglich, modul-spezifische Anweisungen außerhalb eines <IfModule>-Containers zu notieren.
<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 immer in einer httpd.conf enthalten.
<DirectoryMatch> erfüllt dieselben Aufgaben wie <Directory>, mit dem Unterschied, daß als "Verzeichnisname" hier ein Regulärer Ausdruck Verwendung findet und kein Verzeichnisname.
Der Container <Files> enthält Anweisungen die nur für ganz bestimmte Dateien gültig werden sollen. Dieser Container wird beispielsweise benutzt, um .htacces-Dateien vor unbefugten Zugriffen zu verbergen. Das Pendant <FilesMatch> erfüllt dieselbe Aufgabe, wiederum mit dem Unterschied, daß anstelle eines bestimmten Dateinamens ein Regulärer Ausdruck eingegeben werden kann, womit beispielsweise mehrere Dateinamen - eventuell Grafikformate - auf identische Weise behandelt werden können.
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, daß <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, daß das Pendant <LocationMatch> eingesetzt wird, wenn Reguläre Ausdrücke eingesetzt werden sollen.
Ein <Proxy>-Container kann nur eingesetzt werden, wenn zuvor das entsprechende Modul mod_proxy geladen wurde. Ein Beispiel war bis Apache 1.3.28 am Ende der httpd.conf vorformuliert, ab Apache 1.3.29 nicht mehr. 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, daß <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. Bei Apache 2.0.50 ist <Proxy> in der Regel nicht in der vorformulierten httpd.conf enthalten.
Dies ist der vielleicht am weitesten 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. Beachtet werden muß allerdings, daß Anweisungen, die innerhalb eines solchen Containers notiert werden, nur dann Wirkung haben, wenn das Modul mod_vhost_alias.so geladen wurde. Auf die mögliche Konfiguration von virtuellen hosts wird 
später etwas ausführlicher eingegangen.
Umfangreichere Informationen über diese Container sind natürlich in der 
Apache-Dokumentation zu finden.
Im wesentlichen sind es drei "große" Funktionsabschnitte, die die unbedingt nötigen Festlegungen enthalten.
Unter "Globale Umgebung" werden die Bedingungen verstanden, unter denen der Apache Webserver arbeiten soll. Zu dieser Arbeitsumgebung gehören:
Bei diesen Definitionen der Arbeitsumgebung gibt es noch nicht allzuviele 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.
Nachdem die Arbeitsumgebung definiert worden ist, folgen als nächstes die Anweisungen zur Arbeisweise. Arbeitsweise bedeutet dabei im wesentlichen:
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.
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:
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.
SELFHTML aktuell Artikel Serverkonfiguration Die Apache-Konfigurationsdatei
© 2007 
Impressum, für diese Seite: 
christoph.schnauss@berlin.de
