IIS und Apache besser nutzen

Webserver dienen einem einzigen Zweck: Sie sollen den Besuchern möglichst schnell die richtige Seite liefern. Mit ein paar Tricks können sie aber noch mehr: Neben der Umleitung der Surfer oder angepassten Fehlermeldungen ist etwa die bessere Nutzung der Log-Files oder die Kosteneinsparung mit virtuellen Servern möglich. PC Guide präsentiert die besten Tips.

von Marc von Ah

Im Prinzip ist ein Server für das World Wide Web eine ziemlich einfache Angelegenheit: Er braucht in den meisten Fällen längst nicht so tolle Hardware wie etwa ein File- oder Application-Server, und grundsätzlich genügt es, wenn er die Besucher schnell mit den gewünschten Daten versorgt. Diese Aufgabe lässt sich schon mit vergleichsweise einfachen Routinen erledigen.

Dennoch werden auch Webserver ständig weiterentwickelt und verbessert. Und mit jeder neuen Version werden nicht nur Bugs ausgemerzt, sondern auch einige neue Features implementiert. Mittlerweile sind deshalb auch Webserver grosse Pakete, die nicht zuletzt in der Konfiguration zunehmend komplizierter werden und zahlreiche Optionen bieten, die eher selten genutzt werden.

Einige der weniger bekannten Funktionen sind es allerdings durchaus wert, dass man einen zweiten Blick auf sie wirft. So lassen sich mit namensbasierten virtuellen Servern etwa Kosten sparen, weil so mehrere Websites auf einem einzigen physischen Server laufen - und dazu sind nicht einmal zusätzliche IP-Adressen nötig. Mit der Redirektion und dem sogenannten URL-Rewriting lassen sich Anfragen zum passenden Server oder Verzeichnis weiterleiten, selbst wenn der Surfer in seinem Browser eine nicht mehr vorhandene Adresse eingibt. Auf diese Weise kann man den Administrationsaufwand minimieren. Einem ähnlichen Zweck dienen eigene HTTP-Header oder die Anpassung von Fehlermeldungen. 

Mit Hilfe von Logdateien lässt sich schliesslich nicht nur eine Menge über den Zustand des Servers, sondern bei entsprechender Konfiguration auch über die Surfer, ihre Präferenzen und ähnliches herausfinden. Allerdings bedeutet die Wartung der Logfiles einen nicht zu unterschätzenden Aufwand, wenn diese nicht mit geeigneten Tools vorbereitet werden.

Kleine Auswahl

Wir beschränken uns in diesem Workshop auf die Darstellung der Tips für den Apache-Webserver 1.3.9 und den Internet Information Server (IIS) 4.0 von Microsoft. Diese beiden besetzen gemäss einer aktuellen Studie von Netcraft (www.netcraft.com/Survey) gemeinsam über drei Viertel des Webserver-Markts, wobei Apache mit 55 Prozent im September gegenüber den verschiedenen IIS-Derivaten mit 22 Prozent seinerseits deutlich die Nase vorne hat.

Die anderen der rund 30 auf dem Markt verfügbaren Webserver, darunter die verschiedenen Netscape-Enterprise-Server-Varianten, O'Reilly's WebSite Pro, Zeus oder RapidSite, teilen sich die restlichen rund 25 Prozent des Marktes und sind im Rahmen dieses Workshops deshalb vernachlässigbar.

Die beiden führenden Webserver unterscheiden sich in mancherlei Hinsicht. Während der IIS ausschliesslich für Windows NT Server erhältlich, dafür in diesen aber besonders gut integriert ist, gibt es den Apache in Varianten für fast alle Unix-Derivate, Linux, OS/2 und Windows. Beide Programme sind frei verfügbar, allerdings bleibt der IIS letztlich dennoch ein kommerzielles Produkt; Apache dagegen ist Open-Source-Software.

