TFT Monitor bei Mercateo kaufen.

Neues Netbook? Ein Preisvergleich lohnt sich.

Bei uns finden sie Notebooks, PDAs und Drucker mit Testberichten und Tipps.

Diamant Buchhaltungssoftware – transparent und detailliert auch für die Konzernbuchhaltung.

Günstige Shareware Programme als direkte Downloads im Software Portal.

Bis zu 70% sparen durch Preisvergleich.

Erschienen in LinuxUser 06/2002 » Ausgabe bestellen

Web-Server Apache 2

Neuer Indianer

von Marc André Selig

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).

Abb. 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.

Module: Programm-Fragmente, die je nach Bedarf nachgeladen und in ein bereits laufendes Programm eingebunden werden. Viele Apache-Installationen verwenden Module für Funktionalitäten, die nur manchmal gebraucht werden.
CGI: Beim "Common Gateway Interface" handelt es sich um ein fest definiertes Protokoll für die Interaktion zwischen einem Web-Server und einem externen Programm. So können beispielsweise C-Programme oder Perl-Skripte dynamisch HTML-Code erstellen, der genau auf den jeweiligen Benutzer zugeschnitten ist.

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).

PGP: "Pretty Good Privacy" ist ein System für Verschlüsselung und digitale Unterschriften, das unabhängig von zentralen Authentifizierungsdatenbanken arbeitet. Unix-Software wird oft mit PGP digital signiert, um Manipulationen durch Dritte zu verhindern.

Kasten 1: Code-Signaturen überprüfen

Daten, die auf ans Internet angeschlossenen Rechnern lagern, lassen sich genausowenig wie Daten, die über dieses öffentliche Netz wandern, hundertprozentig gegen Manipulation schützen. Wird ein Server gehackt, kann der Angreifer unter Umständen Veränderungen an Dateien, etwa Quelltext-Archiven, herbeiführen, die einem arglosen Downloader nicht sofort auffallen. Der Schaden -- beispielsweise eine in den Code eingebaute Hintertür -- fiele unter Umständen sehr spät auf und würde die Vertrauensbasis von Programmierern und Nutzern der jeweiligen Software irreparabel zerstören.

Verantwortungsvolle Programmierer (speziell, wenn sie so sensible Software wie einen Web-Server schreiben) sorgen deshalb dafür, dass die Nutzer eine Möglichkeit haben, zu überprüfen, ob das Archiv, das sie herunterladen, auch tatsächlich dem von den Herausgebern freigegebenen entspricht. Die einfachste Möglichkeit sind Prüfsummen. Hier kommt sehr oft eine MD5 checksum zum Einsatz: Mit dem (auf den meisten Linux-Systemen vorhandenen) Programm md5sum erzeugt der- oder diejenige, der/die eine Datei ins Netz stellt, einen für dieses File eindeutigen Digest und legt diese Zeichenkette mit auf den Server. Dasselbe tut der User, der die Datei heruntergeladen hat. Stimmen beide Prüfsummen überein, kann man zumindest davon ausgehen, dass beim Download keine Daten kaputtgegangen sind.

Da ein erfolgreicher Angreifer relativ einfach eine solche Check-Summe "seines" manipulierten Archivs auf dem Server ablegen kann, muss man zum tatsächlichen Sicherstellen der Integrität eines Software-Archivs härtere Geschütze auffahren: kryptographische Signaturen. So wie man PGP oder GnuPG zum Signieren ("Unterschreiben") einer E-Mail benutzt, kann man diese beiden Programme auch zum Signieren von Code-Archiven einsetzen. Im Unterschied zu E-Mails legt man die digitale Signatur dabei aber in einer extra ASCII-Datei ab.

Um ein Quelltextarchiv zu verifizieren, braucht der Downloader den oder die öffentlichen Schlüssel der Herausgeber, die das Apache-Team in einer Datei namens KEYS ablegt. Diese importiert man in seinen eigenen Schlüsselbund (mit PGP 2.6.x pgp -ka KEYS, bei GnuPG mit gpg --import KEYS).

Hat man nun signiertes Archiv (httpd-2.0.35.tar.gz) und Signaturdatei (httpd-2.0.35.tar.gz.asc) im gleichen Verzeichnis liegen, lässt sich die Integrität des Archivs mit pgp httpd-2.0.35.tar.gz.asc httpd-2.0.35.tar.gz bzw. gpg --verify httpd-2.0.35.tar.gz.asc httpd-2.0.35.tar.gz überprüfen. Damit GnuPG die teilweise alten PGP-2-Schlüssel der Apache-Entwickler verwenden kann, muss es allerdings speziell angepasst sein. Nähere Informationen dazu erhalten Sie u. a. unter http://www.gnupg.org/gph/en/pgp2x/x23.html. (Patricia Jung)

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.

Linker: Wer lapidar vom "Kompilieren" spricht, meint meist nicht nur das Übersetzen des menschenlesbaren Quelltexts in sogenannte "Objekt-Dateien" mit der Endung .o, sondern auch das Zusammenfügen ("Linken") von selbstkompilierten Objekt-Dateien und externen Bibliotheken zu einem ausführbaren Programm. Diese letzte Aufgabe übernimmt der Linker, unter Linux meist der GNU-Linker ld.
Debugging: Fehlersuche beim Programmieren. Um sich diese Arbeit mit Hilfe von Debugger-Programmen zu erleichtern, schaltet man mit speziellen Compiler-Optionen sogenannte Debugging-Informationen ein. Da der entsprechende Code im Produktionseinsatz nur unnötig Ressourcen frisst, kann der Linker sie auch wieder herausstreichen.

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

