Äußerst populär und daher bei fast allen Distributionen standardmäßig dabei – der Apache-Webserver ist ein Paradebeispiel für Open-Source-Software. Doch die Ernüchterung folgt auf den Fuß, denn seine Konfiguration wirkt auf den ersten Blick sehr umfangreich und dadurch kompliziert. Dieser Artikel gibt erste Hilfe.

Webserver stehen zumeist im Rechenzentrum; der Zugriff darauf erfolgt über das Internet. Wer sich jedoch in das Abenteuer namens “Der eigene Webserver” stürzen möchte, tut gut daran, sich zunächst auf dem eigenen Computer mit der Software vertraut zu machen.

Es gibt auch andere Gründe, auf dem eigenen Arbeitsplatzrechner einen HTTP-Daemon zu betreiben: Eigene Web-Projekte lassen sich so stressfrei erarbeiten und testen, und so manche nützliche Anwendung funktioniert nur, wenn ein Webserver im Hintergrund werkelt.

Wenn aber ein eigener Apache läuft, dann sollte man wissen, wie man ihn konfiguriert und wo die relevanten Dateien liegen. Schließlich will man nicht einfach so Dateien ins Web stellen und mit einem offenen Scheunentor böse Buben auf den eigenen Rechner locken, sondern auch wissen, was dann passiert und wer alles auf die Inhalte zugreift. Nicht zuletzt kann man anderen Usern über Passwort-geschützte Bereiche Zugriff auf wichtige Inhalte erlauben, ohne dass gleich der gesamte Datenbestand weltöffentlich wird.

Den Apache-Webserver gibt es in zwei Entwicklungsreihen: den älteren, aber weiterhin als “Stütze des Webs” fungierenden Apache 1.x (aktuellste Version: 1.3.30) sowie die modernere 2.x-er Reihe [1] (zu Redaktionsschluss bei 2.0.49 angelangt). Teilweise liefern selbst aktuelle Distributionen noch ältere Ausgaben mit. Für Einsteiger ist es jedoch unerheblich, welche Entwicklungsreihe installiert ist; in den wichtigsten Konfigurationspunkten unterscheiden sie sich nämlich nicht.

Was läuft?

Ob direkt bei der Installation eines Linux-Systems oder nachträglich – ist die Entscheidung für den Webserver gefallen, nimmt man am besten das Installationstool der jeweiligen Distribution her, um die gewünschten Apache-Pakete auszuwählen und einzuspielen. Je nach Distribution gehören zum Basis-Paket zusätzlich PHP oder eine Reihe Perl-Module, die man nach Belieben (und abhängig vom Einsatzzweck des Servers) installieren kann.

Einmal ins System eingespielt, vergewissert man sich, dass der Server läuft. Mit der Standard-Konfiguration sollte er sich ohne Probleme starten lassen. So zeigt

ps waux | grep httpd

an, wieviele Instanzen des Webservers laufen. Beim Apache heißt der Webserver-Dämon httpd und arbeitet im Hintergrund. Er ist es, der beim Starten des Webservers als erster Prozess angestoßen wird. Erst später kommen je nach Konfiguration (und je nach der Anzahl der Zugriffe auf den Server) weitere httpds als Kind-Prozesse hinzu. Daher kann es sein, dass ps jede Menge httpd-Einträge anzeigt. Sieht man keinen einzigen, dann läuft auch kein Webserver.

Wenn der Distributor den Server nicht bereits nach der Installation aktiviert, gibt es zwei Möglichkeiten, den Apachen zu starten – und natürlich auch zu stoppen. Einmal findet sich bei guten Distributionen im Verzeichnis /etc/init.d/ ein Start-Stopp-Skript, zum anderen gehört das Tool apachectl, das etwas mehr Optionen anbietet, zum Lieferumfang.

Ersteres startet den Server nach dem Booten mit dem Befehl

/etc/init.d/apache start

und beendet ihn beim Herunterfahren des Rechners mit

/etc/init.d/apache stop

Wer es von Hand auf der Kommandozeile aufruft, kann ihm statt start oder stop auch die Argumente restart bzw. reload mit auf den Weg geben. Der Unterschied zwischen diesen beiden besteht darin, dass beim Reload nur die Konfigurationsdatei neu eingelesen wird, während Restart einen bereits laufenden Apachen zuerst runterfährt, um ihn danach wieder zu starten. Läuft bislang kein Server, wirkt restart wie start.