Apache for Windows NT befindet sich derzeit nach wie vor im Beta-Stadium - die Version 1.3.9 ist zwar gemäss der Apache Group «feature-complete», aber weder von Bugs bereinigt noch Performance-optimiert. Auch die Stabilität kann noch Schwierigkeiten bereiten. Die Unterschiede zwischen der Linux- und der NT-Version sind abgesehen davon gering: In Apache for Windows NT fehlen einige der weniger gebräuchlichen Module und Direktiven. Die Konfiguration der beiden Apaches dagegen ist weitgehend identisch: Sie geschieht hauptsächlich über die Textdatei httpd.conf, die unter Linux meist im Verzeichnis /etc/httpd/, unter NT im Ordner \Apache\conf\ zu finden ist.

Ein wichtiger Unterschied liegt ausserdem im Aufbau der Software: Apache verfügt über eine komplett modulare Architektur, was bedeutet, dass zahlreiche Funktionen, die nicht unbedingt benötigt werden, schon gar nicht erst geladen werden müssen. Der ISS dagegen läuft als Komplett-Paket, bei dem auch ungenutzte Features Platz und Speicher benötigen.

Schliesslich unterscheiden sich die beiden Webserver in der Administration. Der IIS arbeitet hier mit Microsofts Management Console zusammen und bietet ein grafisches Interface, das auch übers Web zugänglich ist. Im Gegensatz dazu muss der Apache-Server im allgemeinen nach wie vor über Textdateien konfiguriert und verwaltet werden - abgesehen von den beiden Tools LinuxConf und Webmin, die vor allem der Linux-Konfiguration dienen und nebenbei auch Apache teilweise verwalten können, gibt es zwar einige GUI-Projekte wie Comanche, die derzeit aber noch im Beta-Stadium stecken, sowie das kommerzielle Produkt WarPaint.

Umleitungen auf der Datenautobahn

Eine Website wächst ständig. Allerdings werden oft nicht nur neue Inhalte hinzugefügt: Manchmal ändert sich auch die gesamte Verzeichnisstruktur, Seiten verschwinden komplett oder werden verschoben. Für den Besucher heisst das im allgemeinen, dass er die Seiten nicht mehr findet und seine Bookmarks nicht mehr brauchen kann.

Allerdings besitzt der Webmaster durchaus Mittel und Wege, um den Besuchern seiner Website diesen Frust zu ersparen. Dazu dienen die sogenannten Redirections.Unter Apache gibt es grundsätzlich zwei Möglichkeiten, mit denen die Surfer umgeleitet werden können, nämlich über die Redirect-Direktive und über das sogenannte URL-Rewriting, das vom Modul mod_rewrite zur Verfügung gestellt wird.

Die Redirect-Direktive wird vom Standard-Modul mod_alias bereitgestellt; wenn das Modul einkompiliert ist, findet sich ein entsprechender Eintrag in der Konfigurationsdatei httpd.config. Dieser Eintrag muss bloss auskommentiert und angepasst werden. Soll beispielsweise jeder, der die URL www.windowsguide.ch eingibt, auf die Site www.pcguide.ch umgeleitet werden, könnte das so aussehen:

Redirect www.windowsguide.ch www.pcguide.ch 


 

Ähnlich funktioniert auch die Umleitung auf dasselbe Verzeichnis in einer neuen Domain:

RedirectPermanent /daten www.pcguide.ch/daten 


 

Hier wird jede Anfrage, die den Pfad /daten enthält, auf die neue URL umgeleitet, beispielsweise etwa www.windowsguide.ch/inhalt/daten/beispiel.htm auf www.pcguide.ch/daten/beispiel.htm.

Die Redirect-Direktive unterstützt dabei einige Parameter, die den HTTP-Statuscodes entsprechen. Diese sind Permanent (301; permanente Umleitung), Temp (302; temporäre Umleitung), See other (303; zeigt die Ersetzung einer Ressource an) und Gone (410; Ressource endgültig entfernt). Im obigen Beispiel wird permanent verwendet, die Umleitung findet in jedem Fall statt.

