Das Herzstück eines typischen Internet-Servers bildet ein Programm, das WWW-Seiten anbietet. Weltweit am häufigsten genutztes Exemplar dieser Gattung ist der Apache-Web-Server, dessen Entwickler kürzlich die Version 2 zur allgemeinen Verwendung freigaben.

Die Begriffe “Internet” und “World Wide Web” verwendet man heute im alltäglichen Sprachgebrauch fast gleichbedeutend. Das mag nicht korrekt sein, doch gehört das WWW unbestritten zu den meistgenutzten Diensten im Netz. Und der hat zwei Seiten: Mit einem Web-Client wie Netscape, Mozilla oder Konqueror wählt der User eine Seite an, wobei der Computer Kontakt zu dem Web-Server aufnimmt, der die entsprechende Ressource anbietet. Erst wenn jener Daten zurück schickt, kann der Client auch etwas anzeigen. Dieser Artikel zeigt, wie Sie auf Ihrem Computer Apache in der jüngst als stabil erklärten Version 2 als Web-Server installieren und konfigurieren.

Hinter den Kulissen des Webs

Im einfachsten Fall schickt ein Web-Browser eine Anfrage an Apache, und das Server-Programm antwortet mit einer HTML-Seite. Meist enthält diese mehrere Verweise auf weitere Objekte wie zum Beispiel Grafiken oder Frames, die ebenfalls vom Server ausgeliefert werden (vgl. Abbildung 1).

Abbildung 1: Datenaustausch über das Web

Doch wie genau sieht die Interaktion mit den Browsern aus? Wer darf auf welche Teile des Servers zugreifen? Wo sind diese Angebote auf den lokalen Festplatten gespeichert?

Werden Web-Inhalte – wie bei den meisten aktuellen Web-Seiten – in unterschiedlich großem Umfang dynamisch generiert, kommen weitere Problemkomplexe hinzu: In diesem Fall lädt Apache von der Festplatte nämlich nur eine Vorlage für die HTML-Seite bzw. ein kleines Stück Software, mit dessen Hilfe die eigentliche HTML-Seite entsteht. Die HTML-Erzeugung erfolgt durch separate Programme, die Apache entweder als Module oder als eigenständige CGI-Prozesse aufruft. Diese externen Programme sollten Sie in gewissem Maße bereits während der Apache-Installation berücksichtigen.

Apache installieren

Die neue Apache-Version 2 hat bislang einen Nachteil: Sie ist selbst in aktuellen Distributionen wie SuSE 8.0 Professional noch nicht enthalten. Eine gute Gelegenheit also, Apache selbstständig zu konfigurieren und zu übersetzen. Dadurch gewinnen Sie nebenbei einiges an Performance und möglicherweise sogar ein wenig zusätzliche Funktionalität, die Distributoren oft deaktivieren.

Die Software selbst erhalten Sie von der zugehörigen Web-Seite [3]. Sofern PGP bei Ihnen installiert ist, sollten Sie die Integrität des Pakets damit überprüfen (vgl. Kasten 1).

Den Quelltext entpacken Sie wie üblich und wechseln ins neuerzeugte Sourcen-Verzeichnis:

tar xzf httpd-2.0.35.tar.gz
cd httpd-2.0.35

Nun folgt der gewohnte Zyklus aus ./configure; make; make install. Allerdings empfehlen sich beim Aufruf des configure-Skripts, das Ihr System auf seine Eigenschaften und Fähigkeiten überprüft und die eigentliche Übersetzung vorbereitet, einige Anpassungen:

CFLAGS=-O2 LDFLAGS=-s ./configure --enable-rewrite=shared --enable-so --sysconfdir=/etc/httpd

