Webserver/Die Apache-Konfigurationsdatei

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

An der Diskussion im SELFHTML-Forum lässt sich ablesen, dass das Interesse an einer zuverlässigen Installation des Apache unverändert groß ist. Der Apache wird weltweit millionenfach eingesetzt und hat den unschätzbaren Vorteil, dass er nicht nur sehr stabil und zuverlässig läuft und außerordentlich variabel konfigurierbar ist, sondern auch noch frei und kostenlos zur Verfügung steht - und wer sich dafür interessiert, kann sich in die Sourcen vertiefen und ihn sich nach eigenen Bedürfnissen kompilieren.

Informationen zum Autor

Name:
Christoph Schnauß

Hinweis

Dieser Artikel ist eine Textübertragung aus dem aktuell.de.selfHTML-Bereich. Seine Inhalte sind möglicherweise veraltet.
  • zuerst erschienen: 19.08.2004,
  • letzte Aktualisierung: 23.11.2005
von Christoph Schnauß: Apache-Webserver mit Hilfe der httpd.conf einrichten

Es gibt zwar eine kaum mehr überschaubare Anzahl an gedruckten deutschsprachigen Anleitungen und Kompendien, aber die Übersetzung der Online-Dokumentation ist noch längst nicht vollendet und eine einigermaßen knappe Anleitung in deutscher Sprache ist im Internet schwer zu finden. Dabei ist das, was man für den Anfang braucht, tatsächlich nahezu alles in den Kommentaren der Konfigurationsdatei enthalten, so dass ein Einstieg erst einmal zuverlässig gelingen sollte. Für weitergehende Fragen muss selbstverständlich die Dokumentation der Apache Software Foundation konsultiert werden, mehr als eine allererste Einstiegshilfe kann und will dieser Artikel gar nicht leisten.

Ich hatte mich vor einiger Zeit einmal an eine Übersetzung der Kommentare gesetzt, um aus mehr oder weniger beruflichen Gründen etwas Verständliches anbieten zu können. Durch den Kontakt zum SELFHTML-Forum ergab sich die Möglichkeit, diese Übersetzung zur Grundlage eines Artikels zu machen, der dann auch gelegentlich zitiert worden ist. Wie alles im Internet unterliegt aber auch mein Artikel einem gewissen Verschleiss, da die Entwicklung des Apache inzwischen deutlich weitergegangen ist. Daher wurde der ursprüngliche Artikel von Grund auf überarbeitet, neu gefasst, erweitert und so weit wie möglich auf die aktuelle Entwicklung ausgerichtet.

Der Artikel versteht sich als Bestandteil der Artikel im SELFHTML-Raum. Einige zusätzliche Fragen werden von anderen Artikeln beantwortet, zum Beispiel von den drei Arbeiten von Michael Schröpl:

Einen speziellen Aspekt der Apachekonfiguration beschreibt auch Achim Schrepfer in seinem Artikel Aliasing von Webverzeichnissen, andere Arbeiten, wie beispielsweise Den W3C-Validator lokal installieren von David Tibbe berühren Teilthemen dieses Artikels, und Rolf Rost hat sich in seiner bereits etwas älteren Arbeit Der private Internetserver mit RAS mit einem vergleichbaren Thema beschäftigt.

Es muss ausdrücklich darauf hingewiesen werden, dass sich der Artikel an Leser wendet, die sich einen Apache lokal installieren möchten, um gelegentlich Scripts vor dem Hochladen zu testen. Für einen solchen Serverbetrieb sind umfangreichere Kombinationen mit diversen Modulen, Sicherheitseinstellungen und Proxy-Installationen in der Regel nicht erforderlich. Man wird auch kaum Aufgaben zu bewältigen haben, wie sie Christian Kruse in seinem Artikel Wirksames Tuning für viel besuchte Webauftritte beschrieben hat. Wer den Apache in einem Firmennetzwerk betreibt oder ihn als "produktiven Server" öffentlich zugänglich macht, wird jedoch um solche "Zusätze" kaum herumkommen. Auf Modifikationen für unterschiedliche Benutzerzugriffe und -rechte (.htaccess) wird im Rahmen dieses Artikels ebensowenig eingegangen wie auf Sicherheitsaspekte, einzig zu Perl (CGI) und PHP gibt es einige knappe Anmerkungen, da diese beiden Sprachen zur Zeit wohl die am häufigsten benötigten Instrumente zur Erstellung von Scripts und zum Einsatz serverseitiger Techniken über eine Netzwerk-Verbindung darstellen.

Unix / Linux und Windows[Bearbeiten]

Der Apache entstammt der Unix-Welt und leugnet seine Herkunft nicht. Wird er auf einer Unix-Plattform eingesetzt (Linux ist ja ein Mitglied der Unix-Familie), ist er ein mächtiges Werkzeug, dessen Einsatzfähigkeiten mit dem Begriff "Vielfalt" nur annähernd umschrieben werden. Er ist zur Zeit der mit Abstand am häufigsten im Internet eingesetzte HTTP-Webserver, eignet sich aber auch hervorragend zum Einsatz in kleineren Netzen, in Firmen-Intranets oder privaten LANs. Längst gibt es ihn auch in Portierungen für andere Plattformen, beispielsweise für Windows. In diesem Artikel wird versucht, Grundlagen der Apache-Konfiguration sowohl für Windows wie auch für Linux vorzustellen.

Für einen "Systemvergleich" ist hier nicht der richtige Ort, aber es muss doch darauf hingewiesen werden, dass die Apache-Entwickler selbst immer wieder betont haben, die für Windows bisher erarbeiteten Portierungen der Version 1.3.x (die derzeit letzte ist 1.3.31) befänden sich im "beta-Stadium" und man solle darauf gefasst sein, dass der Apache nicht immer vollkommen stabil sei. Auch wenn derlei Äußerungen im Hinblick auf Win9x gemacht wurden und Win2000 immerhin bescheinigt wird, dass es dem Apache fast keine Probleme bereite: es sind vorsorgliche Hinweise; in einem kleinen LAN aus Windows-Rechnern arbeitet der "Indianer", wie ihn manche nennen, auch auf einem Win98-Rechner durchaus zuverlässig und stabil und kümmert sich wenig darum, was seine Entwickler für Probleme vielleicht vorausahnten. Der eigentliche Grund für die Reserviertheit der Apache-Entwickler liegt in Unzulänglichkeiten dieser inzwischen älteren Windows-Systeme: "mit Windows 95/98 kann der Apache nicht von einem bestimmten Benutzer mit Sonderrechten für das Netzwerk gestartet werden. Es gibt auf einer lokalen Maschine keine Sicherheit. Aus diesem einfachen Grund kann die Apache Group niemals den Einsatz von Windows 95/98 als öffentlicher HTTP-Server befürworten. Einsatzmöglichkeiten gibt es lediglich als Unterstützung für die Entwicklung von Webinhalten und das Kennenlernen des Apache, und vielleicht noch als Server in einem abgeschirmten privaten Netzwerk" [1].

Dass der mögliche Funktionsumfang gegenüber einem auf einer Unix-Plattform eingesetzten Apache tatsächlich etwas geringer ist, wird kaum jemand bemerken. Und der Hinweis auf ein "beta-Stadium" entfällt bei den aktuellen Softwarepaketen der Version 2, die ebenfalls unter Windows 9x eingesetzt werden können, ihre volle Funktionalität aber erst mit Windows 2000 bzw. Windows XP erreichen - und selbstverständlich auf jedem mit einem der Unix-Familie zugehörenden Betriebssystem ausgestatteten Rechner.

Beinahe von Anfang an hatte der Apache einen mächtigen Seite Partner: Perl. In den 90er Jahren des vergangenen Jahrhunderts kamen weitere "Partner" hinzu, als vielleicht wichtigster PHP. In den Diskussionen der verschiedenen newsgroups bürgerten sich bald zwei Begriffe ein, mit denen man den Unterschied zwischen den Einsatzplattformen und den mit dem Webserver zusammenarbeitenden Sprachen und Systembestandteilen benennen wollte: LAMP und WAMP. Dabei bedeutet LAMP nichts anderes, als dass auf dem eingesetzten Rechner ein System mit LINUX, Apache, mySQL und PHP installiert ist, während mit WAMP eine Installation mit WINDOWS, Apache, mySQL und PHP gemeint ist. Selbstverständlich gibt es noch eine Vielzahl weiterer möglicher Kombinationen von Betriebssystemen und dem Apache Webserver. Aber WAMP und LAMP dürften die häufigsten sein - und wohl noch eine Weile bleiben.

Der deutlichste Unterschied zwischen diesen beiden Einsatzweisen des Apache zeigt sich im Umgang mit den Modulen sowie in der Zahl der überhaupt verfügbaren Module (sie ist auf einem Windows-Rechner etwas kleiner als auf einem Linux-Rechner). Eine der größten Stärken des "Indianers" liegt ja überhaupt darin, dass er diesen modularen Aufbau aufweist; das heißt, dass eine relativ kleine ausführbare Datei httpd bzw. apache.exe zur Laufzeit noch nahezu beliebig viele Module mit enormen Funktionserweiterungen ansprechen kann und einem Benutzer freigestellt ist, eventuell für wichtig gehaltene weitere Funktionalitäten in individuell erstellten Modulen festzulegen und an den Server zur Ausführung zu übergeben. Im wesentlichen handelt es sich bei diesen Modulen um Bibliotheken, mit denen Zugriffs- und Verwaltungsmöglichkeiten für diverse Aufgaben zugänglich gemacht werden. Wirklich ausschöpfen lassen sich diese "Features" (bisher) nur auf einer zur Unix-Familie gehörenden Plattform wie zum Beispiel Linux. Die Windows-Variante des Apache Webservers bietet nur einen Teil dessen, was er tatsächlich zu leisten vermag, auch wenn sich mit der inzwischen stabilen Version 2 einige Erweiterungen ergeben haben.

Bis zur Apache-Version 1.3.13 hießen die Module übrigens auf einem Windows-Rechner auch so, wie eine System- bzw. Programmbibliothek innerhalb eines Windows-Systems nun einmal heißt: es waren DLLs, also "dynamic linked libraries". Ihrem Wesen nach sind sie das immer noch, nur tragen sie jetzt auf einem Windows-Rechner denselben Namen wie auf einem Linux-Rechner - sie heißen jetzt "modul_name.so". Dabei steht "so" für "Shared Object", was die Funktion wohl besser benennt.

Apache-Installation[Bearbeiten]

Der Apache Webserver ist kostenlos und frei verfügbar. In unregelmäßigen Abständen werden von der Apache Software Foundation Updates bereitgestellt, so dass man im Internet bisweilen auf verschiedene Versionen trifft. Dabei hat die Entwicklerarbeit dazu geführt, dass derzeit zwei "Zweige" existieren: Version 1.3.x und die jüngere Version 2.x, die künftig die gültige Version darstellen wird. Die aktuelle Version (Stand Juli 2004) ist Version 2.0.50, bei der Apache Software Foundation ist aber bereits Version 2.1 in Arbeit. Der 1.3.x-Zweig ist mehr oder weniger "abgeschlossen", die letzte als stabil bezeichnete und zum Download angebotene Version ist 1.3.31 (Stand Juli 2004). Möglich ist, dass zur Behebung kleinerer Fehler noch Update- bzw. Bugfix-Versionen erscheinen. Am grundsätzlichen Aufbau dieses "Zweiges" wird sich nichts mehr ändern.

Beide Versionen unterscheiden sich zum Teil erheblich - auch in der Art und Wirkungsweie einiger Abschnitte der httpd.conf. Darüber hinaus verläuft die Installation auf den verschiedenen Plattformen (Betriebssystemen) auf sehr unterschiedliche Weise. Es soll daher kurz auf die beiden Plattformen Windows und Linux eingegangen werden. Der Artikel erhebt dabei keinerlei Anspruch auf Vollständigkeit!

Auf einem Linux-System[Bearbeiten]

Natürlich werden die Sourcen oder binaries des Apache für eine Installation benötigt. Entweder lädt man sie sich von http://www.apache.de/dist/httpd herunter oder man nimmt die auf den Installationsmedien (CDs) der ausgewählten Distribution immer mitgelieferten Pakete. Oft sind die dort enthaltenen Apache-Versionen aber nicht aktuell, dann kann man sich das benötigte Paket von einem FTP-Server holen.

Für SuSE Linux 9.1:

Für Fedora Core 2:

Für Debian 3.0r2 (sarge):

Wenn apt-get richtig konfiguriert ist, bekommt man damit einen Apache angeboten, der dann auch gleich ins System integriert wird.

Für Gentoo und FreeBSD 5.2.1: Selbstverständlich gibt es auch dafür FTP-Server, von denen man sich die gewünschten Pakete direkt holen könnte, jedoch sind die Update-Mechanismen über den portage-Tree (Gentoo) bzw. das ports-System (FreeBSD) so ausgefeilt und zuverlässig, dass ein gesonderter FTP-Download kaum empfehlenswert ist. Die systemeigenen Mechanismen erlauben es außerdem, zu entscheiden, ob man die Integration ins System der "Systemroutine" überlassen oder selbst vornehmen möchte.

Der wichtigste Unterschied zu einer Windows-Installation besteht wahrscheinlich darin, dass bei Installationsvorgängen auf einem Linux-Rechner die Software in der Regel aus den Sourcen kompiliert und damit an das vorhandene System angepaßt werden muss. Installationswerkzeuge wie z.B. YaST, anaconda oder apt-get greifen auf die vorkompilierten Pakete zu und erledigen die wenigen noch nötigen Kompiliervorgänge automatisch. Diese distributionsspezifischen Pakete sorgen mit im jeweiligen Header enthaltenen Anweisungen dafür, dass das Installationstool zusätzliche Systemscripts erstellt und Apache an den vom Distributor vorgesehenen Orten installiert. Man kann in den Installationsvorgang bei der Wahl einer solchen Methode nicht selbst eingreifen, und das kann bisweilen dazu führen, dass dann einige spezielle Module nicht vorhanden sind oder nicht auf die gewünschte Weise arbeiten. Wer die Arbeitsweise "seines" Apache wirklich verstehen und selbst festlegen möchte, sollte sich ihn Seite selbst kompilieren.