Die zweite (und bessere) Möglichkeit der Umleitung unter Apache funktioniert mit dem Modul mod_rewrite. Auch diese mächtige Komponente wird bei einer Standardinstallation in Apache einkompiliert. Mod_rewrite dient allen möglichen Arten der Anpassung und Abwandlung von URLs: Beispielsweise lassen sich damit browser- oder inhaltsspezifische und auch zeitabhängige Adressen erstellen, nach bestimmten Seiten in verschiedenen Verzeichnissen suchen etc. Im Vordergrund steht hier aber die Umleitung von Besuchern einer Seite auf eine andere, was man mit der Direktive RewriteRule erledigt.

Zuallererst müssen Sie dazu die Rewrite-Engine starten. Darauf folgt dann die Substitutionsregel, die aus zwei Argumenten - dem Suchmuster und dem Substitutionsstring - bestehen muss. Das Suchmuster lässt sich mit einer Reihe regulärer Ausdrücke oder einfachem Text schreiben, der Substitutionsstring dagegen besteht aus Text, Rückverweisen auf das Suchmuster, Server-Variablen oder Maps. Zusätzlich können Flags gesetzt werden.

Ein Beispiel soll das verdeutlichen. Nehmen wir an, wir hätten einen alten Server mit einigen Home-Verzeichnissen, die auf einen neuen Server verschoben werden. Die Lösung ist mit mod_rewrite relativ simpel:

RewriteEngine on RewriteRule ^/~(.+) http://neuer-server/~$1 [R,L] 


 

Hier wird nach dem Start der Rewrite-Engine eine Regel definiert, nach der sämtliche URLs mit dem Format /user/pfad auf http://neuer-server/user/pfad umgeleitet werden. Der Rückverweis $1 entspricht dabei dem Inhalt der Klammer im Suchmuster. Dazu kommen die beiden Flags R und L, die dafür sorgen, dass die neue URL an den Browser zurückgeschickt und die Regelverarbeitung unverzüglich beendet wird.

Das Rewrite-Modul bietet noch eine ganze Menge weiterer Funktionen, deren Beschreibung den Rahmen dieses Workshops aber sprengen würde.

Im IIS gibt es nur die simple Redirektion, um Surfer auf eine andere Adresse umzuleiten - dieser kann aber immerhin auf normale wie virtuelle Verzeichnisse und ganze Server (respektive URLs) angewendet werden. Eine URL-Substitutions-Engine gibt es im Microsoft-Produkt derzeit nicht, entsprechende Funktionen können aber mit dem Internet Server Application Programming Interface (ISAPI) programmiert werden.

Das Anlegen einer Umleitung ist denn auch denkbar einfach: Öffnen Sie den Properties-Dialog für Ihre Website, und wechseln Sie ins Fenster Home Directory. Hier aktivieren Sie anstelle des Radio-Buttons vor A directory located on this computer denjenigen vor A redirection to a URL. Nun geben Sie im Textfeld noch diejenige Adresse an, zu der der Besucher umgeleitet werden soll, und wählen allenfalls noch die eine oder andere der drei Optionen unter The Client will be sent to aus.

Diese Optionen behandeln den Umgang von IIS mit Umleitungen. Mit The exact URL entered above wird der Surfer auf genau diese Zieladresse geschickt, ohne dass irgend etwas zu dieser URL hinzugefügt wird. So lassen sich etwa komplette virtuelle Verzeichnisse auf eine einzelne Datei umleiten. A directory below this one ermöglicht die Umleitung aus einem Home-Verzeichnis zu einem Subdirectory. Permanent Redirection for this resource schliesslich schickt die 301-Statusmeldung und sorgt so für die ständige Umleitung und bei einigen Browservarianten wie den neueren Internet Explorern sogar für die Anpassung der Bookmarks.

Die Redirektion unter IIS kann schliesslich mit einigen Variablen verfeinert werden, die dazu dienen, der Umleitungsadresse Teile der ursprünglichen URL zu übergeben. Details dazu finden Sie in der Dokumentation zum Windows NT Option Pack.