Mit den Argumenten start, stop und restart kennt apachectl ähnliche Optionen wie das Start-Stopp-Skript. Zum Neuladen der Konfiguration kommt jedoch der Befehl

apachectl graceful

zum Einsatz. Bekommt der Systemverwalter dabei die Antwort command not found, gibt man den Pfad zum Programm mit an:

/usr/sbin/apachectl configtest

Die Option configtest macht nichts weiter, als die Konfiguration zu testen, aber das ist sehr hilfreich.

Wo liegt das alles?

Klappt das Starten und Stoppen, macht man sich auf die Suche nach der Konfiguration. Dabei wird man oft das Gefühl nicht los, die wichtigen Dateien und Verzeichnisse seien überall auf der Festplatte verstreut, aber nie da, wo man sie vermutet. Dies hat zum einen historische Gründen, zum anderen liegt es aber auch daran, dass sich die Experten über die passenden Plätze streiten.

Bei Suse 9.0 beispielsweise findet man die Konfigurationsdateien in /etc/httpd/ und die Daten-Verzeichnisse der Webpräsenz unter /srv/www/, während der httpd im Verzeichnis /usr/sbin/ liegt. Andere Distributionen sammeln die Web-Verzeichnisse unter /usr/local/apache oder /usr/local/httpd; teilweise liegen dort auch Konfigurationsdateien oder Programme.

Leider ist es wichtig zu wissen, wo sich die Konfigurationsdateien befinden und wo die Web-Verzeichnisse untergebracht sind, weshalb der Anwender um eine kleine Suchaktion nicht herumkommt. Glücklich sind die, denen ps waux | grep httpd etwas in der Art von httpd -f /etc/httpd/httpd.conf anzeigt: Sie können sich die weitere Suche sparen und wissen nun, dass die Konfigurationsdateien unter /etc/httpd/ zu finden sind. Alle anderen (und alle, die es genauer wissen wollen) schauen sich die Ausgabe des Befehls httpd -V einmal genauer an (Listing 1).

rechner:~ # httpd -V
Server version: Apache/1.3.28 (Linux/SuSE)
Server built:   Oct 29 2003 19:51:11
Server's Module Magic Number: 19990320:15
Server compiled with….
 -D EAPI
 -D EAPI_MM
 -D EAPI_MM_CORE_PATH="/var/lib/httpd/mm"
 -D HAVE_MMAP
 -D HAVE_SHMGET
 -D USE_SHMGET_SCOREBOARD
 -D USE_MMAP_FILES
 -D HAVE_FCNTL_SERIALIZED_ACCEPT
 -D HAVE_SYSVSEM_SERIALIZED_ACCEPT
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D DYNAMIC_MODULE_LIMIT=128
 -D HARD_SERVER_LIMIT=2048
 -D HTTPD_ROOT="/srv/www"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/run/httpd.pid"
 -D DEFAULT_SCOREBOARD="/var/run/httpd.scoreboard"
 -D DEFAULT_LOCKFILE="/var/run/httpd.lock"
 -D DEFAULT_ERRORLOG="/var/log/httpd/error_log"
 -D TYPES_CONFIG_FILE="/etc/httpd/mime.types"
 -D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"
 -D ACCESS_CONFIG_FILE="/etc/httpd/access.conf"
 -D RESOURCE_CONFIG_FILE="/etc/httpd/srm.conf"
rechner:~ #

Damit erfahren sie neben der Versionsnummer (1.3.28) und der verwendeten Distribution (Suse) eine Menge darüber, in welchen Verzeichnissen der Server welche Daten vermutet und mit welchen speziellen Optionen das Programm übersetzt wurde. Für uns sind vor allem die Zeilen ab -D HTTPD_ROOT von Interesse. Als “Server Root” bezeichnet man das Oberverzeichnis für die Webserver-Dateien, für die kein anderer Pfad spezifiziert wurde, im Beispiel unter /srv/www/. Die Prozess-Identifikationsnummer (PID) des laufenden Servers lässt sich der Datei /var/run/httpd.pid entnehmen. Fehlermeldungen landen in /var/log/httpd/error_log, und sämtliche Konfigurationsdateien liegen unter /etc/httpd/. Alle anderen Merkmale können wir ignorieren.

