Der wohl häufigste Einsatz für Linux-Rechner ist der Betrieb als Webserver. Mit einem Marktanteil von deutlich über 60 Prozent laut der regelmäßigen Messungen von NetCraft steht dabei Apache am höchsten in der Gunst der Anwender. Allerdings arbeiten viele Systeme noch mit Apache 1.3.x - und das, obwohl die Nachfolgeversion 2.0 mittlerweile schon längst ausgereift ist und stabil läuft. Dabei hat gerade die zweite Apache-Generation einige Neuerungen, Annehmlichkeiten und Vorteile zu bieten.
Bessere Performance, geringerer Speicherbedarf und neue Module mit zusätzlichen Funktionen sind gute Argumente, entweder den Umstieg zu wagen oder beim Sprung in das Webmaster-Dasein gleich auf diese Version zu setzen. Zwingend notwendig ist dies sogar für all jene, die schon jetzt oder in Kürze mit IPv6 arbeiten.
Apache 2.x im Überblick
Im allgemeinen Sprachgebrauch ist Apache gleich bedeutend mit dem Webserver, also der Software, die für das Ausliefern von Web-Inhalten an den Browser eines Anwenders zuständig ist. Wie so oft, ist das eine drastisch vereinfachte Darstellung. Schon die Geschichte des Namens - Apache ist eine Ulkform von "a patchy server", also eines Flickwerks - ist Apache eher ein Rahmenwerk, das seine Fähigkeiten erst durch zusätzliche Module erhält.
Diese Erweiterungen nämlich sind es, die eine vom Internet-Surfer kommende Anfrage entgegennehmen, analysieren, benötigte Informationen von der Festplatte oder aus Datenbanken holen und sogar Interpreter für Programmiersprachen aufrufen, um schlussendlich die auf teils verzwickten Wegen entstandene Ausgabe an den User zurückzuliefern.
Gerade mit diesen Modulen gab und gibt es unter Apache 1.3.x immer wieder Probleme. Bei diesem entscheidet die Ladereihenfolge der Erweiterungen darüber, auf welchem Weg eine Anfrage die Modulkette durchläuft. So kann es unachtsamen Webmastern schon einmal passieren, dass das Modul zum Komprimieren der Ausgabedaten vor dem Aufruf des PHP-Interpreters in der Konfigurationsdatei steht. Dieser kann nun aber mit den gepackten Informationen schlicht nichts mehr anfangen - Haareraufen und stundelange Fehlersuche sind oft die Folge.
Es verwundert daher nicht, dass sich bei der jüngsten Apache-Generation vor allem im Bereich der Module einiges getan hat. So legt der Server nun intern fest, in welcher Reihenfolge die Module eine eingehende Anfrage sowie die ausgehenden Datenströme bearbeiten. Darüber hinaus haben einige Erweiterungen Einzug gehalten, die sich unter Apache 1.3.x nur mit Hilfe externer Programme oder schlichtweg gar nicht realisieren lassen.
Die wichtigsten Neuerungen in Apache 2.x sind sicher die direkte Unterstützung von Secure Socket Layers (SSL), der Support für Distributed Authoring and Versioning (DAV), Kompression der übertragenen Inhalte sowie integriertes Caching im Speicher oder auf der Festplatte. Dazu kommt, dass für die unterstützten Betriebssysteme spezielle Multithreading-Versionen des Servers erzeugt werden können, die sich durch geringeren Speicherbedarf bei gleichzeitig höherer Performance auszeichnen.
Installation / Upgrade
Ob es um die Erstinstallation des Apache-Servers oder um ein Upgrade einer Version aus der 1.3.x-Serie geht: Die zunächst beste Vorgehensweise ist die Installation der RPM-Archive des Anbieters der jeweiligen Installation. Unter SuSE-Linux 9.0 geht das einfach über die Auswahl "Einfacher Webserver mit Apache2". Ein eventuell bereits vorhandener Apache 1.3.x muss dabei nicht entfernt werden. SuSE hat die Installation so gelöst, dass beide Server parallel zueinander auf dem Rechner vorhanden sein können. Für ein Upgrade hat das unschätzbare Vorteile, wie sich schnell zeigt.
Auch wenn damit nicht der nominell neueste Apache-Server eingerichtet wird: Ein Online-Update behebt auch diesen Schönheitsfehler.
Die Konfigurationsdateien für Apache 2.x finden sich bei SuSE im Verzeichnis /etc/apache2. Im Falle eines Upgrades ist es ratsam, die dort abgelegten Standardvorgaben erst einmal zu sichern, bevor man daran geht, die alten Einstellungen wieder einzupflegen. Das ist mit wenigen Befehlen auf der Kommandozeile erledigt:
su -
cp -rp /etc/apache2/ /etc/apache2.bak
Tücken beim Update
Die größte Hürde für Umsteiger ist nun, dass SuSE mit dem Apache 2.x ein neues System zum Verwalten der Konfiguration eingeführt hat. An die Stelle der monolithischen Datei httpd.conf, die alle Konfigurationsparameter enthält, tritt dabei eine modulare Version derselben Datei. Diese ist nun eher der zentrale Verwalter mehrerer weiterer Konfigurationsdateien, die ja nach Bedarf per Include-Anweisung eingebunden werden.
Dazu kommt, dass Apache 2.x einige Kommandos nicht mehr kennt, die unter Version 1.3.x durchaus üblich waren. Außerdem finden sich einige Module unter neuem Namen, und da sich die Modulschnittstelle geändert hat, laufen alte Module sowieso nicht unter der neuen Apache-Generation. Um das Anpassen der existierenden Konfigurationsdatei kommt man also nicht herum. Eine große Hilfe ist dabei der Stream-Editor sed. Er erleichtert nicht nur das Anpassen der Pfade, sondern kann im selben Durchgang die nicht mehr benötigten Befehle entfernen, wodurch Sie sich viel Tipparbeit sparen. Da vor allem die Eingabe der Befehle für sed fehleranfällig ist, empfiehlt es sich, die einzelnen Schritte in einem Shell-Script zusammenzufassen:
#!/bin/bash
# apache_convert.sh
# Shell-Script zur Konvertierung der httpd.conf
# von Apache 1.3.x in ein unter Apache 2.x
#!/bin/bash
cd /etc/apache2
cp ../httpd/httpd.conf .
sed -e '/^[ \\t]*LoadModule.*/d' \\
-e '/^[ \\t]*AddModule.*/d' \\
-e '/^[ \\t]*PidFile.*/d' \\
-e 's%/httpd/%/apache2/%g' \\
-e 's%#NameVirtualHost \\*:80%#NameVirtualHost \\*%g' \\
-e 's%/suse_loadmodule.conf%/sysconfig\\.d/loadmodule.conf%g' \\
-e 's%/suse_include.conf%/sysconfig\\.d/include.conf\\nInclude /etc/apache2/vhosts\\.d/*.conf%g' \\
-e '/^[ /t]*ServerType.*/d' \\
-e '/^[ \\t]*ClearModuleList.*/d' \\
-e '/^.*suse_addmodule.*/d' \\
-e 's/^[ \\t]*Port\\(.*\\)/Listen\\1/g' \\
-e '/^[ \\t]*SSLLog.*/d' \\
-e 's/^[ \\t]*ServerName.*/Include \\/etc\\/apache2\\/sysconfig\\.d\\/global.conf/g' \\
httpd.conf > httpd.conf.tmp
sed -e ':t /<IfDefine STATUS/,/if Define>/{/<\/IfDefine>/!{$!{N; bt}}; s/<IfDefine STATUS.*IfDefine>/Include \\/etc\\/apache2\\/mod_status.conf\\nInclude \\/etc\\/apache2\\/mod_info.conf/g }' \\
httpd.conf.tmp > httpd.conf
Um ein wenig manuelle Arbeit kommen Umsteiger trotzdem nicht herum. Damit ein paar Einstellungen der alten Konfigurationsdatei funktionieren, sind Änderungen an der SuSE-spezifischen Datei /etc/sysconfig/apache2 notwendig. Zum einen sind hier in der Parameterliste der Variablen APACHE_MODULES die Einträge status und info hinzuzufügen, zum anderen sollte der Wert von APACHE_SERVER_FLAGS auf STATUS geändert werden. Empfehlenswert, aber nicht zwingend erforderlich ist das Einsetzen der IP-Adresse des Rechners als Parameter von APACHE_SERVER_NAME.
Zur Überprüfung der Konfigurationsdatei auf korrekte Syntax müssen Sie nicht unbedingt den Webserver starten und auf eine Fehlermeldung warten. Viel einfacher geht das mit dem Hilfsprogramm apache2ctl. Mit dem Parameter -t aufgerufen liest es die Konfigurationsdatei ein und bricht ab, sobald es einen Fehler findet.
Das Script können Sie hier downloaden.
Die ersten Schritte
Sind Erstinstallation oder Upgrade abgeschlossen, kann man den Server mittels /etc/init.d/apache2 start aktivieren. Wurde an der Standardkonfiguration nichts geändert, stellt der Server eine mitgelieferte Seite dar. Um diese abzurufen, geben Sie im Browser einfach als URL die IP-Adresse des Rechners an, auf dem der Webserver läuft.
Wer mehr über den Server wissen möchte, kann sich zusätzliche Informationen mittels spezieller URLs holen - allerdings nur über das Loopback-Interface, also von dem Rechner aus, auf dem der Webserver läuft. So erhalten Sie über http://localhost/server-info eine Statusseite mit umfangreichen Daten über die einzelnen Module, unter http://localhost/server-status stehen allgemeine Statistiken über Auslastung des Servers, belegte CPU-Zeiten und so weiter zur Verfügung.
Da die auf diesem Weg bereitgestellten Informationen durchaus nützlich sind, möchte man sie vielleicht auch von anderen Rechnern aus abrufen können. Ein entsprechender Versuch resultiert jedoch in einer Fehlermeldung, die zweifelsfrei mitteilt, dass keine Berechtigung zum Zugriff auf das angeforderte Verzeichnis besteht.
Grundlagen zur Sicherheit
Ursache dafür sind die sehr restriktiven Einstellungen, die per Default für die Informationsseiten des Servers eingerichtet sind. So finden sich sowohl in der für die Informationsseite zuständigen Datei /etc/apache2/mod_info.conf als auch in dem Pendant für die Statusanzeige /etc/apache2/mod_status.conf folgende Einstellungen:
Order deny,allow
Deny from all
Allow from localhost
Diese Einstellung macht nicht ganz das, was man auf den ersten Blick vermuten würde. Entgegen der eigentlichen Erwartung schaltet der Befehl Order deny,allow den Zugriff prinzipiell frei. Nur abrufende Systeme, die den hinter dem Schlüsselwort Deny spezifizierten Kriterien entsprechen, werden abgewiesen. Wer nicht in diese Gruppe fällt oder in der Parameterliste der Anweisung Allow erwähnt ist, erhält Zugriff. Umgekehrt arbeitet dann die BefehlsfolgeOrder allow,deny. Hier ist der Zugriff prinzipiell verwehrt, es sei denn, das aufrufende System ist explizit in der Allow-Liste aufgeführt. Die wirklich sichere Variante wäre also, anstelle von Order deny,allow die entgegengesetzte Option Oder allow,deny zu verwenden. Wer das nicht glaubt, darf es gerne selbst ausprobieren.
Um nun zum Beispiel in einem lokalen Netz mit dem privaten IP-Adressbereich 192.168.1.0 bis 192.168.1.255 von jedem Rechner aus auf die Statusinformationen Zugriff zu haben, wären die Parameter wie folgt zu ändern:
Order allow,deny
Allow from 192.168.1.0/24
Diese Einstellung erlaubt den Zugriff von einer beliebigen IP-Adresse aus dem Subnetz 192.168.1.x. Soll nur bestimmten Rechnern der Zugriff erlaubt sein - etwa der Admin-Workstation mit der Adresse 192.168.1.10 und dem Server selbst - dann sähen die Einstellungen so aus:
Order allow,deny
Allow from 192.168.1.10/32 localhost
Wie zu sehen ist, können die Angaben auf einer Zeile erfolgen. Es ist aber auch erlaubt, mehrere Zeilen zu verwenden, und das Mischen beider Varianten ist ebenfalls möglich.
Die eigene Web-Seite: Vorbereitungen
Das ist zwar alles recht interessant, aber eigentlich betreibt man den Server ja nicht dazu, sich irgendwelche Informationen anzusehen, sondern weil man selbst eigene Seiten veröffentlichen möchte. Um dieses Vorhaben zu realisieren, gibt es zwei Möglichkeiten: eine einfache und eine sinnvolle. Die einfache Variante besteht darin, sich die Konfigurationsdatei des Webservers anzusehen und herauszufinden, aus welchem Verzeichnis heraus er seine Standardseite bezieht. Dort legt man dann eigene Inhalte ab, und fertig ist die Website.
Damit handelt man sich allerdings mehrere Nachteile ein. Der gravierendste davon: Dieses Verfahren erlaubt nur eine einzige Website. Spätestens wenn der Wunsch nach weiteren Seiten aufkommt, beispielsweise für administrative Funktionen, muss eine andere Lösung gefunden werden. Apache bietet von Haus aus schon die Möglichkeit, mit einem Server mehrere Websites zu bedienen. Dazu verwendet er so genannte "Virtuelle Server", die sich durch ihren Namen unterscheiden. Auf diese Weise lassen sich die Web-Auftritte www.meinedomain.de und admin.meinedomain.de problemlos anlegen und komfortabel verwalten.
Unter SuSE-Linux finden sich Templates zum Erzeugen von virtuellen Hosts im Verzeichnis /etc/apache2/vhosts.d/. Zusätzlich sollte in httpd.conf die folgende Zeile für das automatische Einbinden dort abgelegter Virtual-Host-Konfigurationen sorgen, sofern diese die Dateinamensendung .conf besitzen:
Include /etc/apache2/vhosts.d/*.conf
Sollte diese Zeile fehlen, genügt es, sie am Ende der Datei einzufügen. Zusätzlich ist in httpd.conf der Kommentar vor dem Befehl #NameVirtualHost * zu entfernen. Achtung: Sollte hier hinter dem * noch ein :80 stehen, ist dieses zu entfernen. Andernfalls reagiert Apache 2.x mit kryptischen Fehlermeldungen, deren Ursache später nur schwer zu finden ist.
Verzeichnis-Layout
Bevor es an die Konfiguration des Apache für die neue Site geht, noch ein paar Gedanken zur Verzeichnisstruktur. SuSE Linux legt für jeden neuen User automatisch ein Verzeichnis namens public_html an, das für Web-Inhalte gedacht ist. Auf Grund der zusätzlich notwendigen Verzeichnisse für temporäre Daten, Protokolldateien und CGI-Scripts wird das jedoch schon bei einem einzigen Web-Auftritt unübersichtlich.
Besser ist es, ein eigenes Verzeichnis zur Aufnahme der Website anzulegen. Unterhalb davon werden Verzeichnisse erzeugt, deren Namen eine eindeutige Identifikation des jeweiligen Web-Auftritts erlauben. Erst hier findet sich dann die eigentliche Verzeichnisstruktur der einzelnen Website. Um dieses Schema für die von dem Benutzer webuser verwaltete Domain www.meinedomain.de anzulegen, sind als Superuser folgende Befehle auszuführen:
useradd -m webuser
mkdir -p /home/webuser/websites/www.meinedomain.de
mkdir -p /home/webuser/websites/www.meinedomain.de/cgi-bin
mkdir -p /home/webuser/websites/www.meinedomain.de/content
mkdir -p /home/webuser/websites/www.meinedomain.de/etc
mkdir -p /home/webuser/websites/www.meinedomain.de/log
mkdir -p /home/webuser/websites/www.meinedomain.de/tmp
chown -R webuser /home/webuser
chmod -R a+rx /home/webuser/websites
chmod 777 /home/webuser/websites/www.meinedomain.de/log
chmod 777 /home/webuser/websites/www.meinedomain.de/tmp
Der Parameter -p für den Befehl mkdir bewirkt, dass eventuell noch nicht vorhandene übergeordnete Verzeichnisse automatisch angelegt werden. Das Ändern der Leserechte mittels chmod ist notwendig, damit Apache überhaupt auf die gespeicherten Inhalte zugreifen und Protokolldaten sowie temporäre Dateien schreiben kann. Jetzt ist es an der Zeit, den virtuellen Host zu konfigurieren.
Der virtuelle Host
Das vorgefertigte Template von SuSE in /etc/apache2/vhosts.d/vhost.template besticht nicht gerade durch Geradlinigkeit und Übersichtlichkeit - es ist überfrachtet, und die Struktur ist nicht optimal. Daher hier eine einfache Variante, die denselben Zweck erfüllt:
<VirtualHost *>
ServerAdmin webmaster@meinedomain.de
ServerName www.meinedomain.de
ErrorLog /home/webuser/websites/www.meinedomain.de/log/error.log
CustomLog /home/webuser/websites/www.meinedomain.de/log/access.log combined
DocumentRoot /home/webuser/websites/www.meinedomain.de/content/
ScriptAlias /cgi-bin/ /home/webuser/websites/www.meinedomain.de/cgi-bin/
<Directory /home/webuser/websites/www.meinedomain.de/content/>
AllowOverride All
Order allow,deny
Allowfrom all
</Directory>
<Directory /home/webuser/websites/www.meinedomain.de/cgi-bin/>
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Um die Änderungen zu aktivieren, muss der Webserver über den Befehl /etc/init.d/apache2 restart neu gestartet werden, damit er die neuen Konfigurationsdaten übernimmt.
Mit den Angaben in www.meinedomain.de.conf erhält Apache die Informationen darüber, wie er die in Seitenabrufen enthaltenen Pfadangaben auf das lokale Dateisystem des Rechners umsetzen soll und welche Sicherheitsmechanismen dabei zum Einsatz kommen sollen. Das Schlüsselwort Documentroot legt das Wurzelverzeichnis für den Web-Auftritt fest. So führt ein Abruf der URL http://www.meinedomain.de dazu, dass Apache im lokalen Verzeichnis /home/websuer/websites/www.meinedomain.de/content nach der Startseite sucht. Ein kleiner Kunstgriff versteckt sich hinter der Zeile, die mit dem Schlüsselwort ScriptAlias beginnt. Sie teilt dem Webserver mit, dass ein Aufruf von http://www.meinedomain.de/cgi-bin/ nicht in das lokale Verzeichnis /home/webuser/websites/www.meinedomain.de/content/cgi-bin/ führt, sondern stattdessen in das parallel zum Content-Verzeichnis angelegte, spezielle Verzeichnis cgi-bin. Dies dient der Sicherheit des Web-Angebots, da so über normale Aufrufe durch einen Browser nicht einmal versehentlich Zugriff auf die Klartextinhalte der CGI-Scripts erfolgen kann.
Ein Aufruf der Domain im Browser führt aber momentan noch nicht zum gewünschten Erfolg. Schließlich ist noch nicht festgelegt, zu welcher IP-Adresse die Domain www.meinedomain.de aufgelöst werden soll. Wer Zugriff auf einen DNS-Server hat, kann den notwendigen Eintrag selbst vornehmen. Für lokale Tests genügt es, auf dem Rechner, von dem aus mit dem Browser auf die Webseite zugegriffen wird, die Hosts-Datei anzupassen.
Diese findet sich unter Linux und auch auf neueren Apple-Rechnern unter Mac OS X in der Datei /etc/hosts. Windows 2000, 2003 und XP legen die Datei in C:\\Windows\\System32\\drivers\\etc ab. Eine einzige, zu der Datei hinzugefügte Zeile verschafft schnellen Zugriff auf die gerade angelegte Web-Seite:
<ip-adresse des web-servers> www.meinedomain.de
Für den Platzhalter <ip-adresse des web-servers> ist selbstverständlich die richtige IP-Adresse einzutragen - zum Beispiel 192.168.1.66 für einen Webserver in einem lokalen, vom Internet aus nicht erreichbaren Netz.
Ein erneuter Abruf der URL http://www.meinedomain.de präsentiert nun eine leere Verzeichnisübersicht. Ursache dafür ist, dass noch keine Inhalte in Form von HTML- oder PHP -Dateien hinterlegt sind. Wenn es stört, dass Apache in diesem Fall einfach die im Verzeichnis enthaltenen Dateien anzeigt, kann man schnell Abhilfe schaffen. Es reicht aus, eine leere Datei mit dem Namen index.html im Verzeichnis zu erzeugen, zum Beispiel über das Kommando
touch /home/webuser/websites/www.meinedomain.de/content/index.html
Den Besuchern des Web-Auftritts wird nun eine leere Seite angezeigt.
Die Beispielkonfiguration können Sie hier herunterladen.
Fazit
Mit Apache 2.x einen Webserver einzurichten, ist kein Hexenwerk. Nur wenige Kommandos in den richtigen Dateien sind notwendig, um eine funktionierende Konfiguration auf die Beine zu stellen. Das für manche zunächst vielleicht ungewohnte Editieren in Textdateien wird schnell zur Gewohnheit, und vor allem bei der Administration von Servern im Internet zahlt es sich schnell aus, ohne grafische Benutzeroberfläche auskommen zu können. Kein Wunder, dass Apache so viele Freunde hat. (mha)