Die Optionen vor ./configure setzen Umgebungsvariablen: CFLAGS und LDFLAGS geben Optionen für Compiler und Linker an. Dabei steht -O2 für eine Optimierung der Geschwindigkeit (zu Ungunsten der Programmgröße). -s weist den Linker an, Debugging-Informationen aus dem fertigen Programm herauszulöschen – wir gehen mal davon aus, dass Apache halbwegs ordentlich arbeitet.

Optionen, die mit --enable- beginnen, aktivieren einzelne Unterfunktionen. Beispielsweise schaltet --enable-rewrite das Modul mod_rewrite ein, mit dessen Hilfe Sie Besucher ganz unsichtbar innerhalb Ihrer Site umleiten können. --enable-so steht für die dynamisch nachladbaren Module, die wir später für Erweiterungen benötigen. Viele Linux-Anwender ergänzen noch die Option --sysconfdir=/etc/httpd: Konfigurationsdateien stehen dann im Verzeichnis /etc/httpd, während die Vorgabe von Apache /usr/local/apache2/conf heißt. Eine vollständige Liste aller Optionen für die Kompilierung erhalten Sie mit dem Befehl ./configure --help.

Mit dem Kommando make starten Sie anschließend die eigentliche Übersetzung, die ein paar Minuten beanspruchen kann.

Vor der Installation wechseln Sie mit su zum root-Account. make install schreibt die vorbereiteten Programm- und Datendateien (in der Voreinstellung) nach /usr/local/apache2. Die Bibliotheksdateien zu Apache landen dabei im Verzeichnis /usr/local/apache2/lib. Damit Ihr Linux diese auf Anhieb findet, ergänzen Sie das Verzeichnis – immer noch als root – am besten gleich in der Linker-Konfigurationsdatei /etc/ld.so.conf:

echo /usr/local/apache2/lib >>/etc/ld.so.conf
/sbin/ldconfig -v

Geben Sie die root-Rechte baldmöglichst (mit dem Kommando exit) wieder auf, um verhängnisvolle Fehler zu vermeiden.

Zusatzmodule vorbereiten

Apache lässt sich dynamisch durch nachladbare Zusatzmodule ergänzen. Vorteil: Wenn sich eines davon ändert, müssen Sie nicht jedesmal den gesamten Web-Server neu übersetzen.

tar xzf php-4.2.0RC4.tar.gz
cd php-4.2.0RC4
CFLAGS=-O2 CXXFLAGS=-O2 LDFLAGS=-s ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-safe-mode --with-mysql=/usr/local/mysql --prefix=/usr/local/apache2
make
su
make install
exit

Abbildung 2: Datenfluss mit PHP

Ein sehr weit verbreitetes Modul ist PHP, das Sie über [6,7] beziehen. Die Installation ähnelt – wie Listing 1 zeigt – stark der von Apache selbst. Allerdings stehen hier noch viel mehr Konfigurationsoptionen zur Verfügung. Beispielhaft benutzt Listing 1 diejenigen, die für die meisten Systeme interessant sein dürften:

• --with-apxs2 weist das PHP-Paket auf das Apache-Tool apxs hin, das die Erstellung dynamischer Module erleichtert. Diese Option sorgt für die Einbindung von PHP in den bereits übersetzten Apache.
• --enable-safe-mode hilft bei der Erstellung sicherer PHP-Skripte.
• --with-mysql bindet eine bereits installierte MySQL-Datenbank ein, auf die nun sehr einfach mit PHP-Befehlen zugegriffen werden kann. Wenn Sie (noch) nicht mit MySQL arbeiten, lassen Sie die Option einfach weg.
• --prefix sorgt dafür, dass die PHP-Dateien nicht einfach nach /usr/local geschrieben werden, sondern gemeinsam mit Apache in /usr/local/apache2 landen. PHP verwendet die Unterverzeichnisse include, lib/php und bin.

Eine vollständige Liste der zahlreichen --enable– und --with-Optionen erhalten Sie über den Befehl ./configure --help.

Konfiguration