Die in diesem Artikel beschriebenen Beispiele wurden mit folgenden Distributionen getestet:

  • SuSE Linux 9.1
  • Fedora Core 2
  • Debian 3.0r2 (sarge)
  • Gentoo 1.4
  • FreeBSD 5.2.1 (FreeBSD ist kein Linux, was hier aber unberücksichtigt bleiben kann)

Wird der Apache unter Linux eingerichtet, müssen nicht alle Dateien in den Unterverzeichnissen eines gemeinsamen Apache-Verzeichnisses zu finden sein, obwohl man sich das natürlich auch so einrichten kann. Distributionen, die bestimmte Installationswerkzeuge nutzen (SuSE, Red Hat/Fedora und andere), legen die Dateien in Verzeichnisse, die die jeweiligen Distributoren für angemessen halten. Die Konfigurationsdatei liegt oft in einem Verzeichnis /etc/httpd oder /etc/apache2. Bei Red Hat 9 bzw. Fedora ist es, wenn man das distributionsspezifische RPM-Paket benutzt, /etc/httpd/conf.

Apache-konf-1.png

Ab Apache 2.0.49 gehen mehrere Distributionen (zumindest SuSE Linux 9.x, Debian 3.0r2 (sarge) und Gentoo) eigene Wege bei der Zusammenstellung der Apache-Konfigurationsdatei. Sie wird in mehrere einzelne Dateien aufgeteilt. Vielleicht am weitesten geht dabei die SuSE: Die ursprüngliche httpd.conf wird in mehrere einzelne Dateien aufgetrennt und diese verschiedenen Konfigurationsdateien werden dann in einer neuen httpd.conf mit Hilfe des include-Befehls eingebunden.

httpd.conf

In Debian und Gentoo wird darüberhinaus der Dateiname httpd.conf gar nicht mehr verwendet, sie heißt jetzt apache2.conf. Etwas ausführlicher wird auf die Möglichkeit, die Konfigurationsdatei aufzusplitten, an der Seite entsprechenden Stelle dieses Artikels eingegangen.

Die ausführbare Datei kann httpd (Apache 1.3.x) oder httpd2 bzw. apache2 (Apache 2.0.x) heißen. In Debian 3.0r2 (sarge) und Gentoo ist es zum Beispiel /usr/sbin/apache2.

httpd

In SuSE Linux 9.1 ist es /usr/sbin/httpd2. Die Module werden meistens in /usr/lib/apache/modules (Apache 1.3.x) bzw. in /usr/lib/apache2/modules zu finden sein, und das Webverzeichnis ("DocumentRoot") legt die SuSE unter /srv/www/htdoc an, Debian schlägt /var/www/apache2-default vor. Die Ablageorte können also unterschiedlich ausfallen, je nachdem, welche Linux-Distribution benutzt wird, welche Apache-Version, und ob bei der Installation die Standard-Vorgaben des Distributors übernommen wurden oder nicht. Wird auf eine distributionsspezifische Installation verzichtet und der Apache individuell aus den Sourcen kompiliert, wird häufig der Vorschlag der Apache Software Foundation übernommen und als Installationsort /usr/local/apache oder /usr/local/apache2 gewählt. Jedoch kann man die Ablageorte selbstverständlich selbst bestimmen.

Gestartet werden kann der Apache durch den Aufruf seines Namens:

httpd2 -k start

Einige Distributionen starten den Apache Webserver nicht unmittelbar, sondern lassen ihn von einem Script apachectl bzw. apachectl2 aufrufen. Dem Startaufruf können unterschiedliche Parameter mitgegeben werden.

Meistens möchte man, dass der Webserver sofort bei Systemstart initialisiert und ebenfalls gestartet wird. Er soll also als "Daemon" im Hintergrund eingesetzt werden. Das ist problemlos möglich, jedoch unterscheiden sich auch hier wieder die Distributionen teilweise erheblich in der Art, wie man solche Hintergrunddienste einrichten kann. Das Initialisierungsscript, das meist in /etc/init.d abgelegt oder dorthin verlinkt wird, ist im Sourcenpaket unter dem Namen httpd.init enthalten. Es wird auch dann angelegt und distributionsspezifisch angepaßt, wenn man sich seinen Apache selbst kompiliert. Als Systemadministrator muss man lediglich dafür sorgen, dass dieses Script auch tatsächlich von den Start-/Stop-Scripts des jeweiligen Runlevels angesprochen wird.

SuSE Linux 9.1: Die SuSE macht es, wie fast immer, etwas komplizierter. Es gibt in YaST einen speziellen Bestandteil, der "Runlevel-Editor" heißt

YaST-Runlevel-Editor

und mit dessen Hilfe sich einstellen läßt, welche Dienste aktiviert werden sollen. Darüberhinaus gibt es einen "Editor für /etc/sysconfig-Dateien".

YaST-sysconfig-Editor

Hier können einige Konfigurationsschritte absolviert werden, allerdings sollte damit vorsichtig umgegangen werden, da dieser Editor unmittelbar die in die httpd.conf eingebundenen Dateien bearbeitet.

Fedora Core 2: Ähnlich wie in SuSE gibt es auch hier einen kleinen grafischen Editor, der ebenfalls nichts anderes tut, als die Initialisierungsscripte von /etc/rc.d/init.d zu den gewünschten Runleveln zu verlinken.

Fedora-Dienste

Debian 3.0r2 (sarge): Software, die mit apt-get installiert wird und als Dienst bzw. daemon eingesetzt werden soll, erhält automatisch ein Initialisierungsscript in /etc/init.d. Auch für den Apache gibt es ein solches Initialisierungsscript. Das Verzeichnis /etc/init.d wird während des Systemstarts ausgelesen. Eine Kontrollmöglichkeit, welche Dienste gestartet werden, bietet das kleine Programm rcconf.

Debian - rcconf

Gentoo: Auch hier gibt es ein kleines Initialisierungsprogramm, das dafür sorgt, dass die nötigen Links und Scripte erstellt oder aktualisiert werden. Mit dem Konsolenbefehl rc-update add apache default werden die benötigten Links erzeugt und im Verzeichnis /etc/runlevels/default abgelegt.

FreeBSD 5.2.1: Während des Systemstarts wird außer in /etc/rc.d auch im Verzeichnis /usr/local/etc/rc.d nach Scripts gesucht, die die lokal installierten "Daemonen" starten. Wenn der Apache über den port oder mit pkg_add installiert wurde, liegt hier ein kleines Shellscript, das apache.sh bzw. apache2.sh heißt und für den Start des Apache-Daemons zuständig ist. Eventuell muss der Name des Scripts korrigiert werden, und das Script muss ausführbar sein, dann startet Apache als Hintergrunddienst bei Systemstart. Ab Apache 2.0.49 kann eine Zeile apache2_enable="YES" dafür sorgen, dass der Apache gemeinsam mit dem Betriebssystem als "Dämon" hochgefahren wird und seine Funktionalität zur Verfügung stellt.

Auf einem Windows-System[Bearbeiten]

Wer sich einen Apache unter Windows einrichten möchte, muss sich zunächst entscheiden, welche Version installiert werden soll und dabei auch berücksichtigen, welche Windows-Version auf seinem Rechner vorhanden ist. Grundsätzlich ist zwar Apache 2.0.x zu empfehlen, manchmal gibt es jedoch Gründe, den älteren Apache 1.3.x einzusetzen. Für beide Versionen stellt die Apache Software Foundation in ihrem englischsprachige Seite Download-Archiv Installer-Pakete bereit, erkennbar an der Dateinamenserweiterung MSI. Wer die Sourcen ebenfalls haben möchte, kann sich eines der ZIP-Archive von http://www.apache.de/dist/httpd dazu downloaden.

In den Diskussionen des SELFHTML Forum wird gelegentlich auch auf Apache-Installationen aus sogenannnten bundle-Lösungen aufmerksam gemacht. Es gibt mehrere Anbieter wie zum Beispiel englischsprachige Seite Foxserv oder deutschsprachige Seite Apachefriends, die ein bereits fertig zusammengestelltes WAMP- bzw. LAMP-Paket zum Download anbieten, womit man sich einige Schritte bei der Software-Installation sparen kann. Leider sind diese Pakete oft so "voreingestellt", dass es schwer fällt, im Nachhinein Systempfade und ähnliches an die eigene Rechnerkonfiguration anzupassen oder einzelne Teilpakete auf neuere Versionen umzustellen. Günstiger ist es sicherlich, sich Software immer von der Originalquelle zu besorgen.

Die vorgestellten Beispiele wurden mit Hilfe folgender Windows-Rechner überprüft:

  • Windows 98 SE
  • Windows 2000 (mit Servicepack 4)
  • Windows XP (mit Servicepack 1)

Grundsätzlich ist die Installation mit Hilfe eines der MSI-Installerpakete zu empfehlen. Der Microsoft-Installer, der für das Ausführen solcher Installationsdateien zuständig ist, gehört ab Windows 2000 zum Betriebssystem. Für ältere Windows-Versionen muss man sich unter Umständen zuerst den Installer besorgen, was von der entsprechenden englischsprachige Seite Download-Seite geschehen kann. Wird die MSI-Datei aufgerufen, erscheint dann, unabhängig von der eingesetzten Windows-Version, einer der bekannten "Assistenten".

Apache-Installer

Ein kurzer Dialog mit diesem Assistenten begleitet die Installation. Zuerst müssen ein Domainname, ein Servername und eine mail-Adresse für den Administrator angegeben werden. Wenn man nicht Inhaber einer eigenen Domain ist oder den Apache in einem lokalen Netz zu Testzwecken einrichten möchte, sollte hier nicht versucht werden, einen realen Domainnamen anzugeben, den es im Internet bereits gibt. Die Option, den Apache als Dienst für alle Benutzer einzurichten, ist auf einem Win9x-Rechner problematisch. Sie kann nur dann erfolgreich eingesetzt werden, wenn alle von Microsoft bereitgestellten Updates eingespielt wurden. Der Installer für Apache 1.3.31 ist prinzipiell in der Lage, den Server auch unter Windows 98SE als Hintergrunddienst einzurichten, ab Windows 2000 ist das ohnehin kein Problem.

Apache-Installer

Das nächste ist die üblich gewordene Option, eine komplette Installation ausführen zu lassen oder sie persönlich zu steuern. Auch hier gilt, dass eine benutzergesteuerte Installation ("custom") immer zu empfehlen ist.

Apache-Installer

Mit der "benutzergesteuerten Installation" lässt sich festlegen, welche Software-Bestandteile man gern haben möchte und vor allem läßt sich der Pfad zum Installationsverzeichnis individuell bestimmen. Der voreingestellte "default"-Pfad ist C:\Programme\Apache Group\. Für die in diesem Artikel benutzten Beispiele wurde die Auswahl aber grundsätzlich so getroffen, dass am Ende ein Verzeichnis D:\Apache vorhanden ist.

Schließlich wird der Installationsprozeß gestartet. Die Dateien werden auf die Festplatte kopiert, wobei Domainname, Servername und Administrator-Mailadresse in die httpd.conf geschrieben werden, zugleich werden die nötigen Einträge in der registry vorgenommen. Je nach der Leistungsfähigkeit des Rechners dauert das einige wenige Minuten.

Apache-Installer

Zuletzt meldet der Assistent noch, dass alles korrekt verlaufen ist. Ein Systemneustart ist in der Regel nicht erforderlich.

Diese Schritte sind für Apache 1.3.31 und Apache 2.0.50 identisch und laufen auf den verschiedenen Windows-Versionen in gleicher Art ab. Der Installer versucht noch, den Webserver sofort zu starten, was in der Regel problemlos geschehen sollte. Sofern die Option, den Apache als Dienst einzurichten, bestätigt wurde, versucht die Installationsroutine zusätzlich, diesen Dienst zu initialisieren. Der Apache läuft dann bereits als Hintergrunddienst und kann im Browser mit der Adreßeingabe http://localhost oder http://127.0.0.1 aufgerufen werden. Es erscheint das Standard-Dokument:

Standardseite

Damit ist die Installation abgeschlossen. Alles, was jetzt noch folgt, betrifft die Konfiguration und Administration des neu installierten Webservers.

Windows98SE (Apache 1.3.31) Nach einer vollständigen ("complete") Installation des Apache Webservers 1.3.31 auf einem Windows 98 SE-Rechner zeigt der Windows-Explorer folgenden Inhalt des Verzeichnisses D:\Apache:

Apache 1.3.31-Verzeichnis unter Windows

  • D:\Apache\bin - enthält einige Programmdateien zur Generierung von Paßwörtern sowie ein PERL-Script.
  • D:\Apache\cgi-bin - ist das voreingestellte Verzeichnis, in dem cgi-Scripts (PERL) abgelegt werden können.
  • D:\Apache\conf - enthält die zentrale Konfigurationsdatei, Sicherheitskopien dieser Datei und zusätzliche Konfigurationsdateien.
  • D:\Apache\htdocs - gilt vorläufig als "DocumentRoot" und enthält sämtliche Dokumente, die der Webserver bei entsprechenden Anfragen weitergeben soll sowie die Online-Dokumentation.
  • D:\Apache\icons - eine Reihe kleiner Grafiken, die bei der Darstellung von servergenerierten Dokumenten eingebunden werden.
  • D:\Apache\include - enthält Header-Dateien, die beim Kompilieren benötigt werden könnten.
  • D:\Apache\lib - einige wenige ebenfalls zum Selber-Kompilieren benötigte Bibliotheken.
  • D:\Apache\libexec - einige weitere Bibiliotheken.
  • D:\Apache\logs - dient zur Aufnahme von Protokolldateien.
  • D:\Apache\modules - enthält die zur Laufzeit zuladbaren Module.
  • D:\Apache\proxy - nimmt die Dateien auf, die bei einem Proxy-Einsatz zwischengespeichert werden sollen.
  • D:\Apache\src - enthält in mehreren weiteren Unterverzeichnissen den Quellcode.