Eine Adresse, mehrere Hosts

Virtuelle Server sind nichts neues: Schon länger wird diese Technik eingesetzt, wenn man mehrere verschiedene Websites auf einem einzigen physischen Server laufen lassen will. Dabei wurden bisher allerdings immer zusätzliche IP-Adressen benötigt, die den virtuellen Servern zugewiesen wurden.

Die Möglichkeit, mehrere virtuelle Hosts (und damit URLs) mit einer einzigen IP-Adresse zu verwenden, wurde mit der Version 1.1 des HTTP-Protokolls neu eingeführt. Dieses Vorgehen bietet verschiedene Vorteile: Auf der einen Seite wird auf diese Weise die Zahl der benötigten, langsam knapp werdenden IP-Adressen reduziert, andererseits kann ein Unternehmen so auch Geld sparen, indem es keine zusätzlichen Adressen kaufen muss. Schliesslich kann dadurch die Administration vereinfacht werden, wenn nicht jede Website auf einer eigenen Maschine läuft.

Unter Apache geschieht die Konfiguration von benannten virtuellen Hosts über eine Anpassung in der Konfigurationsdatei httpd.conf. Im dritten Abschnitt (Virtual Hosts) der Textdatei finden sich die entsprechenden Einträge.

Zunächst müssen Sie mit der Direktive NameVirtualHost eine IP-Adresse und die zugehörige Portnummer definieren. Unmittelbar danach werden im Konfigurationsfile die einzelnen virtuellen Hosts aufgeführt. Das könnte dann etwa so aussehen:

NameVirtualHost 192.168.0.11 # Erster virtueller Host <VirtualHost 192.168.0.11> ServerAdmin webmaster@meine-firma.ch DocumentRoot /www/docs/meine-firma.ch ServerName www.meine-firma.ch … </VirtualHost> # Zweiter virtueller Host <VirtualHost 192.168.0.11> ServerName www.andere-firma.ch </VirtualHost> 


 

Im Internet Information Server richten Sie zunächst ganz normal mit dem Wizard eine neue Site ein, weisen dieser eine IP-Adresse und ein Verzeichnis zu. Danach öffnen Sie die Eigenschaften für die eben erstellte neue Website und wechseln zum Fenster Web Site. Unter dem Eintrag Web Site Identification klicken Sie dann auf den Button Advanced. Im folgenden Fenster wählen Sie den Eintrag für die Site aus, klicken auf Edit und geben im Feld Host Header Name einen (beliebigen) Namen für den virtuellen Host ein.

Diesen Vorgang können Sie nun sooft wiederholen, wie Sie virtuelle Hosts benötigen. Dabei muss bloss beachtet werden, dass sich die Einträge in einer der drei Eigenschaften unterscheiden: Sie können also dieselbe IP-Adresse und auch denselben Port benutzen, müssen dann aber zwingend unterschiedliche Namen haben.

Für Browser ab der dritten Generation stellen die virtuellen Hosts kein Problem dar. Für ältere Browser, die HTTP 1.1 nicht unterstützen, finden sich auf den einschlägigen Server-Sites entsprechende Workarounds.

Beachtet werden muss ausserdem, dass auch für namenbasierte virtuelle Hosts eine Anpassung der DNS-Datenbanken nötig ist: Es müssen CNAME-Einträge eingerichtet werden, die auf einen vorhandenen Host mit A-Eintrag verweisen.

Zusätzliche Köpfe

HTTP-Headers sind eine Möglichkeit, dem Browser eines Besuchers nebst der eigentlich verlangten Seite einige Zusatzinformationen zuzusenden. Standardmässig werden in den Headern Daten wie Server-Typ, HTTP-Version, letztes Modifikationsdatum und ähnliches geliefert. Zusätzliche Infos können etwa Bewertungen des Inhalts oder eine Liste der MIME-Typen sein. Wichtiger allerdings sind Ablaufdaten von Inhalten, die nur über eine bestimmte Zeit gültig sein sollen. Ausserdem ist es möglich, über HTTP-Header benutzerdefinierte Informationen zu versenden, beispielsweise dafür zu sorgen, dass zwar ein Browser eine Seite im Cache speichert, ein Proxy-Server aber nicht.

