Webserver/Apache

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Der 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, sodass es schließlich 1999 zur Gründung der Apache Software Foundation kam. Die Entwicklungsarbeit wird beständig weitergeführt.

Inhaltsverzeichnis

[Bearbeiten] 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 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.

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. 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 der httpd.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.

Beachten Sie: Gegenüber Apache 2.0.x haben sich bei Apache 2.2.x Namen und Funktionsweisen einiger Module geändert.

[Bearbeiten] 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.

[Bearbeiten] 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 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.

[Bearbeiten] "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.

[Bearbeiten] 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.

Beachten Sie: Ab Apache 2.2.2 wird von der Apache Software Foundation empfohlen, nicht mehr eine einzelne Konfigurationsdatei einzusetzen, sondern sie in mehrere kleinere Teile aufzutrennen. Eine Praxis, die bei Linux-Distributionen schon seit Apache 2.0.50 auf unterschiedliche Weise verfolgt wurde. Auf einem Windows-System finden Sie bei einer Standardinstallation jetzt ebenfalls mehrere Unterverzeichnisse im /conf-Verzeichnis, beispielsweise default und extra.

[Bearbeiten] Die Container mit den einzelnen Anweisungen

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.

[Bearbeiten] <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.

[Bearbeiten] <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.

[Bearbeiten] <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|Regulärer Ausdruck eingegeben werden kann, womit beispielsweise mehrere Dateinamen - eventuell Grafikformate - auf identische Weise behandelt werden können.

[Bearbeiten] <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.

[Bearbeiten] <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.

[Bearbeiten] <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.

Beachten Sie: 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.

[Bearbeiten] 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.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Übersicht
Index
Mitmachen
Werkzeuge
Spenden
SELFHTML