Nur die drei mit fetter Schrift hervorgehobenen Unterverzeichnisse sind tatsächlich zwingend nötig - allerdings wird ein "DocumentRoot" (das hier zunächst D:\Apache\htdocs heißt und unter anderem das Standard-HTML-Dokument enthält) ebenfalls zwingend benötigt, nur sollte das nicht unbedingt an diesem Ablageort belassen, sondern mit der entsprechenden Modifikation der dafür zuständigen Anweisung in der httpd.conf an anderer Stelle, günstigerweise auf einer eigenen Partition oder Festplatte, zugeordnet werden. Dazu folgen später weitere Erläuterungen.

Das Apache-Verzeichnis selbst enthält neben einigen Informationsdateien, deren Lektüre sehr zu empfehlen ist, die zentrale ausführbare Datei apache.exe sowie die fundamentale Betriebsbibliothek ApacheCore.dll und einige wenige weitere Dateien wie zum Beispiel die Lizenz. Lesenswert ist die relativ kleine Datei WARNING-WIN.TXT.

Der Installations-Assistent legt nicht nur diese Verzeichnisse an, sondern erstellt auch eine neue Programmgruppe für das Startmenü.

Startmenü Apache 1.3.31

Dafür, dass der Apache bei Systemstart als Dienst gleich mitgestartet wird, sorgt eine Eintragung in die registry unter dem Schlüssel HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices. Diese Möglichkeit, einen Apache 1.3.x oder 2.0.x als Dienst starten zu lassen, gibt es nur dann, wenn die von Microsoft angebotenen Updates eingespielt wurden.

Registryeinträge

Existiert eine solche Eintragung nicht, kann "D:\Apache\Apache.exe" -k start -n Apache von Hand an der entsprechenden Stelle in die registry eingefügt werden. Damit ist dann die Grundinstallation erfolgreich verlaufen und es kann danach an die Feinarbeit herangegangen werden. Das heißt, um die Aufgaben, die Apache erledigen soll, genauer festzulegen, ist es nurmehr erforderlich, die individuellen Anpassungen dafür in der httpd.conf vorzunehmen.

WindowsXP (Apache 2.0.50) Der Assistent macht freundlich auf die zu installierende Apache-Version aufmerksam.

Apache-Installer

Der optische Ablauf gestaltet sich so wie nach oben oben beschrieben. Der Server wird sofort nach Abschluß der Installation gestartet und läuft danach als Systemdienst im Hintergrund. Man sieht es daran, dass nacheinander zwei "DOS-Fenster" kurz geöffnet und rasch wieder geschlossen werden, danach sind im Task-Manager zwei Apache-Prozesse mit unterschiedlicher Speicherbelastung zu finden. Auch in der registry gibt es einige neue Einträge, der vielleicht wichtigste läßt sich hier, anders als in Windows 9x, unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Apache2 finden.

Apache-Registryeinträge

Dieser Schlüssel ist auch dafür zuständig, dass der Apache in der Liste der Dienste aufgeführt wird.

Dienst

Die Programmgruppe im Startmenü zeigt mehrere neue Einträge, wie sie bereits von Apache 1.3.31 her bekannt sein können

Startmenü Apache 2.0.50

und am Inhalt der Systemordner hat sich gegenüber Apache 1.3.31 einiges verändert. Die ausführbare Datei liegt jetzt im Verzeichnis D:\Apache\bin, neu hinzugekommen ist ein Verzeichnis D:\Apache\error mit einigen vorformulierten Fehlermeldungen, die Dokumentation liegt jetzt in einem eigenen Verzeichnis, der Inhalt des Modul-Verzeichnisses ist erheblich erweitert worden und das Stammverzeichnis ist bis auf wenige Textdateien vorläufig leer.

Apache 2.0.50-Verzeichnis unter Windows

Auch hier gilt, dass für einen Testlauf nur vier Unterverzeichnisse wirklich zwingend benötigt werden. Das Verzeichnis D:\Apache\bin gehört bei einem Apache 2.0.50 selbstverständlich dazu.

Apache selbst kompilieren[Bearbeiten]

auf einem Linux-System[Bearbeiten]

Wie jede andere Software kann selbstverständlich auch der Apache auf dem eigenen System kompiliert werden. Dazu muss das Archiv mit den Sourcen natürlich vorhanden, also von der entsprechenden download-Adresse besorgt worden sein. Die Quellpakete werden als komprimierte Archive vertrieben, überwiegend als *.tar.gz-Archive, und müssen zunächst entpackt werden. Dafür steht der Befehl tar zur Verfügung, der in folgender Form eingesetzt werden kann:

tar -xvzf Archivname

Damit wird das Archiv am selben Ort ausgepackt, beispielsweise in /usr/install (so ein Verzeichnis kann man sich schließlich leicht erstellen). Es gibt auf den grafischen Oberflächen auch Tools, die ähnlich wie WinZip arbeiten - bei KDE ist es das kleine Programm ark, das ein solches Auspacken erledigen kann. Somit kann der Einsatz von tar umgangen werden, was für manche Linux-Benutzer leichter ist, da es inzwischen viele gibt, die nicht gerne Konsolenbefehle tippen, sondern sich eher auf Mausklicks verlassen. Ist dieser Vorgang abgeschlossen, wechselt man in das Verzeichnis mit den eben ausgepackten Dateien, dann folgen nacheinander die nächsten drei Schritte auf der Konsole bzw. im Terminal (XTerm). Es versteht sich von selbst, dass diese Arbeit vom Administrator (root) ausgeführt werden muss:

Beispiel
# Konfigurationsanweisungen ./configure --prefix=PFAD ... [weitere Anweisungen] ... # Bau der Software make # Installation in das Betriebssystem make install

Wer sicher ist, dass make das gewünschte Ergebnis liefert, kann auch gleich make install vorgeben. Der "make"-Befehl sollte, ebenso wie ein C-Compiler, zum System gehören, aber beispielsweise die SuSE 9.1 installiert beides nicht mehr automatisch, man muss sich also vergewissern, dass make auch wirklich zur Verfügung steht.

configure ist ein Shellscript, das mit den Sourcen vertrieben wird und unter anderem in die Makefiles den als "PFAD" angegebenen Installationsort schreibt. Wer über genügend Erfahrung und/oder Motivation verfügt, kann auch dieses Script nach seinen Vorstellungen modifizieren. Aber Achtung: das "configure"-Script für Apache 2.0.50 enthält deutlich über 18 000 Zeilen (bei Apache 1.3.x waren es noch 1 700). Auch die Art, welche Module wie behandelt werden sollen, regelt dieses Script. Dazu werden der "configure"-Anweisung noch Optionen mitgegeben, was folgendermaßen aussehen kann:

Beispiel
./configure --prefix=PFAD\ --enable-rewrite=shared \ --enable-speling=shared

Damit würden das Modul mod_rewrite sowie das Modul mod_speling kompiliert und in das Zielverzeichnis kopiert, so dass sie später über die LoadModule-Anweisung in der httpd.conf angesprochen werden können.

./configure stellt eine mächtige Anweisung dar, die große Sorgfalt verlangt. Die einfachste Möglichkeit, alle zulässigen Optionen für ./configure kennenzulernen, besteht darin, dass man sich die entsprechende Liste mit

./configure --help

anzeigen läßt. Die Ausgabe ist relativ umfangreich. Wer sich diese Ausgabe einmal anschauen möchte, findet sie hier: Popup-Seite configure-Hilfe

./configure muss immer ausgeführt werden, da sonst beispielsweise nicht bekannt ist, wohin die fertigen Dateien eigentlich installiert werden sollen. Als "PFAD" wird in den README-Dateien zum Apache /usr/local/apache vorgeschlagen bzw. /usr/local/apache2. Man kann diesem Vorschlag folgen oder ihn den eigenen Vorstellungen entsprechend abändern - die Linux-Distributionen folgen diesem Vorschlag in der Regel nicht, wie Seite weiter vorn bereits dargestellt wurde. Mit make wird der eigentliche Kompiliervorgang angestoßen, der einige Zeit in Anspruch nehmen kann. Danach liegen die gewünschten Dateien bereits vor, befinden sich aber noch nicht am korrekten Ort, sondern in temporären Verzeichnissen. Das ist übrigens auch der Zustand, der für die Zusammenstellung von "Paketen" der einzelnen Distributionen genutzt wird. Es gibt die Gelegenheit, falls man das wünscht, die Dateien anhand des entstandenen Protokolls zu kontrollieren und den Kompiliervorgang gegebenenfalls zu wiederholen, falls irgendetwas nicht wunschgemäß verlaufen ist. Der letzte Schritt, make install, verschiebt die Dateien schließlich an den gewünschten Installationsort innerhalb des Systems, erstellt nötigenfalls die zugehörigen Verzeichnisse und Links, dann kann man die Software benutzen. Um die temporär während des Kompilierlaufes erzeugten Dateien zu löschen, kann danach noch make clean eingegeben werden.

Für den Apache könnte so ein Ablauf also folgendermaßen aussehen:

Beispiel
# Software-Archiv auspacken tar -xvzf httpd-2.0.50.tar.gz # Wechsel in das Installationsverzeichnis cd httpd-2.0.50 # Konfigurationsanweisungen ./configure --prefix=/usr/local/apache2 # Bau der Software make # Installation make install # Entfernen temporärer Dateien make clean

Wer sicher ist, dass dabei keine Fehler oder Probleme auftauchen, kann diese Konsolenbefehle auch in ein kleines eigenes Shellscript schreiben, das die gesamte Installationsarbeit erledigt. Werden, wie hier, keinerlei Optionen oder nur Optionen mit dem Zusatz "=shared" für dynamisch zuladbare Module notiert, entsteht eine ausführbare Datei httpd bzw. httpd2 von ca. 2 MB Größe - und natürlich noch einiges andere. Je mehr Module ohne den Hinweis "=shared" eingebunden, also fest einkompiliert werden, desto größer wird auch die ausführbare Datei. Sollen viele Module später dynamisch angesprochen werden können, könnte der "./configure"-Befehl folgendermaßen aussehen:

Beispiel
./configure --prefix=/usr/local/apache2 --with-perl=/usr/local/bin/perl5.8\ --enable-so --with-mpm=prefork --with-port=80 --libdir=/usr/local/lib/apache2\ --includedir=/usr/local/include/apache2 --enable-v4-mapped --with-ssl=/usr\ --enable-mods-shared=all

Interessant ist die Option --enable-mods-shared=all. Sie bewirkt, dass sämtliche verfügbaren Module kompiliert werden, so dass sie später über die LoadModule-Anweisung eingebunden werden können. Und es ist zu beachten, dass alle diese Optionen für configure in einer Zeile hintereinander geschrieben werden müssen, hier sind die Backslashes lediglich zur besseren Lesbarkeit notiert worden, sie gehören nicht zum Scriptaufruf selbst.

Ist alles wunschgemäß verlaufen und die neue Software installiert, kann der Apache mit dem Befehl

httpd -k start

gestartet werden. Über die Zusammenstellung der Initialisierungsscripts, mit deren Hilfe der Apache Webserver als "daemon" bzw. Hintergrunddienst sofort während des Systemstarts hochgefahren wird, ist Seite weiter vorn bereits etwas ausgesagt worden.

Neben der Apache-Dokumentation gibt es noch ein paar weitere kleine Hilfstellungen, die auf der Konsole abgerufen werden können. Eine Anzeige der möglichen Startparameter erhält man mit httpd2 -h, was folgendes Bild ergibt:

Apache-Hilfe

Mit httpd2 -V erhält man also, gegebenenfalls zu Kontrollzwecken, eine Liste der Bedingungen, unter denen der Apache kompiliert wurde. Das entspricht den vorhin kurz umrissenen Vorgaben für configure. Und eine Liste der fest (statisch) einkompilierten Module kann man sich mit httpd2 -l ausgeben lassen. Wichtig gerade für das "Grundthema" dieses Artikels ist httpd2 -t, womit sich die Syntax der Konfigurationsdatei(en) prüfen läßt:

Apache-Hilfe Apache-Hilfe

auf einem Windows-System[Bearbeiten]

Manchmal möchte oder muss man sich den Apache Webserver auch auf einem Windows-Rechner selbst kompilieren. Dazu müssen die Sourcen natürlich vorhanden sein, die als ZIP-Archiv von englischsprachige Seite http://www.apache.de/dist/httpd heruntergeladen werden können. Allerdings setzt ein solches Vorhaben voraus, dass ein entsprechender C-Compiler auf dem Rechner vorhanden ist, der mindestens den make-Befehl beherrscht und ausführen kann. Mit den Sourcen liefert die Apache Software Foundation bereits ein paar für Microsoft Visual C++6 geeignete Projektfiles mit, die nach entsprechender Systemanpassung genutzt werden können. Ein Konfigurationsscript, das mit configure vergleichbar wäre, steht unter Windows allerdings nicht zur Verfügung.

Visual C++ 7

Eine sehr kurze Anleitung dazu findet sich in D:\Apache\htdocs\manual in der Datei win_compiling.html.html (Apache 1.3.31) bzw in D:\Apache\manual\platform in der Datei win_compiling.xml (Apache 2.0.50). Selbstverständlich gibt es dieselbe Anleitung auch online unter englischsprachige Seite http://httpd.apache.org/docs-2.0/platform/win_compiling.html. Alles weitere findet sich in den Hilfeseiten für Visual C++.

Ist der Apache erfolgreich kompiliert und fertig installiert worden, lassen sich auch unter Windows einige Befehlszeilen-Parameter aufrufen, die sich wiederum mit apache -? darstellen lassen und dieselben Ergebnisse zeigen wie die oben zitierten Ergebnisse auf einem Linux-System.

Apache-Hilfe

Der Aufbau der httpd.conf[Bearbeiten]

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.

Die Container mit den einzelnen Anweisungen[Bearbeiten]

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 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> und <IfModule>[Bearbeiten]

<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> und <DirectoryMatch>[Bearbeiten]

<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, dass als "Verzeichnisname" hier ein Regulärer Ausdruck Verwendung findet und kein Verzeichnisname.

<Files> und <FilesMatch>[Bearbeiten]

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

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

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, 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. Bei Apache 2.0.50 ist <Proxy> in der Regel nicht in der vorformulierten httpd.conf enthalten.

