SELFHTML/Navigationshilfen Webserver/CGI Webserver
Der Apache HTTP-Webserver
Allgemeines
Die Apache-Module
Die Konfigurationsdatei httpd.conf
Weitere Informationen
| SELFHTML/Navigationshilfen Webserver/CGI Webserver |
|
|
Der Apache HTTP-Webserver |
|
|
|
| | |
Der heute (Anfang 2005) weltweit am häufigsten eingesetzte Webserver wurde im April 1995 erstmals in einer Version 0.6.2 publiziert. Er war das Ergebnis der Zusammenarbeit einer kleinen Entwicklergruppe, die sich das Ziel gesetzt hatte, einige bugfixes und Patches für eine bereits im NCSA (National Center for Supercomputing Applications) an der Universität von Illinois eingesetzte Software zusammenzutragen. Dieser ersten Sammlung von Patches verdankt die Software auch ihren Namen: a-patch-e. 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 in den 90er Jahren des vergangenen Jahrhunderts einsetzende explosionsartige Entwicklung des Internet begünstigte die weitere Arbeit der Entwickler enorm und bot gleichzeitig Voraussetzungen dafür, dass der Bedarf für den Einsatz zuverlässiger Server-Software erheblich anstieg. Dazu kam, dass der Apache von Anfang an eine Open-Source-Entwicklung sein und kostenlos jedem zur Verfügung stehen sollte. Die Entwicklergemeinde vergrößerte sich rasch, so dass es schließlich 1999 zur Gründung der 
Apache Software Foundation kam. Die Entwicklungsarbeit wird beständig weitergeführt.
Der Apache enstammt der UNIX-Welt, allerdings gibt es längst Portierungen für andere Rechnerarchitekturen und Plattformen, darunter selbstverständlich auch für Windows-Systeme. Da Windows 95, 98 und Me keine Mehrbenutzerbetriebssyteme sind und somit keine unterschiedlichen Rechte für besondere Benutzer kennen, wird von der Apache Software Foundation von einem Einsatz des Apache auf solchen Systemen im öffentlichen Betrieb abgeraten. Müssen Sie für öffentliche Aufgaben ein Windows-System einsetzen, so benutzen Sie eines der etwas moderneren NT-basierten Systeme (Windows NT, 2000, XP oder 2003). Dazu kommt, dass Sie für Windows einen Apache der Version 2 einsetzen sollten, da dieser das entsprechende Multiprozessing-Modul (MPM) nutzt und damit deutlich stabiler, zuverlässiger und schneller läuft als der ältere Apache 1.3.x. Wenn Sie einen Webserver lediglich im privaten Bereich oder auf einem Einzelplatzrechner zum Testen Ihrer Scripts benötigen, können Sie auch eines der älteren Systeme sowie die ältere Apache-Version einsetzen, falls Ihnen nichts anderes zur Verfügung steht.
Für jede Plattform lassen sich sowohl bereits vorkompilierte Pakete (für Windows beispielsweise MSI-Installationspakete) wie auch der komplette Sourcecode downloaden, so dass 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. Dabei gibt es zur Zeit ein paar kleine Unterschiede der beiden "Zweige": die jüngere Apache-Version 2.x.x nutzt konsequent den Einsatz von Multiprozessing-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. Die ältere Apache-Version 1.3.x ist noch nicht mit derselben Konsequenz modular aufgebaut. Sie ist heute noch auf sehr vielen Servern im Internet verbreitet, wird aber nach und nach von der jüngeren Version abgelöst 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: Multiprozessing-Module (MPM), Basismodule, Erweiterungsmodule, experimentelle und externe Module. Eine Besonderheit stellen die MPM dar, die es nur für Apache 2.x.x gibt (Apache 1.3.x folgt einem anderen, älteren Modulkonzept). Obwohl in den Sourcen mehrere solcher 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 mod_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:
KeepAlive zuständig und damit für die Lebensdauer von HTTP-Verbindungen. In Apache 1.3.x für alle core-Anweisungen zuständig.LoadModule-Anweisung als DSO Verwendung finden sollenAndere 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. Auf einer Windows-Maschine mit installiertem Apache 2.0.52 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.
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 inzwischen in mehrere kleinere Dateien aufgesplittet. Im wesentlichen enthält die httpd.conf drei "große" Funktionsabschnitte, in denen die unbedingt nötigen Festlegungen stehen.
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 Arbeitsweise. 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.
Wenn man das erstemal 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> 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 (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 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> 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.
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.
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.
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.
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.
Umfangreichere Informationen über die Container sind in der Apache-Dokumentation zu finden.
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.
Aus Gründen des Überblicks sollten Sie grundsätzlich, noch bevor Sie irgendwelche Anpassungen vornehmen, eine Kopie Ihrer 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.
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. Da sich die beiden Apache-Versionen (1.3.x und 2.x.x) in manchen Bereichen unterscheiden, ist auch die Dokumentation für beide "Zweige" getrennt verfügbar. Die Apache-1.3.x-Dokumentation gibt es nur in englischer Sprache. An der deutlich umfangreicheren Apache-2.0.x-Dokumentation arbeitet eine Gruppe von Übersetzern, um sie in mehreren Sprachen anbieten zu können. Viele Teile sind bereits in deutscher Sprache nachlesbar.
Im Online-Angebot von SELFHTML aktuell finden Sie weitere Informationen zum Thema Webserver und Links zu anderen Quellen im Web. Folgende Inhalte kommen in Frage:
Tipps & Tricks zur Serverkonfiguration
Feature-Artikel zur Serverkonfiguration
|
| |
 |
SSI - Server Side Includes
|
 |
Webserver lokal auf einem PC einrichten
|
| SELFHTML/Navigationshilfen Webserver/CGI Webserver |
|
© 2005 Impressum