Unter Apache sind gleich mehrere Module für HTTP-Headers zuständig, die aber nur teilweise standardmässig einkompiliert werden. In der Normalinstallation dabei ist etwa mod_mime, das für MIME-Typen zuständig ist. Separat installiert werden müssen dagegen mod_expires (Verfalldaten von Seiten) und mod_headers (benutzerdefinierte Header). Die Funktionsweise dieser Module verdeutlichen wir am Beispiel von mod_expire.

Dieses Modul muss zuerst in httpd.conf aktiviert werden. Danach können mit den Direktiven ExpiresByType und ExpiresDefault die Bedingungen für den Ablauf festgelegt werden. Verfalldatum und Ablauf heissen in diesem Zusammenhang übrigens nicht, dass das Seitenelement selber ungültig würde - vielmehr wird es im Cache des Browsers für ungültig erklärt und erneut vom Server geladen.

ExpiresActive on ExpiresByType text/plain A3600 ExpiresByType image/gif M604800 ExpiresByType text/html «access plus 2 days» ExpiresDefault «modification plus 7 days» 


 

Aus diesen Beispielen werden einige Dinge schnell offensichtlich: In der Notation der Direktive muss zwingend der MIME-Typ der betroffenen Dateien angegeben werden (ausser bei ExpiresDefault, das das Verfalldatum aller Dateien festlegt), ausserdem ist die Ablaufzeit in Sekunden erforderlich. Es gibt zwei Syntax-Varianten mit den zusätzlichen Optionen A und M, die die Notation der Zeit bestimmen: A bezieht sich auf den Zugriff durch den Client, M auf die letzte Modifikation. Schliesslich ist es möglich, genaue Zeiten ab dem Eintritt einer bestimmten Aktion wie access (Zugriff) oder modification festzulegen.

Im IIS mit seiner grafischen Konfigurationsoberfläche lassen sich dieselben Beispiele einfacher, aber weniger flexibel realisieren. Öffnen Sie wieder die Properties-Dialoge zur aktuellen Website und wechseln Sie da in das HTTP-Headers-Fenster. Auch im IIS müssen die Verfalldaten zuerst aktiviert werden, was mit einem Klick ins Kästchen Enable Content Expiration geschieht. Danach können dann die entsprechenden Werte eingeben werden. Allerdings ist das nur für alle Dokumente gleichzeitig möglich, eine Abstufung nach MIME-Typen wird im IIS derzeit nicht unterstützt.

Lesbare Fehlermeldungen

Die kryptischen Fehlermeldungen und Statuscodes des HTTP-Protokolls - 404 Not Found, 500 Internal Server Error und wie sie alle heissen - sind wohl jedem Surfer und Webmaster geläufig. Leider lässt sich damit häufig wenig anfangen. Wesentlich angenehmer wäre es für den Besucher einer Site, wenn er bei einer falschen URL-Eingabe oder einem internen Server-Fehler nicht nur die Fehlermeldung zurückgeliefert bekommt, sondern auch gleich eine kurze Anleitung, welche anderen Möglichkeiten ihm offenstehen, um an die gewünschte Ressource zu gelangen, ohne den Fehler zu wiederholen.

Apache bietet zur Anpassung von Fehlermeldungen drei Möglichkeiten, die alle mit der Direktive ErrorDocument genutzt werden, aber eine unterschiedliche Syntax verwenden.

ErrorDocument 500 «Der Server hat ein Problem. Ursache: %s .» ErrorDocument 404 /errors/missing.html ErrorDocument 404 http://www.anderer-server.ch/ umgezogen.html 


 

