Der modulare Aufbau des Apache-Webservers erlaubt es, quasi beliebige Module zu integrieren und auf diesem Weg spezielle Funktionen zur Verfügung zu stellen. In der Standard-Installation der meisten Distributionen sind viele der mitgelieferten Erweiterungen jedoch gar nicht aktiviert, so dass weder die Besucher der Webseiten noch der Administrator von ihren Funktionen profitieren können. Dabei ist es gar nicht so schwer, die verborgenen Schätze zu heben.
Besonders interessant sind die folgenden Möglichkeiten:
Datenkompression reduziert den Traffic und damit die Kosten des Betreibers. Zudem kommt die Seite schneller beim Benutzer an.
Caching-Mechanismen senken die Last auf dem Server und verschaffen dem Benutzer bessere Antwortzeiten.
Mittels Authentifizierung sperren Sie bestimmte Bereiche Ihrer Website und gewähren nur bestimmten Benutzergruppen Zugriff.
Diesen Artikel und eine ganze Reihe weiterer Praxis-Themen finden Sie auch in unserem neuesten tecCHANNEL-Compact. Dort erfahren Sie nicht nur, wie Sie einen Apache 1.x unfallfrei auf Apache 2 upgraden, sondern unter anderem auch wie Sie einen Email-Server mit dem Freeware-Tool XMail aufsetzen und via SpamAssassin vor unerwünschten Mails schützen. Auf der Heft-CD finden Sie einen kompletten LAMP-Server von SuSE sowie den Intel C++-Compiler für Linux, mit dem Sie Ihre Programme optimal auf Ihre Prozessor-Architektur abgestimmt compilieren können. Der Compiler ist für den Privatgebrauch sogar kostenlos.
Traffic reduzieren mit Datenkompression
Einer der größten Kostenfaktoren beim Betrieb eines Webauftritts sind die anfallenden Gebühren für das übertragene Datenvolumen - neudeutsch Traffic genannt. Der größte Teil der von Webseiten abgerufenen Informationen besteht aus reinem Text und ist damit leicht komprimierbar. Diese Erkenntnis ist weder an den Programmierern der Webserver, noch an den Entwicklern der Browser vorübergegangen. So sind moderne Server und Browser in der Lage, neben der Übertragung im Klartext auch verschiedene Kompressionsverfahren auszuhandeln.
Benutzer von Apache 1.3.x konnten erst mit Hilfe des externen Moduls mod_gzip in den Genuss der volumenreduzierenden Packalgorithmen kommen, ist dieses Feature in Form des Moduls mod_deflate bei Apache 2.x bereits enthalten. Allerdings ist dieses zumindest bei SuSe Linux 9.0 nicht aktiviert. Aber das lässt sich leicht ändern.
Dazu ist zunächst in der Datei /etc/sysconfig/apache2 die Parameterliste für die Variable APACHE_MODULES um den Wert "deflate" zu erweitern. Das bewirkt, dass beim nächsten Neustart des Webservers über /etc/init.d/apache2 restart das Deflate-Modul zur Komprimierung der übertragenen Daten geladen wird.
Konfiguration von Deflate
Allerdings reicht die reine Aktivierung von Deflate noch nicht aus, um die Datenkompression sinnvoll zu nutzen. Dazu sind ein paar weitere Befehle in die Datei /etc/apache2/httpd.conf zu schreiben:
<Location />
SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\\.0[678] no-gzip
BrowserMatch \\bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \\
\\.(?:gif|jpe?g|png)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary
</Location>
Diese Befehlsfolge können Sie an zwei verschiedenen Stellen verwenden: zum einen direkt in der zentralen Konfigurationsdatei httpd.conf. In diesem Fall wirkt sich die Kompression auf alle vom Webserver ausgelieferten Seiten aus - egal von welchem virtuellen Host sie stammen. Zum anderen lässt sich auch jeder einzelne virtuelle Host mit diesen Befehlen ausstatten. Auf diese Weise können Sie bei eventuellen Problemen mit einem bestimmten Webauftritt die Kompression für diesen gezielt deaktivieren.
Die diversen Zeilen mit dem Schlüsselwort BrowserMatch sorgen dafür, dass bekannte Probleme mit älteren Browsern umgangen werden. Über die Anweisung SetEnvIfNoCase erfährt der Webserver, dass Grafikdaten nicht durch den Kompressionsfilter zu schicken sind. Die mit dem Schlüsselwort Header beginnende Zeile schließlich sorgt dafür, dass eventuell zwischen Nutzer und Webserver liegende Proxies die Inhalte korrekt an den Besucher weiterleiten.
Überwachung von Deflate
Um zu prüfen, dass die Kompression auch Erfolge erzielt, empfiehlt es sich, in der Testphase ein eigenes Logfile mit den erreichten Kompressionsraten anlegen zu lassen. Dabei hilft das Deflate-Modul durch das Bereitstellen eines neuen Schlüsselworts: DeflateFilterNote. Es erlaubt die Belegung neuer Variablen, die zum Erzeugen einer benutzerdefinierten Protokolldatei verwendet werden können:
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
CustomLog /home/webuser/websites/www.meindomain.de/log/deflate.log deflate
In der Regel liegen die per Deflate-Modul erzielten Kompressionsraten bei 20 bis 50 Prozent der Ausgangsinformationen. Speziell Besucher, die per Modem oder ISDN im Internet unterwegs sind, werden den Unterschied durch einen deutlich schnelleren Seitenaufbau bemerken. Netter Nebeneffekt: Nicht nur der Webmaster profitiert vom sinkenden Transfervolumen. Auch DSL-Nutzer mit Volumentarif können mehr Surfen, da weniger Daten vom Server zu ihnen fließen.
Kürzere Antwortzeiten dank Caching
Speziell gut besuchte Webseiten haben mit dem Problem zu kämpfen, dass schnell die Festplatte zum Flaschenhals wird. Apache 2.x bietet zur Lösung dieses Problems einen eigenen Cache an, der entweder den Hauptspeicher oder ein Verzeichnis der Festplatte als Zwischenspeicher nutzt.
Um den Cache zu verwenden, müssen mindestens zwei der drei vorhandenen Module beim Start von Apache geladen werden: das Zentralmodul mod_cache sowie eines der beiden Speichermodule mod_mem_cache und mod_disk_cache. Es ist ratsam, hier einen zweistufigen Ansatz zu verwenden, um einen leichten Wechsel zwischen den beiden Modulen zu ermöglichen. Dazu ist zum einen die Parameterliste der Variablen APACHE_MODULES in der Steuerdatei /etc/sysconfig/apache2 um den Wert "cache" für das Zentralmodul zu erweitern. In die Konfigurationsdatei des Webservers (/etc/apache2/httpd.conf) kommt dann noch ein Befehlsblock, der zwischen Caching im Speicher und Caching auf Disk umschaltet:
<IfModule mod_cache.c>
#LoadModule disk_cache_module /usr/lib/apache2-prefork/mod_disk_cache.so
<IfModule mod_disk_cache.c>
CacheRoot /tmp/cacheroot
CacheSize 256
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
</IfModule>
LoadModule mem_cache_module /usr/lib/apache2-prefork/mod_mem_cache.so
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 4096
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 2048
</IfModule>
</IfModule>
Je nachdem, welche der beiden mit LoadModule beginnenden Anweisungen aktiviert - also nicht per Kommentarzeichen "#" abgeschaltet - ist, verwendet der Webserver nun das Caching für alle von ihm bereitgestellten Seiten. Sollte dies bei einzelnen Webauftritten zu Problemen führen, lässt sich das Caching innerhalb der Anweisungen für den betroffenen virtuellen Host gezielt abschalten:
<IfModule mod_cache.c>
CacheDisable /
</IfModule>
Einfacher Zugriffsschutz
Nicht immer ist es erwünscht, dass alle Bereiche des Webauftritts für jeden Surfer erreichbar sind. Um einzelne Verzeichnisse oder auch einzelnen Dateien vor fremden Blicken zu schützen, bietet der Apache-Server einige Verfahren zur vorherigen Authentifizierung des Anwenders. Schlägt diese fehl, bleibt der Zugriff auf die Informationen verwehrt.
Um diesen Zugriffsschutz zu implementieren, existieren zwei Verfahren. Auf der einen Seite können die notwendigen Befehle direkt in der Konfigurationsdatei für einen virtuellen Host eingetragen werden. Alternativ dazu lässt sich in dem zu schützenden Verzeichnis eine Datei mit dem Namen .htaccess ablegen, welche die notwendigen Befehle enthält. Diese Variante funktioniert in der Regel auch dort, wo kein Zugriff auf die Konfiguration des Webservers besteht, beispielsweise wenn der Webauftritt von einem ISP gehostet wird. Voraussetzung dafür ist allerdings, dass für das zu schützende Verzeichnis hinter dem Schlüsselwort AllowOverride die Option "AuthConfig" gesetzt ist. Für die im ersten Teil beschriebene Beispiel-Domain www.meinedomain.de sähe das also so aus:
<Directory /home/websuser/websites/www.meinedomain.de/content/>
AllowOverride Options FileInfo AuthConfig
Order allow,deny
Allow from all
</Directory>
Die Datei .htaccess
Um beispielsweise das über die URL http://www.meinedomain.de/basetest erreichbare Verzeichnis zu schützen, muss dieses angelegt und in ihm die Datei .htaccess mit folgendem Inhalt erzeugt werden:
AuthType Basic
AuthName "BaseTest"
AuthUserFile /home/webusers/websites/base.users
Require valid-user
Damit legt man fest, dass für das Verzeichnis die Basis-Authentifizierung zum Einsatz kommt. Die nötigen Daten zur Überprüfung eines Users bezieht das System aus der Datei /home/webuser/websites/base.users. Über die Anweisung Require valid-user erfährt der Webserver, dass jeder Anwender aus dem Benutzerverzeichnis Zugriff erhält.
Das Benutzerverzeichnis
Für diese Aufgabe ist unter SuSE Linux 9.0 das Hilfsprogramm htpasswd2 zuständig. Es dient sowohl zum Anlegen der Datei mit den Benutzerinformationen wie auch zum Ändern der dort abgelegten Passwörter. Zur ersten Initialisierung muss das Tool mit dem speziellen Parameter "-c" zum Anlegen der Datei, dem gewünschten Dateinamen sowie dem Namen des ersten anzulegenden Users aufgerufen werden. Bei späteren Aufrufen muss der Parameter "-c" entfallen, da andernfalls eine bereits existierende Datei durch eine leere überschrieben wird.
htpasswd2 -c /home/webuser/websites/base.users webuser
htpasswd2 /home/webuser/websites/base.users gast
Wichtig ist es dabei, darauf zu achten, dass die Datei mit den Zugangsdaten außerhalb des Verzeichnisbaums liegt, aus dem der Webserver die Inhalte für die Webseite bezieht. Andernfalls könnten die Nutzer die Datei einfach herunterladen und versuchen, sie zu entschlüsseln.
Über die reine Benutzerverwaltung hinaus erlaubt die Authentifizierung auch Benutzergruppen. Eine einfache Textdatei stellt dabei die Verbindung zwischen dem Benutzer und den verfügbaren Gruppen her. Über das spezielle Schlüsselwort AuthGroupFile teilt man Apache mit, aus welchem File er die Zuordnungen beziehen soll. Um beispielsweise nur Mitgliedern der Gruppe "admin" Zugriff zu gewähren, ist noch die Datei .htaccess um die Zeile
Require group admin
zu erweitern. Die Gruppendatei selbst hat einen einfachen Aufbau:
admin: webuser
normal: gast test
Diese Vorgabe teilt den Benutzer webuser in die Gruppe admin ein, während die Anwender gast und test der Gruppe normal zugeordnet werden.
Erweiterter Zugriffsschutz
Besonders bei Webseiten mit einer großen Anzahl von Usern, die auf unterschiedliche geschützte Bereiche Zugriff haben, ist die Verwaltung der Zugangsdaten in Textdateien ein Pferdefuß. Bis die einzelnen Einträge durchsucht sind, kann schon geraume Zeit vergehen. Währenddessen erhält der Anwender den Eindruck eines langsamen oder im schlimmsten Fall nicht mehr reagierenden Systems.
Zur Lösung des Problems bietet Apache 2.x für die Verwaltung der Zugangsinformationen alternativ zu den Textdateien die Speicherung in einer Datenbank an. Dazu ist das entsprechende Modul mod_auth_dbm.so beim Start des Servers zu laden, was unter SuSE Linux 9.0 wieder durch das Hinzufügen eines Parameters (auth_digest) zur Variablen APACHE_MODULES in der Datei /etc/sysconfig/apache2 erfolgt.
Für die Steuerdatei .htaccess stehen dann neue Schlüsselwörter zur Verfügung: AuthDBMUserFile und AuthDBMGroupFile. Darüber hinaus erfolgt die Verwaltung der dort gespeicherten Informationen nicht mehr über das Hilfsprogramm htpasswd2, sondern über das Script dbmmanage2. Das obige Beispiel für die einfache Authentifizierung wäre also wie folgt zu ändern:
AuthType Basic
AuthName "BaseTest"
AuthDBMUserFile /home/webusers/websites/dbm.users
AuthDBMGroupFile /home/webusers/websites/dbm.users
Require valid-user
Wie zu sehen ist, verweisen die Einträge für AuthDBMUserFile und AuthDBMGroupFile auf dieselbe Datei. Der Grund dafür ist, dass dbmmanage2 diese Informationen in einer Datenbank ablegt. Wer möchte, kann dies aber auch in separaten Dateien tun - muss dann allerdings die Verwaltung selbst übernehmen. Aber auch dbmmanage2 hat seine Tücken.
So ist strikt darauf zu achten, dass nach dem Anlegen eines neuen Benutzers unbedingt die Update-Funktion ausgeführt und das Passwort erneut gesetzt wird. Beim ersten Anlegen schreibt das Hilfsprogramm das Passwort nämlich im Klartext in die Datenbank. Da dies später kaum mit dem dann verschlüsselten Passwort übereinstimmt, das während der Authentifizierung erzeugt wird, ist ein Login des betroffenen Anwenders somit unmöglich.
Fazit
Besonders die Funktionen zur Kompression und zum Caching sollten Sie auf Ihrem Apache-Server einsetzen. Denn ein besseres Antwortverhalten sorgt dafür, dass Ihre Besucher auch länger bleiben und später auch wiederkommen. Eine Website, bei der ein Benutzer für jeden Seitenaufruf mehrere Sekunden warten muss, wird sich auf Dauer sicherlich nicht in der Favoritenliste halten. Zudem können Sie gerade mit Kompression Ihre laufenden monatlichen Kosten deutlich senken.
Wenn es um Community-Sites mit verschiedenen Sicherheitsbereichen geht, kommen Sie um die erweiterte Authentifizierung mit mod_auth_dbm.so nicht herum. Die textbasierte Variante ist zu langsam und zu fehleranfällig - sie reicht gerade aus, ein Verzeichnis mit einem Standard-Passwort zu belegen, so dass nur Besucher darauf zugreifen können, denen Sie die Login-Daten zukommen lassen. Verschiedene Logins für jeden Besucher sind damit nicht realisierbar. (mha)