Ein wesentlicher und wohl der verantwortungsvollste Teil der Arbeit steht uns jetzt bevor: Apache muss konfiguriert werden. Die entsprechenden Dateien befinden sich normalerweise in /usr/local/apache2/conf, bei einer Linux-Installation mit dem oben angegebenen --sysconfdir jedoch in /etc/httpd. Relevant ist die httpd.conf; die Fassung zu diesem Artikel erhalten Sie von [5] oder der Heft-CD.

httpd.conf enthält eine zunächst etwas verwirrend anmutende Vielfalt an Optionen. Zum Glück gilt: Bereits in der Konfigurationsdatei sind alle Möglichkeiten ausführlich erklärt (weitergehende Informationen gibt es unter [4]).

Wie bei vielen anderen Konfigurationsdateien auch lässt sich jede Zeile durch Voranstellen eines Hashes (“#“) auskommentieren und damit vorübergehend deaktivieren. Wenn man Direktiven durch Konstrukte wie <Directory> </Directory> umschließt, gelten die Zeilen zwischen dem Anfangs- und dem End-Tag nur für die im Tag angegebene Rahmenbedingung.

Globale Einstellungen

Eine Reihe Einstellungen gelten für das gesamte System:

ServerRoot "/usr/local/apache2"
DocumentRoot "/usr/local/apache2/htdocs"
TypesConfig /etc/httpd/mime.types
User nobody
Group #-1

ServerRoot legt das Wurzelverzeichnis der Apache-Installation fest; DocumentRoot das Verzeichnis, unterhalb dessen Ihre Web-Dokumente liegen. Die in TypesConfig angegebene Datei enthält eine Zuordnung zwischen Dateitypen und Dateinamenserweiterungen. User und Group stehen für die Zugriffsrechte, die laufende Apache-Prozesse in Anspruch nehmen dürfen: Apache muss zwar mit sehr weitreichenden Rechten gestartet werden (meistens als root), gibt diese während des Betriebs jedoch wieder auf, damit etwaige Eindringlinge nur begrenzten Schaden anrichten dürfen. Die Gruppe #-1 bezeichnet die Gruppe mit der zweithöchsten möglichen Gruppen-ID auf dem System.

ServerAdmin mymail@somewhere.org
ServerName selig.dyndns.org:80
Listen 80

Hinter ServerAdmin steht die E-Mail-Adresse des für den Web-Server Verantwortlichen. ServerName zeigt den offiziellen Domain-Namen des Servers – etwaige alternative Namen bestimmen Sie über die Direktive ServerAlias. Wenn Sie gar keinen offiziellen Namen für Ihren Server besitzen, lassen Sie ServerName einfach weg und können Apache dann zumindest lokal verwenden. Listen wiederholt den Port, auf dem Apache ankommende Verbindungen entgegennimmt.

LoadModule rewrite_module modules/mod_rewrite.so
LoadModule php4_module        modules/libphp4.so
AddType application/x-httpd-php .php

Dynamische Module werden durch das Kommando LoadModule eingebunden und aktiviert. Nach dem in diesem Artikel beschriebenen Übersetzungsvorgang stehen zumindest die beiden Module mod_rewrite.so und libphp4.so zur Verfügung. Für PHP benötigen wir zusätzlich eine Erklärung der Dateinamenserweiterung: Jetzt weiß Apache, dass alle Dateien mit .php durch das PHP-Modul interpretiert werden sollen.

Tuning

Zwischen Geschwindigkeit und Ressourcenverbrauch einen Kompromiss zu finden, ist nicht immer ganz einfach. Die Voreinstellungen von Apache gelten für eher mittelstark beanspruchte Systeme. Sehen wir uns die notwendigen Angaben ganz kurz an:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
Timeout 300

KeepAlive aktiviert ein wichtiges Feature der HTTP-Version 1.1 [1]: Nach Übertragung einer (HTML- oder Grafik-) Datei bleibt die Verbindung zwischen Browser und Web-Server zunächst noch offen. Wenn eine weitere Datei angefordert werden muss, weil beispielsweise eine Web-Seite viele Bilder enthält, entfällt der Aufwand für den erneuten Verbindungsaufbau, die Bilder können sehr schnell nachgeschoben werden.

Um Missbrauch zu verhindern und Fehler (vor allem bei älteren Web-Browsern) im Zaum zu halten, begrenzt MaxKeepAliveRequests die Zahl der Objekte, die über eine Verbindung geschickt werden dürfen. Gleichzeitig trennt Apache inaktive Verbindungen nach 15 Sekunden (KeepAliveTimeout). Für alle Verbindungen gilt ein Timeout von 300 Sekunden oder fünf Minuten: Braucht ein Browser länger für eine Reaktion, ist er vermutlich abgestürzt.

Apache 2 unterstützt sowohl das ältere Prozess-basierte Server-Modell (das entsprechende Modul heißt prefork.c) als auch das neuere Thread-basierte (Modul worker.c). Wenn Threads aktiv sind, also das entsprechende Modul beim Kompilieren von Apache aktiviert wurde, gelten die Angaben innerhalb von <IfModule worker.c> und </IfModule>:

<IfModule worker.c>
  StartServers         2
  ThreadsPerChild     25
  MinSpareThreads     25
  MaxSpareThreads     75
  MaxClients         150
  MaxRequestsPerChild  0
</IfModule>

Mit den darin verschachtelten Optionen hat es folgende Bewandtnis:

• Dank StartServers starten zu Beginn zwei zusätzliche Server-Prozesse. Insgesamt laufen dann drei Apache-Prozesse: Einer erledigt Verwaltungsaufgaben, die beiden anderen die eigentliche Arbeit. Davon enthält jeder 25 parallele Threads (ThreadsPerChild).
• Zu jedem beliebigen Zeitpunkt sollten mindestens 25 Threads unbeschäftigt sein (MinSpareThreads) und auf neue Anfragen warten. Wird diese Zahl unterschritten, startet Apache einen zusätzlichen Prozess mit weiteren 25 Threads.
• Damit umgekehrt keine unnötigen Ressourcen verschwendet werden, dürfen nicht mehr als 75 Threads arbeitslos sein (MaxSpareThreads). Ansonsten wird ein Prozess mit 25 Threads beendet.
• Gleichzeitig verwaltet der Server höchstens 150 Client-Verbindungen (MaxClients). Kommen mehr Anfragen aus dem Netz, weist er diese vorübergehend ab. Diese Einstellung hält den Server auch bei einem Angriff oder nach einer Erwähnung in Slashdot noch über Wasser.
• MaxRequestsPerChild kann einen periodischen Neustart der Server-Prozesse auslösen. So will man etwaige Programmierfehler umgehen. Hier glauben wir an die Programmierer und schalten das Feature mit einer Null aus.

Einstellungen für Verzeichnisse

Während wir uns bislang bei der Konfiguration um den Server an sich gekümmert haben, geht es jetzt um die Daten, die er der Welt zugänglich machen soll, zunächst um den Zugriff auf Daten-Verzeichnisse:

<Directory />
    AllowOverride None
    Options FollowSymLinks
    Order Deny,Allow
    Deny from all
</Directory>
<Directory "/usr/local/apache2/htdocs">
    AllowOverride None
    Options Indexes FollowSymLinks
    Order allow,deny
    Allow from all
</Directory>

Dabei werden jeweils drei Dinge festgelegt: Zunächst kümmern wir uns um das Änderungspotenzial lokaler Konfigurationsfiles, so genannter .htaccess-Dateien, innerhalb der Web-Verzeichnisse. Wieviel dürfen diese Extra-Dateien an der Konfiguration ändern (AllowOverride)? Hier sind wir sehr restriktiv.

Zweitens legen wir fest, welche Besonderheiten (Options) für das jeweils im Directory-Tag genannte Verzeichnis gelten. FollowSymLinks steht hier vor allem aus Geschwindigkeitsgründen: Normalerweise verhindert Apache den Zugriff auf Symlinks, die aus dem Web-Verzeichnis herauszeigen. Wenn Sie Ihre Web-Site ohne die Hilfe fremder Autoren einrichten, verzichten Sie auf den dafür nötigen Sicherheitscheck und freuen sich stattdessen über einen schnellen Server. Indexes ermöglicht die Anzeige eines Inhaltsverzeichnisses, wenn in einem Unterverzeichnis keine Datei index.html vorhanden ist. Interessant wäre eventuell noch IncludesNOEXEC für eine halbwegs sichere Version der Server Side Includes (SSI).

Als Drittes stellt sich die Frage, wer die Inhalte eines Verzeichnisses überhaupt sehen darf. Voreinstellung (für das Root-Verzeichnis <Directory />) ist dabei “niemand”! Wenn jemand (durch einen Trick oder ein ungeahntes Feature) aus dem eigentlichen Web-Bereich ausbricht und versucht, eine andere Datei unseres Computers zu erspähen, wird ihm das verweigert: Die Voreinstellung ist Deny from all. Nur ausgewählte Verzeichnisse schalten wir mit Allow from all frei.

ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/"
<Directory "/usr/local/apache2/cgi-bin">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all
</Directory>

Eine besondere Rolle spielt das mit dem Schlüsselwort ScriptAlias markierte Verzeichnis: Darin enthaltene Dateien werden nicht einfach übertragen, sondern als Programme ausgeführt. Im Unterschied zu PHP handelt es sich hier nicht um HTML-Code mit eingebetteten Anweisungen, sondern um echte Skripte oder kompilierte Programme. Sie werden aufgerufen und erzeugen dabei irgendeine Ausgabe, die Apache an den Browser übermittelt. Dieses Konzept heißt CGI (“Common Gateway Interface”).

Sicherheit

Wesentliche Punkte für ein sicheres System haben wir durch die Konfigurationseinstellungen bereits abgedeckt. Ein ganz wichtiger Punkt jedoch liegt außerhalb der Kontrolle von httpd.conf: die Zugriffsrechte von Systemseite aus.

Achten Sie darauf, dass der Apache-User (in unserem Beispiel heißt er nobody) keinerlei Schreibrechte in Ihrem System hat. Insbesondere darf Apache nicht seine eigene Konfigurationsdatei ändern oder die gespeicherten HTML-Dokumente umschreiben.

Warum diese Vorsichtsmaßnahme? Es könnte ja einmal passieren, dass sich ein Angreifer durch einen Fehler im Apache-Code Zugang zu Ihrem System verschafft. Das wollen wir zwar nicht hoffen, aber solche Fehler kann man nicht von vornherein ausschließen. In diesem Fall könnte der Hacker auf Ihrem System frei agieren – aber eben nur als Apache-User, im Beispiel als nobody.

Wenn nobody nun die HTML-Dateien verändern darf, kann der Eindringling Unsinn auf Ihre Web-Site schreiben, zum Beispiel Werbung für Microsoft oder einen Schmähbrief auf die Queen. Hat nobody gar ein Schreibrecht für die Apache-Konfigurationsdatei, sind dem Hacker Tür und Tor geöffnet: Er kann eigenständig eine Hintertür installieren und erlangt in kürzester Zeit einen vollwertigen Shell-Zugang zu Ihrem Computer.

Mein dringender Ratschlag lautet also, Konfigurations- und Datendateien dem Benutzer root zu geben. Sofern die HTML-Daten laufend geändert werden müssen, schaffen Sie dafür einen eigenen Benutzer, der mit Apache nichts zu tun hat.

Apache starten

Wenn Sie die Konfigurationsdatei zusammengestellt und nach /etc/httpd kopiert haben, wird es spannend: Rufen Sie Apache das erste Mal auf!

Apache enthält ein Skript namens apachectl, das die Kommunikation mit dem Server erleichtert. Es wird immer von root aufgerufen und erlaubt es beispielsweise, die grammatikalische Korrektheit Ihrer Konfigurationsdatei zu testen:

# /usr/local/apache2/bin/apachectl configtest
Syntax OK

Anschließend starten Sie den Server:

# /usr/local/apache2/bin/apachectl start
/usr/local/apache2/bin/apachectl start: httpd started

Wichtig: Aus Geschwindigkeitsgründen schreibt Apache Protokoll- und Fehlermeldungen nicht ins Syslog, wie das unter Linux sonst üblich ist. Stattdessen werden eigene Protokolldateien gepflegt, die unter /usr/local/apache2/logs oder an einer speziell konfigurierten anderen Stelle liegen.

Sollten Sie die Konfigurationsdatei zwischendurch einmal ändern, müssen Sie das Apache mitteilen. Konvention unter Unix ist, dass dies durch Übermitteln des Signals HUP (“Hangup“) erfolgt. Das funktioniert mit Apache zwar auch, ist aber etwas unpraktisch, weil dabei möglicherweise gerade bestehende Verbindungen zu Clients einfach abgebrochen werden. Freundlicher ist der so genannte graceful (“elegante”) Neustart: Dabei werden alle bestehenden Verbindungen mit der alten Konfiguration abgearbeitet. Um neue Verbindungen kümmert sich jedoch ein neugestarteter Prozess. Sobald die alten Prozesse arbeitslos werden, verschwinden sie.

Der systemunabhängige Befehl für diesen eleganten Neustart nach Konfigurationsänderungen sieht so aus:

# /usr/local/apache2/bin/apachectl graceful
/usr/local/apache2/bin/apachectl graceful: httpd gracefully restarted

Automatisch starten

Natürlich wollen Sie den Web-Server nicht nach jedem Reboot manuell aufrufen. Brauchen Sie auch gar nicht: Das beschriebene Programm apachectl erfüllt alle Anforderungen an ein Init-Skript. Integrieren Sie es als root durch einen Symlink einfach ins init.d-Verzeichnis:

cd /etc/init.d
ln -s /usr/local/apache2/bin/apachectl apache

Achten Sie darauf, dass init.d bei manchen Distributionen als /etc/rc.d/init.d anzusprechen ist. Nun wechseln Sie in die rc@L: *.d-Verzeichnisse der Runlevel, in denen Sie Apache nutzen wollen, und verlinken das Init-Skript (die Pfadangaben können wieder variieren):

cd /etc/init.d/rc2.d
ln -s ../init.d/apache S99apache

In rc0.d, rc1.d und rc6.d legen Sie zudem einen entsprechenden Link namens K01apache an, der Apache beim (Re-)Booten und Wechseln in den Wartungsmodus stoppt.

Ausblick

Das sah bislang alles nicht sonderlich komplex aus, doch das ist nur die halbe Wahrheit: Die Konfigurationsmöglichkeiten von Apache gehen bis hin zur freien Definition von Fehlermeldungen. Unterschiedliche Mechanismen ermöglichen die automatische Anpassung der ausgelieferten Inhalte an den Besucher, zum Beispiel die Präsentation von Web-Seiten in derjenigen Sprache, die im Browser gerade eingestellt ist. Nützlich ist auch die Möglichkeit, auf ein und derselben IP-Adresse mehrere Web-Sites mit unterschiedlichen Domain-Namen anzubieten.

Interessieren Sie diese oder andere Themen, lesen Sie im Web [3] weiter. Die vollständige Apache-Dokumentation finden Sie nach der beschriebenen Installation aber auch in /usr/local/apache2/manual.