<VirtualHost>[Bearbeiten]

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 muss allerdings, dass 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 Seite später etwas ausführlicher eingegangen.

Umfangreichere Informationen über diese Container sind natürlich in der englischsprachige Seite Apache-Dokumentation zu finden.

Die Hauptabschnitte (Sektionen) der httpd.conf[Bearbeiten]

Im wesentlichen sind es drei "große" Funktionsabschnitte, die die unbedingt nötigen Festlegungen enthalten.

Global Environment (Globale Umgebung)[Bearbeiten]

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 (Apache 2.0.x), in der Regel port 80, es kann sinnvoll sein, einen anderen port für ein lokales LAN 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)[Bearbeiten]

Nachdem die Arbeitsumgebung definiert worden ist, folgen als nächstes die Anweisungen zur Arbeisweise. Arbeitsweise bedeutet dabei im wesentlichen:

  • Festlegung des vom Server beanspruchten Ports (Apache 1.3.x)
  • 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)[Bearbeiten]

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.

Virtuelle Hosts[Bearbeiten]

Will man den Apache Webserver lediglich dazu einsetzen, ein paar Scripts (Perl, CGI, PHP oder ähnliches) zu überprüfen, ist die Einrichtung von virtuellen Hosts nicht zwingend erforderlich. Ohne virtuelle Hosts kann man einen lokalen Apache ausschließlich mit zwei Adreßangaben nutzen: unter http://localhost und http://127.0.0.1 lassen sich die Serverfunktionen im Browser ansprechen und die lokalen Webinhalte darstellen. Vielfach genügt das bereits. Sofern der Webserver auch "von außen", also über das Internet, zugänglich gemacht werden soll, ist dies bereits möglich. Es kann dabei nur eine einzige Domain gehostet werden.

Mit eingerichteten virtuellen Hosts können jedoch "echte" Domainnamen in der Form http://www.domainname.tld in größerer Zahl verwendet werden, ohne dass dafür auch "echte" IP-Adressen vergeben worden sein müssen. Man könnte sich zum Beispiel vorstellen, dass die Adresse http://www.server.test eingesetzt werden soll. "test" ist hier eine TLD (Top Level Domain), die es im Internet nicht gibt, die aber von der Internet Corporation for Assigned Names and Numbers (englischsprachige Seite ICANN) für private Zwecke reserviert wurde (siehe englischsprachige Seite ftp://ftp.rfc-editor.org/in-notes/rfc2606.txt). Ein Browser kann einen Servernamen dieser TLD nur ansprechen, wenn er tatsächlich vom lokalen Webserver bereitgestellt wird - unter "lokal" muss nicht unbedingt physikalisch derselbe Rechner verstanden werden, das kann auch ein lokales Netzwerk sein.

Da die "Namensauflösung" über einen DNS-Mechanismus vollzogen wird, muss es eine Möglichkeit geben, den neuen Namen www.server.test irgendwie der bzw. einer IP-Adresse zuzuordnen. Das geschieht, indem der Umstand ausgenutzt wird, dass während des Aufbaus einer Verbindung zu einer Domain zunächst nach einem DNS gesucht wird, der die vorgesehene Namensauflösung registriert hat. In diese Suche ist die Abfrage der lokalen hosts-Datei integriert. Man kann sich auch (muss aber nicht unbedingt) auf einer Linux-Maschine relativ einfach einen lokalen DNS-Server (Nameserver) einrichten. Auf einer Windows-Maschine ist die Einrichtung eines Nameservers etwas schwieriger - Server-Systeme wie Win2003 Server enthalten entsprechende Software, die "Professional"- oder "Personal"-Systeme für Arbeitsplatzrechner enthalten sie nicht.

Die lokale hosts-Datei als DNS-Ersatz[Bearbeiten]

Es hat historische Gründe, dass für die Namensauflösung nicht unbedingt ein komplettes Softwarepaket benötigt wird, sondern in kleineren Netzen eine lokale hosts-Datei genügt. Auf einer Linux-Maschine ist das /etc/hosts. Auf einer Windows 9x-Maschine gibt es eine solche Datei nur dann, wenn TCP/IP installiert ist. Sie kann unter dem Namen hosts.sam im %windir% liegen, also meistens wohl C:\Windows\hosts.sam. Der Dateiname muss zu hosts korrigiert werden. Ab Windows 2000 gibt es die Datei %systemroot%\system32\drivers\etc\hosts.

Ohne eigene Eintragungen sieht die hosts-Datei in der Regel erst einmal folgendermaßen aus:

Beispiel
# /etc/hosts diese Datei enthält eine Anzahl von Hostname-zu-Adresse- # Übersetzungen für das TCP/IP-Subsystem. Das wird hauptsächlich # während des Hochfahrens benötigt, wenn noch kein Nameserver # gestartet ist. # Auf kleinen Systemen kann diese Datei auch als Ersatz für einen # Nameserver dienen. # Syntax: # IP-Adresse vollständiger Hostname kurzer Hostname # # spezielle IPv6-Adressen ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts # IPv4-Adressen 127.0.0.1 localhost

und auf einer Windows-Maschine:

Beispiel
# Copyright (c) 1993-1999 Microsoft Corp. # # Dies ist eine HOSTS-Beispieldatei, die von Microsoft TCP/IP # für Windows 2000 verwendet wird. # # Diese Datei enthält die Zuordnungen der IP-Adressen zu Hostnamen. # Jeder Eintrag muss in einer eigenen Zeile stehen. Die IP- # Adresse sollte in der ersten Spalte gefolgt vom zugehörigen # Hostnamen stehen. # Die IP-Adresse und der Hostname müssen durch mindestens ein # Leerzeichen getrennt sein. # # Zusätzliche Kommentare (so wie in dieser Datei) können in # einzelnen Zeilen oder hinter dem Computernamen eingefügt werden, # aber müssen mit dem Zeichen '#' eingegeben werden. # # Zum Beispiel: # # 102.54.94.97 rhino.acme.com # Quellserver # 38.25.63.10 x.acme.com # x-Clienthost 127.0.0.1 localhost

Die Kommentarzeilen kann man problemlos streichen. Für ein Beispiel soll nun zunächst davon ausgegangen werden, dass es zwei über ein Kabel miteinander kommunizierende Rechner gibt, die pc1 und pc2 heißen, wobei auf jedem ein Apache installiert ist. Dann sieht, noch ohne virtuelle hosts, die hosts-Datei beispielsweise so aus:

Beispiel
# lokale hosts-Datei 127.0.0.1 localhost 192.168.0.1 pc1 192.168.0.2 pc2

Damit wird nur dafür gesorgt, dass ein ping Rechnername im lokalen Netz funktioniert, und nicht nur ein ping lokale_IP. Es kommen jetzt noch die Einträge für die vorgesehenen virtuellen Hosts hinzu, wobei die Festlegung der IP-Adressen mehr oder weniger zufällig erfolgt:

Beispiel
# hosts-Datei # lokale IP-Adressen 127.0.0.1 localhost 192.168.0.1 pc1 192.168.0.2 pc2 # virtuelle Hosts 192.168.0.2 www.server1.test 172.24.10.2 www.server2.test 172.24.10.2 www.server3.test 10.0.0.1 www.server4.test

Hier sollen also für den Rechner pc2 vier virtuelle Hosts erzeugt werden, wobei die lokalen Domains www.server1.test und www.server3.test namensgestützte virtuelle Hosts werden sollen, und www.server2.test sowie www.server4.test werden IP-gestützte virtuelle Hosts.

Beachten Sie: Wird hier ein "echter" Domainname, den es tatsächlich im Internet gibt (beispielsweise de.selfhtml.org), einer lokalen IP-Adresse zugeordnet, kann ein Browser das im Internet vorhandene Webangebot nicht mehr darstellen. Daher sollten zur Vermeidung möglicher Konflikte grundsätzlich lokale TLDs wie beispielsweise "test" verwendet werden.

Die Konfiguration virtueller Hosts kann auf zwei einander ähnlichen Wegen erfolgen, entweder als namensgestützter (namebased) virtueller Host oder als IP-gestützter (ipbased) virtueller Host. Bei allen Überlegungen, ob und wie man sich einen virtuellen Host einrichten möchte, steht zuerst immer die Kontrolle, ob in der Modul-Liste der httpd.conf auch das zuständige Modul eingebunden wurde. Soll nur ein einzelner virtueller Host als _default_ eingerichtet werden, so genügt das ja immer vorhandene core-Modul, das den <VirtualHost>-Container bereitstellt (bzw. http_core in Apache 1.3.x). Sollen Anweisungen wie VirtualScriptAlias oder VirtualDocumentRoot benutzt werden, muss die Modul-Liste zusätzlich diesen Eintrag enthalten:

Beispiel
... LoadModule vhost_alias_module modules/mod_vhost_alias.so ...

Namensgestützte virtuelle Hosts[Bearbeiten]

Zunächst werden die benötigten Verzeichnisse auf dem Rechner erstellt, auf dem der Apache installiert ist und die später als DocumentRoot genutzt werden sollen. SuSE Linux sieht seit einiger Zeit dafür ein Verzeichnis /srv/www vor, Red Hat/Fedora ein Verzeichnis /var/www, FreeBSD ein Verzeichnis /usr/local/www usw. Auf einer Windows-Maschine kann das beispielsweise D:\www sein. Man kann diesen Vorschlägen folgen, aber auch ein beliebiges anderes Verzeichnis wählen, lediglich /home/Benutzername sollte besser nicht genommen werden, da das das Arbeitsverzeichnis für einen angemeldeten Benutzer darstellt und wesentlich andere Dateien enthalten kann als webtaugliche Dokumente. Will man genau sein, sollte dann wenigstens noch rasch eine index.htm erstellt und im neuen Verzeichnis abgelegt werden, damit der Apache etwas zur Übergabe an den aufrufenden Browser vorfindet - beliebige Unterverzeichnisse und weitere Webdokumente sind natürlich auch möglich. Der Verzeichnisname kann (wie hier) mit dem Servernamen des virtuellen Hosts übereinstimmen, das ist jedoch nicht Bedingung, es kann auch ein beliebiger anderer Verzeichnisname gewählt werden:

virthost-Verzeichnis

Namensgestützte virtuelle Hosts werden über dieselbe lokale IP angesprochen, die für den Rechner (bzw. dessen Netzwerk-Schnittstelle) gilt, auf dem der Webserver installiert wurde. Das kann beispielsweise 192.168.0.x sein oder 10.0.0.1 oder ähnlich - und wenn es keine lokale IP gibt, kann das auch die 127.0.0.1 sein. Dann werden am Ende der httpd.conf folgende Einträge vorgenommen:

Beispiel
NameVirtualHost 192.168.0.2 <VirtualHost 192.168.0.2> ServerName www.server1.test DocumentRoot "/var/www/server1" </VirtualHost>

beziehungsweise auf einer Windows-Maschine:

Beispiel
NameVirtualHost 192.168.0.2 <VirtualHost 192.168.0.2> ServerName www.server1.test DocumentRoot "D:/www/server1" </VirtualHost>

Und das wars auch schon. Bis auf die Pfadnamen gibt es hier keine plattformspezifischen Unterschiede zwischen Linux und Windows. Wichtig ist allerdings, dass eine Zeile NameVirtualHost 192.168.0.2 über dem <VirtualHost 192.168.0.2>-Container liegt, der die Konfiguration für den namensbasierten Host enthält. Ist keine eigene IP vergeben (weil der Rechner nicht an ein lokales Netzwerk angeschlossen ist), gilt zumindest die Loopback-Adresse 127.0.0.1, die ebenfalls für solche namensbasierte virtuelle Hosts eingesetzt werden kann (dann muss auch in der lokalen hosts-Datei der Name des virtuellen Hosts der IP 127.0.0.1 zugeordnet werden). Es soll der Vollständigkeit wegen noch erwähnt werden, dass nach Änderungen der Konfigurationsdatei der Apache neu gestartet werden muss. Tippt man dann in der Adreßzeile des Browsers http://www.server1.test ein, wird tatsächlich die Datei /var/www/server1/index.htm bzw. D:\www\server1\index.htm an den aufrufenden Browser übergeben - und zwar an jeden Browser auf jedem beliebigen an dieses lokale Netz angeschlossenen Rechner. Auch beliebige Unterverzeichnisse sind erreichbar, sie benötigen keine eigenen virtuellen Hosts. Je nach Bedarf können in einem <VirtualHost>-Container noch wesentlich mehr Anweisungen notiert werden. Nahezu alles, was im Abschnitt "main server configuration" eingetragen werden kann, ist auch innerhalb eines <VirtualHost>-Containers erlaubt. Mit dem hier angegebenen Beispiel ist die Verwaltung von zwei unterschiedlichen Domains möglich: http://localhost und http://www.server1.test. Im Abschnitt "main server configuration" wurde bereits ein DocumentRoot angegeben, das /var/www/localhost ist. Es handelt sich also tatsächlich um völlig unterschiedliche Verzeichnisse und somit auch um zwei verschiedene Webangebote.

Es kann nun sein, dass es gar keine Netzwerkkarte gibt, aber ein Modem oder einen anderen Anschluß für den Zugang zum Internet auf einem Einzelplatzrechner. In einem solchen Fall gibt es zwar die loopback-Adresse, aber keine "private" IP für den lokalen Rechner. Dem Netzwerkadapter wird in der Regel vom ISP die für eine DFÜ-Verbindung nötige IP dynamisch zugewiesen, so dass man sie bei Verbindungsaufbau natürlich noch nicht kennen und ihr also auch keinen virtuellen Host zuordnen kann. Eine solche "default"-Situation wird von den hier zum Vergleich bereits mehrfach genannten Linux-Distributionen grundsätzlich vorausgesetzt. Daher wird "default" anstelle einer IP-Adresse ein Platzhalter eingesetzt:

Beispiel
NameVirtualHost *:80 <VirtualHost *:80> ServerName www.server1.test DocumentRoot "/var/www/server1" </VirtualHost>