In jedem Fall muss der Direktive der entsprechende Statuscode zugewiesen werden, danach die zugehörige Aktion. Die obigen Beispiele zeigen die möglichen Varianten: Beim 500-Fehler wird hier eine reine Textmeldung ausgegeben, der Platzhalter %s steht für sämtliche dem Server vorliegenden Informationen zum aufgetretenen Fehler. Diese nützen zwar dem Besucher wenig, helfen aber dem Administrator beim Debugging.

Beim zweiten Beispiel wird eine benutzerdefinierte Seite aufgerufen, auf der nebst einer ausführlichen Erklärung des Fehlers weitere Angaben stehen können. Das dritte Beispiel schliesslich arbeitet ähnlich wie die bereits beschriebene Umleitung: Der Besucher wird direkt zu einer anderen URL geführt.

IIS bietet abgesehen von den angepassten Textmeldungen dieselben Möglichkeiten der Fehlermeldungs-Anpassung: Neben der Standardmeldung sind dies die Umleitung auf eine Datei oder eine andere URL.

Eingerichtet werden die benutzerdefinierten Fehlermeldungen in den Web-Site-Properties im Fenster «Custom Errors». Wählen Sie aus der Liste den entsprechenden Fehlercode und klicken Sie auf den «Edit Properties»-Button. Hier können Sie nun den Pfad zur Datei oder die neue URL eingeben.

Optimale Logfile-Konfiguration

Log-Dateien sind eine der wichtigsten Informationsquellen über den Zustand des Servers, und Daten über die Besucher einer Site - etwa über die verwendeten Browser und Betriebssysteme, die Herkunftsadresse (Referrer) und ähnliches - lassen sich sogar nur mit Hilfe dieser Protokolle herausfinden. Ausserdem lassen sich anhand der Logfiles potentielle Flaschenhälse erkennen, Serverfehler analysieren und die Nutzung der Website überwachen.

Im IIS ist die Einrichtung von Logfiles eine Sache von wenigen Mausklicks. Im Web Site-Fenster der Server-Eigenschaften aktivieren Sie die Checkbox vor Enable Logging und wählen das passende Log-Format aus; in den meisten Fällen wird dies das Microsoft IIS Log File Format oder das W3C Extended Log File Format sein. Im Properties-Dialog zu den Logdateien muss dann noch die Periodizität des Logs sowie der Pfad zum Logverzeichnis angegeben werden. IIS generiert danach automatisch eine Logdatei, die abhängig von der gewählten Periodizität mit dem Datum des betreffenden Tages, der Woche oder des Monats benannt wird. Wurde das W3C Extended Log File Format gewählt, ist darüber hinaus in einem zusätzlichen Dialogfenster eine genaue Auswahl der Informationen möglich, die in das Logfile geschrieben werden.

Etwas aufwendiger ist die Konfiguration der Logfiles mit Apache. Hier werden Dateiname oder Format der Logfiles über die vier Direktiven des Standardmoduls mod_log_config festgelegt. Die beiden wichtigsten Direktiven sind TransferLog und LogFormat. In ersterer werden der Dateiname und der Pfad definiert - möglich ist auch die Umleitung der Ausgabe auf ein externes Programm etwa zur Auswertung der Daten oder zum Einfüllen in eine Datenbank.

Die LogFormat-Direktive dagegen legt das Format des Logs fest. Diese Direktive bietet rund 20 Argumente, mit denen festgelegt wird, welche Informationen gespeichert werden sollen. Eine Übersicht über diese Formatanweisungen findet sich in der Apache-Dokumentation. Demselben Zweck dient die CustomLog-Direktive, die dieselben Konfigurationsargumente benutzt, aber mehr Flexibilität bietet. Die CookieLog-Direktive schliesslich dient nur noch der Rückwärtskompatibilität - sie wurde durch das Modul mod_usertrack ersetzt, das nun benutzt werden sollte, um das Verhalten eines Besuchers auf der Website zu protokollieren. Wichtig ist ausserdem das separat einzukompilierende Modul mod_log_agent, mit dessen Hilfe sich Informationen über den User-Agent (Browser, Robots) in einer separaten Log-Datei ablegen lassen.