Bibliotheken: Linux arbeitet intensiv mit dynamischen Bibliotheken für diverse Hilfsfunktionen. Beim Aufruf einer Programmdatei lädt der dynamische Linker ld.so die notwendigen Bibliotheken in den Speicher. Das aufgerufene Programm selbst gibt die benötigte Bibliothek nur mit Name und Hauptversion an -- wo die Bibliothek genau steht und welche Version tatsächlich verwendet wird, entscheidet die individuelle Situation auf dem System. So sind Updates sehr einfach möglich. Die Datei /etc/ld.so.conf informiert ld.so über die verfügbaren Bibliotheksverzeichnisse. Der Befehl ldconfig erstellt eine binäre Datenbank aller installierten Bibliotheken.

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.

Listing 1: Installationsbefehle für PHP 4.2.0 RC4

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

PHP: Der "PHP Hypertext Preprocessor" erlaubt das Einbetten von Programmcode in HTML-Seiten. Sie speichern sozusagen eine HTML-Seite mit eingebautem Programm ab: Wenn ein Benutzer diese Seite anfordert, wird das Programm ausgeführt. Es erzeugt in der Regel HTML-Code; der Browser des Benutzers bekommt also kein PHP zu sehen (siehe Abbildung 2). Die Programmiersprache selbst erinnert ein bisschen an C. Sie ist schnell erlernbar. Mit einfachen Mitteln kommen Sie dank PHP zu ganz erfreulichen Resultaten, und die Auswahl an vorgefertigter PHP-Software ist unermesslich.

Abb. 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.

Port: Jeder Unix-Service ist durch eine Port-Nummer eindeutig identifiziert. HTTP-Server verwenden in der Regel den Port 80. Abgesicherte Verbindungen werden über Port 443 abgewickelt -- dafür sind jedoch weitere Module und Verwicklungen nötig, die den Rahmen dieses Artikels sprengen. Inoffizielle Server arbeiten oft auf höheren Port-Nummern, z. B. 8000 oder 8080.

 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>

Prozess: Vereinfacht gesagt heißt jedes laufende Unix-Programm "Prozess". Viele Prozesse können gleichzeitig ablaufen, was aber entsprechende System-Ressourcen beansprucht.
Thread: ("Faden") Mit neueren Programmiermodellen können Abläufe innerhalb ein und desselben Prozesses parallel erfolgen. Das System muss nur einen Prozess verwalten, trotzdem geschehen mehrere Dinge (quasi) gleichzeitig. Für bestimmte Aufgaben bieten Threads einen enormen Performance-Gewinn -- Apache 2 ist ein Beispiel.

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).

Server Side Includes: Ermöglichen eingeschränkt dynamische Seiten, die sich zum Beispiel in Abhängigkeit von der IP-Adresse des Clients ändern. Heute benutzt man eher PHP oder ähnliche Mechanismen.

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*.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.

Init-Skript: Das Programm init wird unmittelbar nach dem Boot-Vorgang aufgerufen und verwaltet alle laufenden Prozesse. Je nachdem, in welchem Betriebszustand (Runlevel) sich das Linux-System gerade befindet, sollen unterschiedliche Programme laufen. Beim Übergang von einem Betriebszustand in einen anderen (zum Beispiel beim Reboot) müssen ggf. auch Programme beendet werden. Welche Software jeweils gestoppt und gestartet werden soll, erfährt init durch entsprechende Kontrollskripte in den Init-Verzeichnissen /etc/init.d/rc*.d o. ä.
Symlinks: "Symbolische Links" sind logische Verknüpfungen von einer Datei zu einer anderen. Sie erstellen einen Symlink mit dem Befehl ln -s. Wenn nun jemand auf den Link zugreift, wird er tatsächlich auf die verlinkte Datei verwiesen -- und zwar völlig transparent, ohne dass er dazu etwas tun müsste. Symlinks eignen sich hervorragend für Situationen, in denen eine Datei an mehreren Stellen im Dateisystem gebraucht wird, oder auch für "umgezogene" Dateien und Verzeichnisse.

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. (pju)

Der Autor

Marc André Selig ist gleichzeitig Mediziner und Informatiker. Da diese Konstellation offenbar zu großzügigen Mengen an Freizeit führt, bleibt ihm reichlich Gelegenheit für sein Hobby, das Schreiben ...

Infos

[1] Roy T. Fielding u. a.: RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1".
[2] Tim Berners-Lee u. a.: RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0".
[3] Apache-Web-Seite: http://httpd.apache.org/
[4] Dokumentation zu httpd.conf: http://httpd.apache.org/docs-2.0/mod/directives.html
[5] Apache-Konfigurationsdatei zu diesem Artikel: http://www.seligma.com/linux-user/apache/
[6] PHP-Web-Seite: http://www.php.net/
[7] PHP-Download: http://www.php.net/%7Ederick/php-4.2.0RC4/

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.