Der Apache beantwortet grundsätzlich alle Anfragen nach nicht aufgelösten Domainnamen so, als ob damit der erste vorhandene virtuelle Host gemeint sei. "Nicht aufgelöst" bedeutet, dass weder die gewünschte IP noch der gewünschte Domainname einer <VirtualHost>-Konfiguration zugeordnet werden können. Bei Verwendung des Platzhalters wird sogar http://localhost auf das unter DocumentRoot genannte Verzeichnis des <VirtualHost>-Containers verwiesen - selbst dann, wenn weiter oben im 2. Abschnitt der httpd.conf (main server configuration) ein anderes Verzeichnis als DocumentRoot vorgesehen wurde. Allerdings ist es nicht möglich, für den Platzhalter mehrere unterschiedliche virtuelle Domains zu definieren. Eine zusätzliche Domain ist möglich, wenn für den Platzhalter ein nach unten anderer port angegeben wird. Wenn man mehrere Domains verwalten möchte, obwohl keine IP-Adresse zur Verfügung steht, muss die loopback-Adresse anstelle des Platzhalters notiert werden.

Da die Methode zur Einrichtung eines namensgestützten virtuellen Hosts am einfachsten zu verstehen und zu befolgen ist, wird sie auch am häufigsten empfohlen.

IP-gestützte virtuelle Hosts[Bearbeiten]

In diesem Konzept wird nicht versucht, einer IP-Adresse mehrere Hostnamen zuzuordnen, sondern es wird für jeden möglichen virtuellen Hostnamen eine eigene IP-Adresse vorgegeben. Das ist ein bißchen komplexer, da man ja normalerweise außer der loopback-Adresse nur eine - in der Regel vom Provider zugewiesene - IP-Adresse für die DFÜ-Verbindung zur Verfügung hat und es wenig Sinn macht, für jeden vorgesehenen virtuellen Host eine neue Netzwerkkarte einzustecken - ganz abgesehen davon, dass die Computer-Hardware gar nicht so viele freie Slots zum Einstecken weiterer Karten bietet. Der Ausweg besteht in einem weiteren Konzept, das IP-Aliasing genannt wird und im wesentlichen bedeutet, dass jedem Netzwerkgerät nicht nur eine IP, sondern zusätzliche IPs in Form von Aliasen zugeordnet werden können.

  • IP-Aliasing mit Linux
  • flüchtige IP (non-persistent)

Das Vorgehen ist relativ einfach. Auf einer Linux-Maschine gibt es zwei Konsolenbefehle bzw. die dahinterstehenden Programme, die dafür verwendet werden können, ifconfig und ip. ifconfig ist der ältere Befehl, der auf jeder Linux-Maschine zur Verfügung stehen sollte, ip ist jünger, deutlich flexibler und mächtiger, aber (noch) nicht auf allen Distributionen Bestandteil des "core"-Systems. Man muss ihn eventuell gesondert installieren. ifconfig liefert, wenn man ihn ohne weitere Parameter aufruft, Informationen über Netzwerkschnittstellen, was bei einem Rechner, in dem es eine Ethernet-Netzwerkkarte gibt und der nicht über eine eigene aktive Internetverbindung verfügt, so aussehen kann:

iconfig

Es gibt in diesem Rechner also zwei Netzwerkgeräte, die eth0 und lo heißen - eth0 ist die Netzwerkkarte (für das LAN) und lo ist die immer vorhandene Loopbackadresse. Beide "Geräte" könnten nun IP-Aliase zugeordnet bekommen, hier soll es lediglich an der Ethernetkarte demonstriert werden. ifconfig kann mit verschiedenen Parametern aufgerufen werden, der einzige Parameter, den man ifconfig leider nicht zeigt, ist derjenige, der einen IP-Alias erzeugen kann. Ein solcher Alias kann auf folgende Weise erstellt werden:

ifconfig eth0:1 192.168.0.20

Damit dieser Alias wirksam werden kann, muss zwar nicht gleich der ganze Rechner, aber immerhin das Netzwerk neu gestartet werden, wofür es (nicht in allen Distributionen) den Konsolenbefehl rcnetwork restart gibt - eine Reinitialisierung der Netzwerkkarte mit ifup eth0 hat denselben Effekt. Danach liefert ifconfig folgende Anzeige:

ifconfig

Das heißt, für die Netzwerkkarte gibt es jetzt sowohl die IP 192.168.0.2 wie auch die IP 192.168.0.20. Beide IP-Adressen gehören zum selben (Sub-)Netz, was allerdings nicht Bedingung ist. Der IP-Alias könnte auch 10.0.4.34 oder irgendeine andere "private" IP mit anderer Netzmaske sein. Mit ifconfig eth0:x können bei Bedarf auch mehrere Aliase erzeugt werden, indem der Wert für x einfach hochgezählt wird.

Leider ist aber ein auf solche Weise erzeugter IP-Alias nicht persistent, das heißt, nach dem nächsten reboot ist er wieder weg und man darf ihn neu anlegen. Also muss nach anderen zuverlässigen Wegen gesucht werden, um den IP-Alias dauerhaft im System zu verankern. Fixe IP (persistent)

Die Scripts, die die Konfiguration für die Netzwerkschnittstellen enthalten, liegen unterhalb von /etc, wobei die Distributionen unterschiedliche Dateinamen und Ablageorte vorsehen.

SuSE Linux 9.1: Die Konfigurationsscripts liegen in /etc/sysconfig/network und tragen die Namen der Netzwerkschnittstellen. Unter "Name" wird dabei in SuSE Linux 9.1, anders als in vorausgegangenen SuSE-Versionen, die Hardware-Adresse verstanden. Das Script, mit dem eine Ethernetkarte angesprochen wird, kann also beispielsweise /etc/sysconfig/network/ifcfg-eth-id-00:30:84:40:09:ee oder ähnlich heißen, während /etc/sysconfig/network/ifcfg-lo für die Loopback-Schittstelle zuständig ist, außerdem gibt es eine gut kommentierte Vorlage /etc/sysconfig/network/ifcfg.template (Popup-Seite Vorlagenscript anzeigen). Sollen die in der nach oben oben als Beispiel dargestellten hosts-Datei notierten zusätzlichen IP-Adressen 172.24.10.2 und 10.0.0.1 wirksam werden, so muss /etc/sysconfig/network/ifcfg-eth-id-00:30:84:40:09:ee folgenden Inhalt bekommen:

Beispiel
BOOTPROTO='static' BROADCAST_1='192.168.0.255' IPADDR_1='192.168.0.2' NETMASK_1='255.255.255.0' NETWORK_1='192.168.0.0' BROADCAST_2='172.24.10.255' IPADDR_2='172.24.10.2' NETMASK_2='255.255.0.0' NETWORK_2='172.24.10.0' BROADCAST_3='10.0.0.255' IPADDR_3='10.0.0.1' NETMASK_3='255.0.0.0' NETWORK_3='10.0.0.0' REMOTE_IPADDR='' MTU='' STARTMODE='onboot' UNIQUE='Gcmk.V9wnhMKHJYC' _nm_name='bus-pci-0000:02:0e.0'

Fedora Core 2: Hier liegen die Konfigurationsdateien in /etc/sysconfig/network-scripts. Ist nur eine Netzwerkkarte vorhanden, heißt das zugehörige Script ifcfg-eth0. Für jeden gewünschten Alias wird ein weiteres Script erstellt, wobei die letzte Ziffer des Scriptnamens hochgezählt wird. ifcfg-eth1 ist demzufolge der erste Alias, ifcfg-eth2 der nächste usw. Die Scripts enthalten solche Einträge:

Beispiel
DEVICE=eth0 BOOTPROTO=static BROADCAST=10.255.255.255 IPADDR=10.0.0.1 NETMASK=255.0.0.0 NETWORK=10.0.0.0 ONBOOT=yes TYPE=Ethernet

Debian 3.0r2 (sarge): Debian macht es relativ einfach. Das Konfigurationsscript ist /etc/network/interfaces mit ungefähr diesem Inhalt:

Beispiel
auto lo eth0 eth0:1 eth0:2 iface lo inet loopback iface eth0 inet static address 192.168.0.2 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 iface eth0:1 inet static address 172.24.10.2 network 172.24.10.0 netmask 255.255.0.0 broadcast 172.24.255.255 iface eth0:2 inet static address 10.0.0.1 network 10.0.0.0 netmask 255.0.0.0 broadcast 10.255.255.255

Gentoo: Noch einfacher - das für die Schnittstellenkofiguration zuständige Script ist /etc/conf.d/net mit folgendem Inhalt:

Beispiel
# /etc/conf.d/net: iface_eth0="192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0" alias_eth0="172.24.10.2 10.0.0.1"

FreeBSD 5.2.1: Wesentliche Anweisungen zur Systemkonfiguration werden hier in einer /etc/rc.conf zusammengefaßt. Eine solche zentrale rc.conf gab es bei den Linux-Distributionen ursprünglich auch, ehe begonnen wurde, die System-Konfiguration in viele verschiedene Teile aufzusplitten. Die Einrichtung virtueller hosts in FreeBSD wird in einem deutschsprachige Seite Kapitel des Handbuchs. ausreichend dargestellt. Der Abschnitt in /etc/rc.conf kann so aussehen:

Beispiel
network_interfaces="lo0 rl0 sk0 tun0" ifconfig_sk0="inet 192.168.0.1 netmask 255.255.255.0" ifconfig_sk0_alias0="inet 172.24.10.2 netmask 255.255.0.0" ifconfig_sk0_alias1="inet 10.0.0.1 netmask 255.0.0.0"

Nach einem Neustart des Netzwerks oder gegebenenfalls einem reboot zeigt ifconfig (Gentoo):

iconfig

Achtung! In SuSE Linux 9.1 und Fedora Core 2 zeigt ifconfig solche fixen IP-Aliase nicht an, auch wenn sie vorhanden sind. Das liegt daran, dass ifconfig von anderen Systemeinstellungen (Kernelversion höher als 2.2) gehindert wird, IP-Aliase darzustellen. Für ip gibt es eine solche Einschränkung nicht, und dieser Konsolenbefehl steht auch in SuSE und in Fedora ohne gesonderte Installation zur Verfügung. Damit sieht die Anzeige dann eben so aus:

ip_addr

Der Informationsgehalt ist derselbe: alle drei IP-Adressen stehen mit den richtigen Netzmasken zur Verfügung und können in der httpd.conf für virtuelle Hosts eingesetzt werden.

IP-Aliasing mit Windows[Bearbeiten]

Ganz so einfach wie auf einer Linux-Maschine ist es auf einer Windows-Maschine (Windows 2000 / XP) nicht. Es gibt keine Scripts, in die man bloß eben mal was hineinzuschreiben braucht. Außerdem vergibt Windows an Geräte, die ihre IP über DHCP dynamisch erhalten sollen, die IP 169.254.213.96 als "dummy". Sollen IP-Aliase eingerichtet werden, so werden dafür die "Eigenschaften" eines Netzwerkgeräts (beispielsweise einer Ethernetkarte oder eines entsprechenden Netzwerkchips auf dem mainboard) geöffnet. Dort gibt es wiederum "Eigenschaften" für das TCP/IP-Protokoll: IP-Alias einrichten IP-Alias einrichten

Und dort schließlich gibt es eine Registerkarte "Erweitert". Hier können nun weitere, eventuell als Alias benötigte IP-Adressen eingegeben werden:

IP-Alias einrichten

Für das Beispiel wurde Wert darauf gelegt, dass die beiden neuen Aliaseinträge jeweils anderen (Sub-)Netzen angehören, man sieht es an der Netzwerkmaske. Die neuen Einträge werden mit "ok" bestätigt, damit ist die Einrichtung der Aliase vollständig. Man kann sich davon durch einen Blick in die registry überzeugen. Unter dem Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{13665A19-8468-4BE3-95C6-E750FFF90ECA}\Parameters\Tcpip sollte es jetzt die neuen IP-Adressen geben - der CLSID-Wert in den geschweiften Klammern kann auch aus einer etwas anderen Ziffern-/Buchstabenkombination bestehen:

IP-Alias einrichten

Zur Kontrolle kann man sich in der "Eingabeaufforderung" die vorhandenen IP-Adressen mit ipconfig -all anzeigen lassen:

IP-Alias einrichten

Dafür, dass auf Aliase Wert gelegt wurde, die verschiedenen (logischen) Netzen zugehören, gibt es einen einfachen Grund: das "private" Netz 192.168.0.x wird nicht nur zur Einbindung des Webservers benötigt, sondern auch dafür, dass über Freigaben verschiedene Rechnerlaufwerke unabhängig vom Webserver den anderen Rechnern zur Verfügung gestellt werden können. Die "Netzwerkumgebung" muss dazu euf eine einzige, klar definierte IP zugreifen können, die dem für die "Arbeitsgruppe" zuständigen Netz angehört. Wird eine zweite IP für dasselbe Netz vergeben (192.168.0.20 gehört zum selben Netz wie 192.168.0.2) so kann sich Windows nicht entscheiden und ersetzt die "default"-IP durch 0.0.0.0 - was sich allerdings erst bei einem Rechnerneustart bemerkbar macht. Dann ist der gesamte Rechner plötzlich nicht mehr im LAN erreichbar. Erst ein IP-Alias, der einem anderen Netz angehört, scheint dieses Verhalten blockieren zu können.

httpd.conf-Einträge für IP-gestützte virtuelle Hosts[Bearbeiten]

Der Rest der Konfiguration verläuft unabhängig von der Einsatzplattform und wird mit einigen wenigen Einträgen in der httpd.conf durchgeführt.

Beispiel
<VirtualHost 192.168.0.2> ServerName pc2 DocumentRoot "/var/www/localhost" </VirtualHost> <VirtualHost 172.24.10.2> ServerName www.server2.test DocumentRoot "/var/www/server2" </VirtualHost> <VirtualHost 10.0.0.1> ServerName www.server4.test DocumentRoot "/var/www/server4" </VirtualHost>

beziehungsweise auf einer Windows-Maschine:

Beispiel
<VirtualHost 192.168.0.2> ServerName pc2 DocumentRoot "D:/www/localhost" </VirtualHost> <VirtualHost 172.24.10.2> ServerName www.server2.test DocumentRoot "D:/www/server2" </VirtualHost> <VirtualHost 10.0.0.1> ServerName www.server4.test DocumentRoot "D:/www/server4" </VirtualHost>