Zwei davon sind die Konfigurationsdateien in ACCESS_CONFIG_FILE und RESOURCE_CONFIG_FILE. Damit hat es folgendes auf sich: Vor Jahren verabschiedeten sich die Apache-Entwickler von den bis dato verwendeten Dateien access.conf und srm.conf; stattdessen landete die gesamte Konfiguration in der Datei httpd.conf, vor allem aus Gründen der Übersichtlichkeit. Mittlerweile entpuppt sich httpd.conf jedoch als so vollgestopft mit Konfigurationspunkten, dass einige Distributionen Teile der Konfiguration wieder in eigene Dateien auslagern und dann mittels eines sogenannten Include wieder einbinden. Für einfache Webserver reicht es aber in jedem Fall, lediglich httpd.conf zu betrachten.

Abbildung 1: Sobald der Apache läuft, kann man mit dem Browser zumindest die Default-Startseite abrufen.

Alles eine Sache der Grundeinstellung

Normalerweise läuft so ein Webserver mit der vom Distributor eingestellten Standard-Konfiguration, und beim Aufruf der URL http://127.0.0.1/ oder http://localhost/ erscheint eine Startseite wie in Abbildung 1. Dann bewaffnet man sich mit einem Editor und nimmt sich die Datei httpd.conf vor. Darin gibt es viele Einstellungen, von denen man lieber die Finger lässt, weil sie Interna des Webservers festlegen. Dies betrifft beispielsweise die Reihenfolge beim Laden der Module. Wer hier einen Fehler macht, nimmt u. U. in Kauf, dass anschließend gar nichts mehr funktioniert. Ein wenig Wissen um das Was und Wie der einzelnen Einstellungen schadet also nicht.

Zuerst kommen die, die das sogenannte Global Environment betreffen, die allgemeine Server-Konfiguration. Dort findet sich der Punkt

ServerType standalone

den man unbedingt so lassen sollte, damit der Apache direkt auf Port 80 nach einkommenden Anfragen lauscht. Mit

ServerRoot "/srv/www"

definiert die bereits erwähnte Server Root.

Damit nicht für jede Anfrage eine komplett neue Verbindung mit dem Webbrowser aufgebaut wird, sollte man folgende Einstellung unbedingt ausprobieren:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

Beim KeepAlive bearbeitet der Server mehrere Abfragen eines Browsers in einer “Session”, im Beispiel maximal 100 Stück. Dabei wartet er nach einer Anfrage maximal 15 Sekunden auf Folgeanfragen. KeepAlive funktioniert allerdings nur, sofern das Browser-Gegenüber mitspielt (die meisten modernen Programme tun es).

Für den Hausgebrauch reicht es locker aus, wenn ein Server gestartet und auch nur ein zusätzlicher (englisch: “spare”) Webserver-Prozess vorgehalten wird, falls weitere Anfragen kommen:

MinSpareServers 1
MaxSpareServers 1
StartServers 1
MaxClients 150
MaxRequestsPerChild 0

Die Obergrenze für gleichzeitige Anfragen liegt bei 150, was für die meisten kleineren Webpräsenzen ausreicht. MaxRequestsPerChild 0 bewirkt, dass ein Webserver-Prozess dauerhaft läuft und nicht nach einer bestimmten Anzahl Anfragen durch einen neuen Prozess ersetzt wird. Wenn man sieht, dass ein httpd-Prozess mehr und mehr Speicher frisst, geht man hier etwas konservativer vor. Das kommt aber eher selten vor.

IP-Adresse und Servername

Spannender wird es bei den Optionen

#Listen 127.0.0.1:80
BindAddress *

Sie legen fest, welche IP-Adresse der Webserver benutzen soll. BindAddress * ist sehr großzügig und weist den Apache an, auf jede Anfrage, die den Rechner erreicht, zu antworten. Alternativ trägt man BindAddress 192.168.1.2 ein, wobei für 192.168.1.2 die tatsächliche IP-Adresse des Rechners zu ersetzen ist.

Besseres Finetuning ermöglicht die Listen-Anweisung: Davon kann man so viele untereinander hinschreiben, wie man braucht, jeweils mit einem Argument der Form IP-Adresse:Port. Allerdings muss man sich entweder für BindAddress oder Listen entscheiden: Das # am Anfang der Listen-Zeile sorgt im Beispiel dafür, dass sie der Apache nicht beachtet.