TransferLog /var/log/httpd.access_log. LogFormat «%a %h %u %t» LogFormat «%{User-agent}i» 


 

Hier wird zunächst der Pfad zum Logfile definiert, in dem die Angaben zur IP-Adresse (a), zum Host (h), zur angeforderten URL (u), zur Zeit (t) sowie zum User-Agent abgelegt werden sollen. Damit Apache ebenfalls täglich (oder in einem beliebigen anderen Rhythmus) eine neue Logdatei anlegt (was standardmässig nicht der Fall ist), kommt das mit dem Server gelieferte Dienstprogramm rotatelog zum Einsatz. Dieses ist quasi eine Erweiterung zum Modul mod_log_config und wird über die Direktive TransferLog konfiguriert, und zwar nach folgendem Schema:

TransferLog «| /Pfad/Zu/Wechseldateien <Logfile> <Zeit in Sekunden>» TransferLog «| /var/log/daily /var/log/httpd. access_log 86400» 


 

Hier wird alle 24 Stunden (86400 Sekunden) ein neues Logfile ins Verzeichnis daily geschrieben. Sowohl Apache als auch IIS protokollieren Serverfehler in separaten Dateien. Beim Apache ist das ein File namens errorlog, beim IIS kommt das normale Systemlogfile zum Einsatz, das über den NT-EventViewer zugänglich ist.

Serverinfos und -status

So wichtig Logdateien für Informationen über den Gebrauch des Servers sind, so wenig sagen sie über den aktuellen Zustand desselben zu einem bestimmten Zeitpunkt aus. Diese Daten können jedoch problemlos vom Betriebssystem geliefert werden: Mit Windows NT und IIS ist dafür der Performance-Monitor zuständig, vergleichbare Tools für Apache unter Linux oder einem anderen Unix-Derivat gibt es sogar in mehrfacher Ausführung. Der Nachteil dieser Werkzeuge ist allerdings, dass sie nur lokal Informationen liefern - bei einem Server, der meist in einem speziellen Raum steht, ist das nicht unbedingt praktisch.

Sinnvoller ist es daher, wenn man übers Web auf die Status-Informationen zugreifen kann. Beim Apache-Server sind dafür die beiden Module mod_info und mod_status zuständig, die allerdings beide separat einkompiliert werden müssen. Ist das geschehen, muss man die Module noch aktivieren und so konfigurieren, dass nicht jedermann auf diese Daten zugreifen kann:

<Location /server-status> SetHandler server-status Order deny, allow Deny from all Allow from localhost </Location> 


 

In diesem Beispiel wird Server-Status so konfiguriert, dass vom lokalen Rechner über die URL http://servername/server-status auf diese Routine zugegriffen werden kann, während alle anderen Stationen ausgeschlossen werden. Geliefert wird eine Webseite mit Serverstatistiken. Analog funktioniert server-info: Sie müssen dazu bloss im obigen Beispiel und der URL server-status durch server-info ersetzen - ausgegeben wird dabei der Inhalt der Konfigurationsdatei httpd.conf. Um von anderen Rechnern auf diese Seiten zugreifen zu können, fügen Sie die entsprechenden IP-Adressen dem Eintrag Allow from hinzu.

Der Internet Information Server geht in seiner Remote-Administrierbarkeit einen Schritt weiter. Über ein Tool namens Internet Service Manager (HTML), das weitgehend den normalen Verwaltungswerkzeugen der Management-Console entspricht, ist die komplette Verwaltung einer Site per Webbrowser möglich.

Für die Überwachung des Servers und seiner Performance muss auch übers Netz der Performance-Monitor bemüht werden: Man wählt einfach im Datenquellen-Dialogfeld den entsprechenden Server aus, auf den darauf zugegriffen wird.


Copyright © 1998, 1999, 2000 by Compress Information Group, Thalwil. Alle Rechte vorbehalten.