Damit dürfte die manchmal (auch nach Lektüre der englischsprachige Seite Online-Dokumentation) nicht leicht verständliche Bezeichnung "IP-gestützt" doch etwas klarer werden. Alle nötigen Voraussetzungen sind erfüllt:

  • das Modul ist über "LoadModule" eingebunden
  • die nach oben lokale hosts-Datei existiert
  • Verzeichnisse für die Webinhalte in "DocumentRoot" sind angelegt
  • <VirtualHost>-Container für vorhandene IP-Adressen sind vorhanden

Dann sind drei unterschiedliche Domains ansprechbar:

http://pc2
http://www.server2.test
http://www.server4.test

Wegen der Zuordnung der Domainnamen zu lokalen IP-Adressen in der hosts-Datei stehen diese Domains ausschließlich im lokalen Netz zur Verfügung, auch dann, wenn der Rechner gleichzeitg eine aktive Internetverbindung hat.

Zu guter Letzt lassen sich, wenn es denn nötig sein sollte, beide Verfahren zur Erstellung virtueller Hosts kombinieren. Wenn es einen IP-Alias gibt, können ihm natürlich auch mehrere namensbasierte virtuelle Hosts zugeordnet werden. Entsprechend der nach oben oben als Beispiel angegebenen hosts-Datei kann der 3. Abschnitt der httpd.conf dann folgendes Aussehen erhalten:

Beispiel
<VirtualHost 192.168.0.2> ServerName pc2 DocumentRoot "/var/www/localhost" </VirtualHost> NameVirtualHost 192.168.0.2 <VirtualHost 192.168.0.2> ServerName www.server1.test DocumentRoot "/var/www/server1" </VirtualHost> <VirtualHost 172.24.10.2> ServerName www.server2.test DocumentRoot "/var/www/server2" </VirtualHost> NameVirtualHost 172.24.10.2 <VirtualHost 172.24.10.2> ServerName www.server3.test DocumentRoot "/var/www/server3" </VirtualHost> <VirtualHost 10.0.0.1> ServerName www.server4.test DocumentRoot "/var/www/server4" </VirtualHost>

Damit würden fünf verschiedene Domains in drei logisch voneinander abgegrenzten Netzen zur Verfügung stehen.

Unterschiedliche Ports verwenden[Bearbeiten]

Das Konzept der Ports gehört unmittelbar zu TCP/IP. Es wird in der entsprechenden RFC beschrieben (englischsprachige Seite RFC 793). Insgesamt gibt es 65 536 (216) ports, von denen die ersten 1024 (210) "reserviert" sind und die ersten 256 als "häufig verwendet" deklariert werden. Port 80 ist derjenige, der für das Hypertext Transfer Protocol (HTTP, siehe englischsprachige Seite RFC 2616) normalerweise vorgesehen ist. Der Apache ist ein HTTP-Webserver, daher findet sich im "Global Environment" der httpd.conf eine Zeile:

Listen 80

Apache 1.3.x kann anstelle von Listen im Abschnitt "main server configuration" eine Anweisung

Port 80

enthalten, die es für Apache 2.0.x nicht mehr gibt (Das Konzept, wie ports angesprochen werden, unterscheidet sich in beiden Apache-Versionen). Das bedeutet, dass Apache port 80 benutzt und alle vorhandenen IP-Adressen berücksichtigt, da dafür keine Einschränkung vorgegeben wurde. Man kann den Apache nun anweisen, nur einige ganz spezifische Adressen zu beachten, was so aussehen kann:

Listen 192.168.0.2:80
Listen 172.24.10.2:80
Listen 10.0.0.1:80

Vorsicht! Jetzt sind Einschränkungen formuliert, das heißt, Apache wird alles ignorieren, was sich nicht den drei explizit angegebenen IP-Adressen zuordnen läßt - also ist mit einer solchen Einstellung beispielsweise http://localhost nicht mehr erreichbar, da diese Adresse ja mit der IP 127.0.0.1 verbunden ist. Und die wäre bei einer solchen Vorgabe ausgeschlossen. Aber alle fünf nach oben oben konfigurierten lokalen Domains sind erreichbar. Wird, wie hier, eine Kombination IP-Adresse:Portnummer notiert, so muss dieselbe Notationsweise auch auf <VirtualHost>-Container angewendet werden:

Beispiel
... NameVirtualHost 192.168.0.2:80 <VirtualHost 192.168.0.2:80> ...

Wird das versäumt, kann es zu Fehlermeldungen im Syslog kommen, die ungefähr so lauten: "[error] VirtualHost 192.168.0.2:0 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results". Es kann gleichzeitig sein, dass der gewünschte virtuelle Host nicht erreichbar ist.

Wenn der Rechner, auf dem der Apache installiert ist, über eine aktive Internetverbindung verfügt und Apache auf port 80 eingestellt ist, ist er unter der aktuellen IP auch für Anfragen aus dem Internet erreichbar. Da es eine ganze Reihe von Robots und anderen Suchdiensten, aber auch ein paar "Schwarze Schafe" und aktive Viren bzw.Würmer gibt, kann das dazu führen, dass sich in den Protokollen (access_log) Zugriffsmeldungen finden wie zum Beispiel so etwas:

Beispiel
ideapilot-s01 - - [19/Jun/2004:14:33:00 +0200] "CONNECT 1.3.3.7:1337 HTTP/1.0" 405 1067 pd958e1a6.dip.t-dialin.net - - [20/Jun/2004:13:03:43 +0200] "SEARCH /\x90\x02 ... \x90\x90" 414 326 geosys03.kaist.ac.kr - - [22/Jun/2004:16:50:47 +0200] "CONNECT 1.3.3.7:1337 HTTP/1.0" 405 1067 traeumt.net - - [23/Jun/2004:01:16:51 +0200] "CONNECT 195.137.213.77:6667 HTTP/1.0" 405 1067 217.139.4.3 - - [30/Jun/2004:04:16:02 +0200] "GET /default.ida?XXXXXXXX%u9090%u6858%ucbd3%u7801 %u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b %u53ff%u0078%u0000%u00=a HTTP/1.0" 404 1204

Über die Interpretation der Protokolleinträge gibt es weiter weiter hinten etwas mehr Informationen, hier ist erst einmal wichtig, zu sehen, dass der Apache auf solche Anfragen reagiert. In allen Fällen mit Zurückweisungen, wobei die zweite Meldung eine möglicherweise sehr unerwünschte "Kontaktaufnahme" bedeuten könnte. Die fünfte Protokolleintragung dokumentiert den mißlungenen Versuch, einen Wurm (Nimda) über port 80 einzuschleusen - übrigens von einem im ägyptischen Gizeh ansässigen Provider aus. Ein ungeschützter IIS anstelle des Apache wäre damit infiziert worden. Solche Versuche, den Apache "von außen" zu erreichen, lassen sich deutlich zurückdrängen (aber nicht gänzlich vermeiden), wenn man ihm für den lokalen Gebrauch einen anderen port zuweist. Das kann beispielsweise in dieser Form geschehen:

Listen 192.168.0.2:32540
Listen 172.24.10.2:32555
Listen 10.0.0.1:25140

Port 80 ist damit zwar nicht "geschlossen" (das fällt in den Aufgabenbereich einer Firewall - ein Browser kann immer noch über port 80 beliebige Internetadressen erreichen), aber der lokale Apache interessiert sich nicht mehr für diesen port, sondern nur noch für die ports 32540, 32555 und 25140. Das heißt, obwohl es laut hosts-Datei einen auf die IP 172.24.10.2 gesetzten virtuellen Host www.server3.test geben sollte, passiert bei Aufruf von http://www.server3.test in der Adreßzeile eines Browsers gar nichts oder es gibt eine Fehlermeldung. Es muss also der port ebenfalls angegeben werden: http://www.server3.test:32555.

Man kann diese Konfigurationsmöglichkeit nutzen, um entgegen der nach oben oben aufgestellten Behauptung trotz fehlender IP-Adresse doch noch zwei verschiedene Webangebote zusammenzustellen, indem im Abschnitt "main server configuration" bereits ein DocumentRoot angegeben und in einem <VirtualHost>-Container ein anderes DocumentRoot festgelegt wird. Die relevanten Einträge in der httpd.conf sehen dann schematisch ungefähr so aus:

Beispiel
#====== global environment ===== ... Listen 80 Listen 2080 ... #====== main server configuration ===== ... ServerName Rechnername:80 DocumentRoot "/var/www/localhost" ... #===== virtual hosts ===== NameVirtualHost *:2080 <VirtualHost *:2080> ServerName www.server.test:2080 DocumentRoot "/var/www/server" </VirtualHost>

Im Browser bekommt man dann mit http://localhost oder http://Rechnername das in /var/www/localhost liegende Webangebot zu sehen, mit http://www.server.test:2080 dagegen das im Verzeichnis /var/www/server liegende Webangebot.

Welcher port benutzt werden soll, ist Ermessenssache des Server-Administrators. Es sollte allerdings möglichst keiner sein, der unterhalb der "reservierten" ports bis 1024 liegt.

Ein Beispiel für SELFHTML-Autoren[Bearbeiten]

In den Layoutvorgaben wird empfohlen, sich einen virtuellen Host einzurichten, wenn man beabsichtigt, eine Seite für den SELFHTML-Raum bereitzustellen - beispielsweise einen Seite Artikel. Die dafür nötige URL ist http://aktuell.de.selfhtml.org/artikel/. Es ist deutlich zu sehen, dass es sich um Unterverzeichnisse einer SELFHTML-Domain handelt, für den virtuellen Host wird also nur ein Äquivalent für http://aktuell.de.selfhtml.org benötigt. Entsprechend dem nach oben oben gegebenen Hinweis kann es jedoch Konflikte geben, wenn man bei diesem Domainnamen bleibt und ihm in der lokalen hosts-Datei eine lokale IP zuordnet. Es kann passieren, dass das online-Angebot von http://aktuell.de.selfhtml.org nicht mehr zur Verfügung steht, sondern stattdessen grundsätzlich der virtuelle Host sein Webangebot an den aufrufenden Browser schickt. Um dieses Problem zu vermeiden, sollte als Domainname besser aktuell.de.selfhtml.test gewählt werden.

Angenommen, es handelt sich bei dem Rechner, an dem der "virtuelle SELFHTML-Autor" seinen bedeutenden Beitrag schreiben möchte, um einen Einzelplatzrechner ohne Netzwerkkarte und mit einer dynamisch zugewiesenen IP, und der "virtuelle SELFHTML-Autor" möchte sich nur ganz schnell mal ohne viel Aufwand einen Apache wie Seite vorn beschrieben unter Windows einrichten, um sein Werk vor dem Absenden ans DEV-Team prüfen zu können. Es macht in diesem Fall keinen Sinn, in der hosts-Datei irgendeine lokale IP zu notieren. Da auch nur ein einziger virtueller Host benötigt wird, genügt die loopback-Adresse:

Beispiel
# lokale hosts-Datei 127.0.0.1 localhost 127.0.0.1 aktuell.de.selfhtml.test

Festlegungen zum gewünschten port sind nicht erforderlich, aber ein <VirtualHost>-Container wird natürlich benötigt:

Beispiel
NameVirtualHost 127.0.0.1 <VirtualHost 127.0.0.1> ServerName aktuell.de.selfhtml.test DocumentRoot "C:/selfaktuell" </VirtualHost>

Selbstverständlich müssen die nötigen Verzeichnisse noch rasch angelegt werden, was zu einem solchen Ergebnis führen kann:

W indows Explorer

Eventuell muss noch PERL und/oder PHP aktiviert werden, aber das ist ja kein Problem - und schon kann es losgehen mit dem Schreiben eines neuen Artikels.

Die Kommentare in der httpd.conf[Bearbeiten]

Der Apache ist mit einer umfangreichen Dokumentation ausgestattet, die man unter der Adresse http://localhost/manual aufrufen kann - vorausgesetzt, es wurde bei der Installation diese Dokumentation nicht ausgeklammert.

Wer das erste Mal mit dem Apache Webserver in Berührung kommt, kann sich beim Durchsehen dieser Dokumentation allerdings in zweierlei Hinsicht vor erhebliche Probleme gestellt finden. Einmal ist es ein auf den ersten Blick nicht überschaubarer Berg an Informationen, andererseits wird selten sofort klar, wo und wie denn nun diese Informationen in wirkungsvolle "Befehle" überführt werden können. Außerdem sind für eine erste Standard-Installation deutlich mehr als zwei Drittel der mit dieser Dokumentation angebotenen Informationen gar nicht zwingend erforderlich, und als eifriger Doku-Leser steht man dann nicht so sehr vor der Frage, welche Information man noch nicht gefunden hat, sondern eher vor dem Problem, das eine oder andere sofort wieder vergessen resp. vorläufig auslassen zu dürfen. Bloß: was braucht man nun unbedingt, und was kann man erst einmal überspringen?

Genau an dieser Stelle wird die Erfindung der Kommentare wichtig. Es handelt sich dabei ausschließlich um so etwas wie "Kürzest-Informationen" zu den wichtigsten Parametern, ohne die der Apache vermutlich nicht arbeiten würde.