Die anschließend folgenden Einstellungen bis zur httpd.conf-Zeile Section 2: 'Main' server configuration sollte man unbedingt so lassen, wie sie sind. Interessant wird es wieder beim Eintrag Port 80. Er besagt, dass der Apache – so wie die allermeisten Webserver im Internet – auf Port 80 lauscht. Für Testserver etc. nimmt man als Alternative z. B. Port 8080 – muss dies nach dem Muster http://server:8080/ dann aber immer auch im Browser angeben. Soll ein Webserver auf einem nicht-standardisierten Port von außen zugänglich sein, achte man darauf, ggf. die Firewall auf dem neuen Port zu öffnen.

Damit ein Fehler im Apache nicht gleich dafür sorgt, dass ein Angreifer root-Rechte bekommt, sollte der Server als spezieller Benutzer (z. B. wwwrun) laufen. Dies legt User wwwrun fest; Group nogroup bestimmt, mit den Rechten welcher Nutzergruppe er zum Beispiel auf Dateien zugreift.

Die Mail-Adresse, die der Nutzer bei Fehlermeldungen als Ansprechpartner erhält, legt man hinter dem Stichwort ServerAdmin fest:

ServerAdmin webmaster@www.domain.de

Auf die Adresse des Verantwortlichen folgt der Name des Servers:

ServerName www.domain.de

Hier gehört der “Fully Qualified Domain Name” (FQDN) hin, also Rechnername mitsamt des Domainnamens, unter dem der Server im Netz zu finden ist. Diese Option kann man weglassen, vor allem, wenn man nur im eigenen Netzwerk testen will.

Die wichtige Frage, in welchem Verzeichnis auf dem Rechner die Dateien stecken, die man sich später über den Webserver anzeigen lassen will, beantwortet

DocumentRoot "/srv/www/"

Hier liegen (zumindest, solange man bei der Konfiguration nicht trickst) die Dateien und Verzeichnisse, die man im Browser zu sehen bekommt, wenn man http://servername/, gefolgt von einem einfachen Dateinamen aufruft: /srv/www/test.html ließe sich über http://localhost/test.html ansprechen, richtig vergebene Leserechte vorausgesetzt.

Damit ist die Grundeinstellung des Servers komplett. Alle weiteren Optionen haben etwas damit zu tun, wie der Webserver mit Anfragen umgehen soll. So legt

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

für das oberste Verzeichnis / in der DocumentRoot (im Beispiel also für /srv/www/) fest, dass symbolische Links auch vom Webserver genutzt werden dürfen (FollowSymLinks). Zudem erlaubt es die Einstellung None für AllowOverride nicht, dass Dateien namens .htaccess innerhalb der Web-Datenverzeichnisse Zugangseinstellungen aus der httpd.conf überschreiben: Es ist besser, erst einmal restriktiv anzufangen und später nach und nach mehr zuzulassen. In der Grundkonfiguration werden alle Dateien eines Verzeichnisses wie in Abbildung 2 angezeigt.

Abbildung 2: So zeigt der Browser ein Verzeichnis unterhalb der Document Root des Servers an.

Jeder kennt URLs der Art http://servername.de/~username/. Die Anweisung UserDir legt fest, wo im Homeverzeichnis des Benutzers sein Webverzeichnis liegt. Im Falle von UserDir public_html wäre dies /home/username/public_html. Das Verzeichnis sollte mit chmod 755 für den Zugriff des Webservers vorbereitet werden, alle dort liegenden Dateien erreicht der Webserver nach chmod 644 dateiname ebenfalls.

Alles geloggt

Spätestens, wenn Fehler und Unregelmäßigkeiten auftreten, beweist sich der Wert guter Server-Protokolle. Auch sie lassen sich konfigurieren. So stellt man mit

HostnameLookups Off

das Auflösen von IP-Adressen in Rechner- und Domainnamen aus, da dies im Betrieb nur Ressourcen frisst. Der Nachteil: Damit vermerkt das Logfile die Zugriffe nur als IP-Adresse. Aber jedes bessere Logfile-Analyse-Tool (siehe Seite 68) übernimmt die entsprechende Namensauflösung.

ErrorLog "/var/log/httpd/error.log"
LogLevel warn

legt fest, in welcher Datei (hier: /var/log/httpd/error.log) die Fehler bei Zugriffen protokolliert werden. Mit dem LogLevel stellt man ein, wieviel geloggt werden soll: warn reicht völlig aus. Wer richtig viele Infos haben will, wenn etwas schiefgeht, kann gerne debug ausprobieren, sollte sich aber nicht wundern, wenn dann zu viele Informationen im Logfile stehen.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Mit den LogFormat-Anweisungen (Listing 1) legt man das Format der Logfiles fest: An die Stelle von %h schreibt der Server den zugreifenden Rechner (“Host”), die Platzhalter %l und %u ersetzt er durch zwei verschiedene Formen von Usernamen, soweit diese übermittelt werden. %t zeigt Datum und Uhrzeit an, %r notiert den Request, also das, was der Browser vom Webserver an Daten erhalten wollte, und %>s zeigt den Status der letzten Abfrage innerhalb der Session an.

%b gibt die Anzahl der gesendeten Bytes an. %{Referer}i wertet aus, wo der Zugriff herkommt, und %{User-agent}i zeigt an, um welchen Browser es sich handelte. Der letzte Eintrag in der Zeile gibt den Typ des Logfiles an, in dem die jeweiligen Daten landen. Dessen Platz im Dateisystem definiert der Eintrag CustomLog: So erzeugt

CustomLog "/var/log/httpd/access_log" common

ein Logfile namens access_log im Common Log Format (CLF), das Zeile 2 in Listing 2 definiert. Es reicht für die meisten Anwendungen aus; ein Eintrag im Logfile sieht dann folgendermaßen aus:

127.0.0.1 - - [22/Mar/2004:00:42:01 +0100] "GET / HTTP/1.1" 200 1456

Wer mehr wissen will, nutzt das ebenfalls in Listing 2 beschriebene Format combined anstelle von common. Es ist auch möglich, für eine Datei mehr als ein Format gleichzeitig anzugeben, beispielsweise wenn man die Referer oder Browsertypen einzeln auswerten will.

Passwort-Schutz

Beim derzeitigen Stand der Konfiguration hat jeder Zugriff auf alle Daten im Webverzeichnis, und nicht immer ist dies gewünscht. Um Unterverzeichnissen einen einfachen Passwort-Schutz zu geben, legt man eine Datei an, in der zusätzlich zum Usernamen das verschlüsselte Passwort enthalten ist. In der httpd.conf muss dann nur noch stehen, welche User Zugriffsrechte bekommen.

Die Datei mit den Zugriffsdaten erzeugt der Befehl

htpasswd -c /etc/httpd/htusers username1

htpasswd ähnelt dem Befehl passwd und legt die Kombination Username:verschlüsseltes Passwort an, nachdem man das Passwort einmal eingetippt und dann zur Sicherheit noch einmal bestätigt hat. Mit der Option -c /Pfad/Datei erzeugt er die Passwort-Datei (im Beispiel /etc/httpd/htusers), die der Webserver später ausliest.

Daher muss der Server auf die Datei auch zugreifen können. Allerdings empfiehlt es sich nicht, die Passwort-Datei im Webverzeichnis abzulegen, hier macht man es potentiellen Angreifern zu einfach.

Einen weiteren User fügt htpasswd /Pfad/Datei username2 hinzu, das Ändern bestehender Passwörter ist mit dieser Syntax ebenfalls möglich.

Damit der Webserver von der Passwortdatei erfährt, bekommt httpd.conf eine Erweiterung wie in Listing 3. Man kann sie ans Dateiende packen oder aber zu den anderen <Directory>-Anweisungen.

<Directory /srv/www/privat>
AuthType Basic
AuthName "Kein Zutritt"
AuthUserFile /etc/httpd/htusers
Require user username1
</Directory>

Sie legt fest, dass für den Zugriff auf das Verzeichnis /srv/www/privat (per Webbrowser über http://server/privat/ zu erreichen) die einfache Authentifizierung (AuthType Basic) genutzt werden soll, und zwar für alle Verzeichnisse unterhalb von /srv/www/privat.

Abbildung 3: So ähnlich sieht die in Listing 3 definierte Passwort-Abfrage für den geschützen Bereich im Browser aus.

Im Browser erscheint dann ein Fenster mit der Passwort-Abfrage (Abbildung 3); der Server überprüft, ob die Datei /etc/httpd/htusers die eingegebene Username-Passwort-Kombination enthält. Dank des Eintrags Require user username1 werden alle anderen Zugriffe geblockt.

Mehr Optionen gefällig?

Wer jetzt Interesse an der Konfiguration des Apache gefunden hat, kann aufatmen: Der Server bietet noch eine Menge weiterer Möglichkeiten, zum Beispiel die VirtualHost-Anweisung zur Konfiguration mehrerer Webpräsenzen auf einem Rechner. Zum Glück kann die mitinstallierte Dokumentation viele Fragen klären und bietet vor allem Detail-Informationen zu den einzelnen Optionen an.