Kommentarzeilen sollen vom ausführenden Programm ignoriert werden. Dazu müssen sie entsprechend gekennzeichnet sein, was in der httpd.conf mit der Raute (#) geschieht. Das Ergebnis kann dann so aussehen:

Beispiel
# "ServerType": Der Server-Typ ist entweder "inetd" oder "standalone". # "inetd" wird allerdings nur von Unix-Plattformen unterstützt/verwendet. # ServerType inetd # # "ServerRoot" bezeichnet die Spitze des Verzeichnisbaums, unter dem die # Server-Konfiguration, Fehleranzeigen und Protokolle zu finden sind. # # Am Ende dieser Zeile darf kein Slash stehen. # ServerRoot "/srv/www"

Grundsätzlich steht ein kommentierender kurzer Text vor dem eigentlichen Befehl, den er erläutert. Soll dieser Befehl von Apache ausgeführt werden, darf die entsprechende Zeile nicht durch ein "#" eingeleitet werden.

Kommentare in Scripts und/oder Konfigurationsdateien haben eine lange und gute Tradition. Sie werden grundsätzlich vom "System" nicht benötigt und müssen vor ihm verborgen werden, sollen aber dem (menschlichen) Administrator mit seiner langsameren und weniger logisch strukturierten Auffassungsgabe bei der Orientierung helfen und knappe Hinweise zum Sinn einer Befehlszeile geben. Wenn man seine eigenen Notizen oder irgendwelche Vermerke auf diese Weise in eine Konfigurationsdatei einbinden möchte, so steht dem nichts im Wege; allerdings sollten Kommentare auch nicht allzu lang werden. Kommentare haben eine Erinnerungsfunktion; sie wiederholen zusammengefaßt das, was die zum Script bzw. zum Softwarepaket gehörende Dokumentation ausführlich darstellt.

Die Online-Dokumentation[Bearbeiten]

Von Anfang an war der Apache mit dieser Dokumentation ausgestattet. Für den älteren Zweig (Apache 1.3.x) gibt es sie nur in englischer Sprache, wobei die Zusammenstellung als abgeschlossen gilt. Für den jüngeren Zweig fertigt ein Übersetzerteam Übersetzungen in zahlreiche Sprachen an, worüber man sich beim englischsprachige Seite Apache-Dokumentations-Projekt informieren kann. Diese Dokumentation gilt noch nicht als abgeschlossen, und es sind auch noch lange nicht alle ihre Bestandteile übersetzt. Format und Layout der Online-Dokumentation wurden drastisch verändert. Da die Arbeit an der Dokumentation noch nicht vollständig beendet ist, kann es auch sein, dass sich die unter englischsprachige Seite http://httpd.apache.org/docs-2.0 nachlesbare Version in Details von der lokalen Kopie unterscheidet bzw. geringfügig ausführlicher ist als das, was in die lokale Kopie des Apache während der Installation integriert wurde.

Die Dokumentation für den älteren Zweig (Apache 1.3.x) besteht aus den gewohnten XHTML-Dokumenten. Für den jüngeren, aktuellen Zweig (Apache 2.x) ist ein interessantes neues Konzept gewählt worden, das auf bereichsübergreifendes Kapitel XML aufbaut. Es lohnt sich, auch die "Bauart" der Dokumentation selbst genauer anzuschauen, da sie eine Möglichkeit demonstriert, XML für die Präsentation von Webinhalten einzusetzen. In Abhängigkeit von den Umgebungsvariablen des Betriebssystems kann sie beispielsweise unter /usr/share/apache(2)/manual (SuSE) oder /usr/share/doc/apache-2.0.50/manual (Gentoo) zu finden sein.

Andere Informationsquellen[Bearbeiten]

Es gibt neben der Online-Dokumentation noch einige kleinere Dateien mit Informationsgehalt. Dazu zählt auch eine kleine Manualpage (nicht auf Windows), die sich mit man httpd aufrufen läßt. Sie enthält, nur wenig ausführlicher dargestellt, eine Übersicht der möglichen Befehlszeilenargumente, die sich auch durch den Aufruf von httpd -? darstellen lassen. Andere Textdateien enthalten die Lizenz, einige kleinere Installationshinweise, die üblichen README-Inhalte, es gibt eine Datei ABOUT_APACHE.txt und eine "quickstart"-Anleitung. Zu finden sind diese Dateien unter /usr/share/doc/packages/apache2 (SuSE) oder /usr/share/doc/apache (Debian). Auf einer Windows-Maschine liegen sie im Stammverzeichnis des Apache, also beispielsweise in D:\Apache.

Der Umgang mit den Modulen[Bearbeiten]

Vielleicht hängt die Konsequenz, mit der der Apache aus einzelnen Modulen zusammengesetzt wird, ja damit zusammen, dass er 1994/1995 ursprünglich aus einem Bündel einzelner Patches für den NCSA-Server entstand (zumindest sein Name ist dieser Entstehungsgeschichte zu verdanken). Durch das Konzept des modularen Aufbaus wird es einem Administrator freigestellt, die Funktionalität bzw. den zur Verfügung gestellten Leistungsumfang der Software selbst zu bestimmen. Diese Festlegungen erfolgen an zwei Stellen: einmal kann man während des Kompilierlaufs bereits darüber entscheiden, ob Softwarekomponenten als fest einkompilierte Module ihre Funktionsbereiche grundsätzlich zur Verfügung stellen sollen, und andererseits ist es möglich, in einer Konfigurationsdatei wie der httpd.conf festzulegen, ob man durch das Zuladen von Modulen zur Laufzeit der Software diese Funktionsbereiche temporär ansprechbar machen möchte.

Entsprechend ihrem Aufgabenbereich können die Module verschiedenen Gruppen zugeordnet werden. Das ergibt zwei große Gruppen: 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. Eine Besonderheit stellen die MPM dar, die es nur für Apache 2.0.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 Multiprozeß-System ist und für den Apache immer nur zwei Prozesse gestartet werden können - der eigentliche Server-Prozeß und ein "Child"-Prozeß. 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 (nur Apache 2.0.x) - läßt 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. In Apache 1.3.x für alle core-Anweisungen zuständig.
  • mod_so - erlaubt den Zugriff auf andere Module, die mit der LoadModule-Anweisung als DSO Verwendung finden sollen
   (+ MP-Modul ab Apache 2.0.x)

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_acces, das die Anweisung Order Allow,Deny konfiguriert oder mod_dir, mit dem ein DirectoryIndex erst ermöglicht wird.

In der Apache-Online-Dokumentation gibt es eine bereits übersetzte deutschsprachige Seite englischsprachige Seite Auflistung aller möglichen Module. Die Seite mit den Erläuterungen zu deutschsprachige Seite core ist ebenfalls in deutscher Sprache verfügbar und sollte bei auftretenden Fragen oder Unklarheiten immer konsultiert werden.

Die Liste der dynamisch verbundenen Module (DSO)[Bearbeiten]

Wenn man den Apache nicht selbst kompiliert, stehen nicht alle Module zur Verfügung, die zum Lieferumfang der Apache-Sourcen gehören. Normalerweise ist das kein Problem, da das, was die "default"-Liste enthält, vollauf genügen kann. Diese Liste ist anfangs relativ lang. Abhängig von Apache-Version, Betriebssystem und der Art, wie der Apache kompiliert wurde, unterscheidet sich die Anzahl der bereits eingetragenen Modulnamen. Einige sind deaktiviert (es steht die Raute vor dem Modulnamen).

Es ist nicht leicht, sich darüber Klarheit zu verschaffen, welches Modul nun tatsächlich für welche Aufgaben benötigt wird. Im Grunde genommen ist es reichlich ein Dutzend, das für die wichtigsten Funktionen, die der Server nahezu immer erfüllen muss, Verwendung findet: Modulname Einsatzgebiet mod_access stellt die Anweisungen "Order allow,deny" bereit, mit denen sich der Zugriff auf Verzeichnisinhalte regeln läßt mod_actions ist für die Ausführung von Scripts (CGI/Perl) zuständig - wird insbesondere auf Windows-Maschinen benötigt mod_alias läßt die Verwendung von Aliasnamen für Verzeichnisse außerhalb des DocumentRoot zu sowie den Einsatz von "ScriptAlias"-Namen beispielsweise für CGI-Scripts oder PHP mod_auth ist für die Benutzer-Authentication zuständig und liest Benutzer- und Gruppendaten ein mod_autoindex bestimmt das Aussehen von servergenerierten Verzeichnislisten mod_cgi macht den Einsatz von CGI-Scripts möglich mod_dir ermöglicht die Vergabe von Dateinamen, die als "DirectoryIndex" angesprochen werden sollen mod_include sorgt für die Ausführung von SSI mod_info stellt Informationen zur Serverkonfiguration bereit - insbesondere über die möglichen und realisierten modulspezifischen Anweisungen mod_log_config konfiguriert das Zugriffsprotokoll mod_mime verknüpft Dateinamen mit Dateiinhalten und Dateiverhalten (Sprache, Zeichensatz u.ä.) mod_mime_magic legt die MIME-Typen ansprechbarer Dateien fest, indem einige wenige bytes ausgewertet werden mod_negotiation ermöglicht das Aushandeln von Übertragungsbedingungen zwischen Server und anfragendem Client mod_setenvif kann Umgebungsvariablen setzen mod_status gibt Statusanzeigen über den laufenden Serverbetrieb aus

Eine Auflistung der einsetzbaren Module wird von der Online-Dokumentation bereitgestellt. Für den Anfang wird man aber kaum mehr als die oben genannten Module benötigen. Die Befehle, die von diesen Modulen bereitgestellt werden, genügen vollauf, um eine Testumgebung zu erstellen. Es gibt aber noch weitere Module, die an dieser Stelle der Online-Dokumentation nicht aufgeführt werden, da sie nicht oder noch nicht zum Lieferumfang des Apache gehören; Informationen dazu finden sich unter englischsprachige Seite http://modules.apache.org. Ein weiterer wichtiger Zusatz, der heute fast immer gebraucht wird, ist mod_php. Dazu gibt es später einige Hinweise.

Wie fängt man am besten an?[Bearbeiten]

Alles hängt davon ab, welche Aufgaben der Apache erfüllen soll. Unmittelbar nach seiner Installation ist noch keiner der weiter Partner ansprechbar, und im DocumentRoot liegen lediglich, falls das entsprechende Paket mitinstalliert wurde, ein paar vorformulierte Indexseiten, die in verschiedenen Sprachen das Standarddokument anbieten. Das genügt selbstverständlich nicht. Man kann es sich sehr leicht machen, indem rasch noch PERL und PHP aktiviert werden und das vorformulierte DocumentRoot unverändert übernommen und lediglich mit eigenen Webdokumenten aufgefüllt wird. Ein solcher "Weg des geringsten Widerstandes" wäre möglich, wenn man es eilig hat und den Apache lediglich benutzen, aber nicht wirklich verstehen lernen möchte.

Der schwierigere, letzten Endes aber erfolgversprechende Weg besteht darin, völlig von vorn anzufangen und nichts von dem, was bereits funktioniert, unverändert zu übernehmen. Das erreicht man am einfachsten, indem die vorformulierte httpd.conf erst einmal als "Backup" umbenannt, unter anderem Dateinamen abgespeichert (damit sie, falls irgendetwas völlig danebengeht, reaktiviert und der Ausgangszustand wiederhergestellt werden kann) und an ihrer Stelle eine neue, individuelle und vorerst völlig leere httpd.conf angelegt wird. Und diese neue httpd.conf gilt es dann, Schritt für Schritt mit den tatsächlich benötigten Einträgen zu füllen. Es ist nicht ratsam, Apache-Bestandteile wie Modul- oder Bibliotheksdateien zu verschieben oder an anderen Dateien des Softwarepakets herumzuexperimentieren. Wenn überhaupt, erfolgen solche Schritte ganz zuletzt, sobald die gewünschte Apache-Konfiguration einigermaßen "steht".

Wenn gar keine httpd.conf existiert, startet der Apache nicht. Es gibt eine Fehlermeldung, die unter Windows so aussieht:

Apache nicht konfiguriert

Auf einer Linux-Maschine steht eine vergleichbare Fehlermeldung im syslog. Ist dagegen eine Konfigurationsdatei vorhanden (einige Distributionen nennen sie apache2.conf statt httpd.conf), so startet der Webserver, was sich mit einer Kontrolle der laufenden Prozesse ermitteln läßt. Dafür gibt es beispielweise den Konsolenbefehl fuser -v /. Auf einer Windows-Maschine könnte die Konfigurationsdatei bis auf die Angabe eines ports völlig leer sein, Linux verlangt mindestens die Angabe eines Benutzers und die Zuweisung eines ports:

Apache nicht konfiguriert

dass der Apache tatsächlich gestartet ist, läßt sich mit fuser -v / bzw. mit dem Task-Manager prüfen. Allerdings bedeutet er in diesem "Embryonalzustand" lediglich eine Belastung des Arbeitsspeichers, da er ohne Konfiguration kaum in der Lage ist, Aufgaben zu erfüllen. Die Minimalanforderung für das, was ihm von der Konfigurationsdatei an Informationen übergeben werden muss, kann man der Windows-Fehlermeldung entnehmen: es wird die Angabe eines ports benötigt und ein DocumentRoot sollte (muss aber nicht zwingend) ebenfalls angegeben werden, damit der Apache weiß, aus welchem Verzeichnis er Anfragen bedienen soll. Linux-Installationen verlangen darüberhinaus die Angabe eines Benutzers. Windows braucht eine solche Angabe nicht. Die Meckerei wegen des fehlenden Servernamens kann man zunächst ignorieren. Eine minimale httpd.conf könnte also folgendermaßen aussehen:

Beispiel
# /etc/apache2/httpd.conf - minimal für SuSE Linux 9.1 User wwwrun Listen 80 DocumentRoot "/srv/www/htdocs" Oder auf einem Windows-Rechner: # D:\Apache\conf\httpd.conf - minimal für Windows XP Listen 80 DocumentRoot "D:/Apache/htdocs"

Übrigens, um das schnell noch zu sagen: "htdocs" bedeutet soviel wie "Hyper Text Documents".

Mit diesen drei bzw. zwei Einträgen kann der Apache bereits in einem lokalen Netz HTML-Dokumente aus dem angegebenen DocumentRoot allen eventuell anfragenden Browsern zur Verfügung stellen. Da kein Servername existiert, müsste die IP-Adresse in der Adreßzeile eines Browsers eingegeben werden, und weil es noch keine Festlegung für DirectoryIndex gibt, müsste auch der gewünschte Dateiname explizit angegeben werden, also beispielsweise http://192.168.0.2/index.htm. Das Standarddokument mit seiner bekannten Formel "Es klappt! ..." bekommt man mit dieser Minimalkonfiguration übrigens in Textform angezeigt, da der Apache noch keine MIME-Typen kennt. Der Internet Explorer zeigt sie allerdings an, weil er Text, der HTML-tags enthält, grundsätzlich als HTML behandelt.

Selbstverständlich ist ein solcher "Minimalzustand" völlig unzureichend und in seiner Wirkung sogar noch weniger befriedigend (und für das Betriebssystem auch belastender) als ein "default"-Zustand bei unverändert übernommener Konfigurationsdatei. Aber ausgehend von dieser Minimalkonfiguration kann man sich nun die vorhin glücklicherweise unter anderem Namen abgespeicherte "default"-Konfigurationsdatei einschließlich ihrer Kommentare wieder hervorkramen, zum Vergleich ansehen und Zeile für Zeile bzw. zurück Container für Container entscheiden, welche Anweisung und/oder welcher Container nun tatsächlich benötigt wird - und in welcher Form. Das ist ein längerer und etwas mühsamer Weg. Aber er bietet die Gewähr, dass bei eventuell auftretenden Fehlern sofort verständlich wird, woran es nun liegt und welche Zeile der Konfigurationsdatei wirklich überdacht und korrigiert werden muss.

Beginnen könnte man damit, erst einmal die Anweisungen aufzunehmen, die von core bereitgestellt und zwingend für den Serverbetrieb benötigt werden, dazu noch die Vorgaben für das Multiprocessing-Modul für das Feintuning. Das ergibt für einen Apache 2.0.x auf einer Linux-Maschine ungefähr folgende httpd.conf: httpd.conf-Zeile Standardwert Bedeutung ServerRoot "/srv/www" bezeichnet die Spitze des Verzeichnisbaums, unter dem die Server-Konfiguration, Fehleranzeigen und Protokolle gesucht werden, sofern dafür nicht ausdrücklich andere Pfade vorgegeben wurden PidFile /var/run/httpd.pid ist die Datei, in der der Server jedes Mal dann seine "process identification number" niederlegt, wenn er gestartet wird Timeout 300 bestimmt die Anzahl Sekunden, ehe eine Unterbrechung gesendet wird KeepAlive On legt fest, ob persistente Verbindungen (mehr als eine Anfrage pro Verbindung) zulässig sind MaxKeepAliveRequests 100 Höchstzahl der während einer persistenten Verbindung zulässigen Anfragen. Wird hier 0 angegeben, ist unbegrenzter Zugriff möglich KeepAliveTimeout 15 Zeitspanne (Zahl an Sekunden), um auf die nächste Abfrage desselben Clients mit derselben Verbindung zu warten StartServers 5 Anzahl der Server-Prozesse, die zu Beginn des Server-Betriebs gestartet werden MinSpareServers 5 Apache fragt periodisch ab, wieviele Serverprozesse gerade auf eine Rückmeldung warten. Wenn das weniger sind als in "MinSpareServers" vorgegeben, wird ein neuer erstellt. Sind das mehr als in "MaxSpareServers" vorgegeben, werden einige beendet (sie "sterben") MaxSpareServers 10 MaxClients 150 Höchstzahl der parallel laufenden Serverprzesse MaxRequestsPerChild 0 Höchstzahl an Anfragen, die jeder "Kind-Prozeß" behandeln darf, ehe er beendet wird Listen 80 Angabe des Standard-Ports User nobody Benutzername Group #-1 Gruppenzugehörigkeit des Apache-Benutzers ServerAdmin mail@adresse.de Anschrift des Server-Administrators ServerName servername.tld DNS-Name des Servers DefaultType text/plain Standard-MIME-Typ, den der Server einem Dokument zuweist, falls es nicht von einer Extension her genauer bestimmt wird TypesConfig /etc/apache2/mime.types liest die Liste der bekannten MIME-Typen ein ErrorLog /var/log/error_log Verzeichnis für Fehlerprotokolle LogLevel warn Art und Menge der Eintragungen, die in der Protokolldatei abgelegt werden sollen ServerTokens Full bestimmt, was der Server als Header-Information jeder HTTP-Anfrage mitgibt ServerSignature On In serverseitig generierte Dokumente kann eine Zeile eingefügt werden, die die Server-Version, den virtuellen Hostnamen und andere Hinweise enthält AddDefaultCharset ISO-8859-1 gibt eine Standard-Kodierung vor, die für alle ausgegebenen Seiten gilt DocumentRoot "/srv/www/htdocs" Verzeichnis, in dem die zur Publikation vorgesehenen Dokumente liegen

Für diese Einträge werden noch keine Zusatzmodule benötigt. Es sind die Bestandteile des "global environment" und einige Vorgaben aus der "main server configuration". Der Serverbetrieb könnte mit diesen Einstellungen bereits aufgenommen werden und zuverlässig funktionieren. Aber es gibt noch keinerlei Zugriffsbestimmungen, Scripts können noch nicht ausgeführt werden, es gibt gravierende Sicherheitslöcher und auch sonst noch allerhand Mängel. Die ursprünglichen Kommentare wurden völlig weggelassen, können aber nach Belieben neu gefaßt oder wieder hineinkopiert werden.

Eine einzelne oder mehrere Konfigurationsdateien?[Bearbeiten]

Die Konfigurationsdatei wirkt aufgrund ihrer Größe (woran auch die durchaus wertvollen Kommentare beteiligt sind) anfangs sehr unübersichtlich und auch ein wenig verwirrend. Die Frage, ob man sie nicht in mehrere kleinere Teile zerlegen könnte, die sich dann etwas leichter administrieren lassen, ist berechtigt. Schließlich gibt es die Möglichkeit, mit Include externe Dateien in die Konfigurationsdatei einzubinden (ein Beispiel dafür gibt es von Anfang an mit dem Aufruf von mime.magic). Zumindest eine Auftrennung entsprechend den drei Hauptabschnitten der httpd.conf (global environment, main server configuration, virtual hosts) bietet sich schließlich an.

Tatsächlich ist das eine sogar sehr gute Idee. Der Programmdatei httpd bzw. apache.exe ist es egal, wie ihr die benötigten Informationen bekanntgegeben werden, wichtig ist, dass sie diese Informationen erhält. So ist es beispielsweise möglich, dass die httpd.conf gar nichts anderes als einige Include-Anweisungen enthält und vielleicht ein paar erläuternde Kommentare - auf diese Art verfährt SuSE Linux 9.1 bereits seit Apache 2.0.48. Die "ausgelagerten" Anweisungen müssen nicht einmal unbedingt in Dateien mit dem Namen *.conf abgelegt werden, der Dateiname ist unwichtig. Als Konvention kann dennoch gelten, dass man beispielsweise die Konfiguration virtueller hosts in einer Datei virthost.conf zusammenfaßt. Darüber hinaus bietet es sich an, die Modulliste in eine Datei module.conf auszulagern sowie die relativ langen Listen, die zu mod_mime gehören, in eine mime.conf. Es macht Sinn, die Anweisungen in Dateien auszulagern, deren Dateinamen dem zugehörigen Modul entsprechen und in der httpd.conf selbst nur noch die core-Anweisungen stehenzulassen. Die Variationsmöglichkeiten sind nahezu unendlich. Wichtig ist lediglich, dass dem Administrator seine Arbeit tatsächlich erleichtert und nicht etwa die Übersicht erschwert wird.

Ein Beispiel für eine individuelle Konfiguration[Bearbeiten]

Da sonst in diesem Artikel immer die Linux-Varianten an erster Stelle stehen, soll es hier ausnahmsweise einmal mit einem Windows-Beispiel versucht werden. Es ist ja nur ein Beispiel. Zwar ist es, wie alle in diesem Artikel genannten Beispiele, ausgiebig auf Zuverlässigkeit und Nachvollziehbarkeit getetet worden, aber das nimmt ihm den Beispielcharakter nicht. Von einem Leser dieses Artikels wird erwartet, dass er den SELF-Gedanken kennt und so weit verinnerlicht hat, dass kein Beispiel ungeprüft übernommen oder gar per Copy&Paste ins eigene System übertragen werden darf. Beispiele dienen dazu, das zugrundeliegende Prinzip zu verdeutlichen, mehr können und sollen sie nicht leisten.

Es soll ein Apache 2.0.50 mit Hilfe des MSI-Installationspakets auf WindowsXP im Programmverzeichnis D:\Apache installiert und so konfiguriert werden, dass mit seiner Hilfe sowohl PHP-Scripts wie auch CGI-Scripts (PERL) ausgeführt werden können und es sollen auch SSI zulässig sein. .htaccess wird nicht benötigt und kein virtueller Host eingerichtet. Dann sieht die httpd.conf in Anlehnung an das oben dargestellte Linux-Beispiel erst einmal ungefähr so aus:

Beispiel
# httpd.conf für Apache 2.0.50 # Einsatzplattform Windows ServerRoot "D:/Apache" PidFile logs/httpd.pid Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 ThreadsPerChild 250 MaxRequestsPerChild 0 Listen 80 Include "D:/Apache/conf/module.conf" ServerAdmin mail@adresse.de ServerName Rechnername DefaultType text/plain ErrorLog logs/error.log LogLevel warn LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog logs/access.log common ServerTokens Full ServerSignature On AddDefaultCharset ISO-8859-1 DocumentRoot "D:/www/server1" <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory "D:/www/server1"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all AddOutputFilter INCLUDES .shtml .shtm </Directory> DirectoryIndex index.htm index.html index.shtml index.shtm index.cgi index.php ScriptAlias /cgi-bin/ "D:/www/server1/cgi-bin/" <Directory "I:/cgi-bin"> AllowOverride None Options Indexes FollowSymLinks ExecCGI Order allow,deny Allow from all </Directory> ScriptAlias /php/ "D:/php/" <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from 192.168 </Location> <Location /server-info> SetHandler server-info Order deny,allow Deny from all Allow from 192.168 </Location> Include "D:/Apache/conf/mime.conf" Include "D:/Apache/conf/autoindex.conf"

Erläuterungen zur Bedeutung bzw. Wirkung der einzelnen Anweisungen können im weiter übersetzten Beispiel einer "default"-Konfigurationsdatei nachgelesen werden, Hinzugekommen sind hier gegenüber dem oben angeführten Linux-Beispiel die Formatierung für das Zugriffsprotokoll, Zugriffsbestimmungen und Optionen für das DocumentRoot, ein DirectoryIndex, die ScriptAliase für PERL und PHP sowie zwei "Location"-Container, die vielleicht für den laufenden Serverbetrieb nicht zwingend benötigt werden, aber während der Konfigurationsarbeit nützliche Zusatzinformationen an den Browser liefern können. Für diese neuen Einträge sowie für einige weitere, noch nicht formulierte, wird die Modulliste benötigt, die in eine Datei module.conf ausgelagert werden soll. Wie weiter vorn bereits angesprochen, wird rund ein Dutzend Module benötigt.

Beispiel
# Include-Datei module.conf LoadModule access_module modules/mod_access.so LoadModule actions_module modules/mod_actions.so LoadModule autoindex_module modules/mod_autoindex.so LoadModule alias_module modules/mod_alias.so LoadModule cgi_module modules/mod_cgi.so LoadModule dir_module modules/mod_dir.so LoadModule include_module modules/mod_include.so LoadModule info_module modules/mod_info.so LoadModule log_config_module modules/mod_log_config.so LoadModule mime_module modules/mod_mime.so LoadModule negotiation_module modules/mod_negotiation.so LoadModule status_module modules/mod_status.so

Damit der Einsatz von Scripts und SSI möglich wird, müssen einige der von mod_mime bereitgestellten Anweisungen ausgeführt werden können, was beispielsweise von einer Datei mime.conf aus geschehen kann.

Beispiel
# Include-Datei mime.conf TypesConfig conf/mime.types MIMEMagicFile conf/magic DefaultLanguage de AddLanguage de .de AddCharset ISO-8859-1 .iso8859-1 .latin1 AddType text/html .shtml .shtm AddType application/x-httpd-php .php AddHandler cgi-script .cgi .pl .exe .bat Action application/x-httpd-php "/php/php.exe" AddOutputFilter INCLUDES .shtml .shtm

Und wenn nun schon mod_autoindex in der Modulliste enthalten ist, soll es auch noch eine autoindex.conf geben, damit Verzeichnisinhalte von Ordnern, in denen keine Index-Datei liegt, im anfragenden Browser dargestellt werden können.

Beispiel
# Include-Datei autoindex.conf IndexOptions FancyIndexing VersionSort AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* AddIconByType (SND,/icons/sound2.gif) audio/* AddIconByType (VID,/icons/movie.gif) video/* AddIcon /icons/binary.gif .bin .exe AddIcon /icons/binhex.gif .hqx AddIcon /icons/tar.gif .tar AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip AddIcon /icons/a.gif .ps .ai .eps AddIcon /icons/layout.gif .html .shtml .htm .pdf AddIcon /icons/text.gif .txt AddIcon /icons/c.gif .c AddIcon /icons/p.gif .pl .py AddIcon /icons/f.gif .for AddIcon /icons/dvi.gif .dvi AddIcon /icons/uuencoded.gif .uu AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl AddIcon /icons/tex.gif .tex AddIcon /icons/bomb.gif core AddIcon /icons/back.gif .. AddIcon /icons/hand.right.gif README AddIcon /icons/folder.gif ^^DIRECTORY^^ AddIcon /icons/blank.gif ^^BLANKICON^^ DefaultIcon /icons/unknown.gif ReadmeName README.htm HeaderName HEADER.htm IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

Das ist bereits alles. Ein derart konfigurierter lokaler Apache erfüllt alle Anforderungen, die in den meisten Fällen an eine einfache Testumgebung auf einem Windows-Rechner gestellt werden. Die ursprüngliche httpd.conf besteht jetzt aus vier kleineren Konfigurationsdateien, die deutlich übersichtlicher gehalten werden können als eine einzige sehr große Konfigurationsdatei. Sie enthalten in dieser Fassung auch keinerlei überflüssige Einträge, die vielleicht niemals während des Serverbetriebs in Anspruch genommen würden. Da im Verzeichnis D:\Apache\conf auch noch zum Vergleich eine Datei httpd.conf.default liegt, läßt sich jederzeit prüfen, ob nicht vielleicht doch noch der eine oder andere Eintrag oder ein weiteres Modul benötigt wird.

Und wenn man sie unbedingt braucht, können selbstverständlich beliebige individuelle Kommentare in diese httpd.conf aufgenommen werden ;-)

Quellen[Bearbeiten]

  1. http://httpd.apache.org/docs-2.0/platform/windows.html