Von: Ulrich Schmitz, Martin Schlöter
Wer die Arbeit am PC unter Windows sozusagen mit der Muttermilch eingesogen hat, wird als Server-Betriebssystem gern Windows NT einsetzen. Die Administration erfolgt hier in einer vertrauten Umgebung und mit bekannten Handgriffen. Allerdings findet die grafisch unterstützte Bequemlichkeit auch ihre Grenzen - spätestens dann, wenn es darum geht, einen NT-Server aus der Ferne zu warten.
Remote-Verwaltung unter NT
Eine grafische Benutzerschnittstelle (Graphical User Interface, GUI), wie etwa Windows NT sie bietet, sorgt für eine einheitliche Vorgehensweise bei den verschiedensten Aktionen am Rechner. Ob es um das Zuordnen von Benutzerrechten oder das Umbenennen einer Datei geht, die notwendigen Handgriffe ähneln einander und folgen immer den gleichen Mustern. In unmittelbarer Nähe seines NT-Servers genießt ein Administrator alle Vorzüge dieses einheitlichen Konzepts. Sobald er bei seiner Arbeit jedoch Entfernungen überbrücken muß, endet die Bequemlichkeit. Gerade Unix-Kundige sehnen sich dann nach den guten alten Kommandozeilen-Utilities, die über Netzwerkverbindungen einen nahezu beliebigen Remote-Betrieb erlauben.
Damit Microsofts Betriebssystem auch diesem Einsatzzweck gerecht wird, enthält das NT Resource Kit einen entsprechenden Satz von Tools, deren wichtigste wir hier vorstellen.
NT-Dienste auf entfernten Computern
Windows NT unterscheidet zwischen Anwendungen und Diensten. Letzteres sind Programme, die das System in der Startphase aufruft, auch ohne daß sich ein Benutzer angemeldet hat. Sie haben in der Regel keine Interaktion mit dem Desktop.
Für den Zweck, NT-Dienste auf entfernten Servern zu überwachen und zu steuern, hält das Windows NT Resource Kit das Programm Netsvc.exe bereit.
Die Syntax sieht folgendermaßen aus:
netsvc \\ [option]
Die verschiedenen Parameter für Netsvc haben folgende Bedeutung:
Dienstname bezeichnet den jeweils zu kontrollierenden Dienst. Der Name läßt sich hierbei entweder so angeben, wie er in der Registry des Servers definiert ist, oder in Form des Anzeigenamens, wie er in der Systemsteuerung unter Dienste erscheint. Wenn der Anzeigename Leerstellen enthält, muß er in Anführungszeichen "“" eingeschlossen werden.
\\Computername nennt den lokalen oder entfernten Rechner, auf dessen Dienste der Zugriff erfolgen soll.
Option kann die Werte /query, /start, /stop, /continue, /list oder /pause annehmen. Bei /list ist kein Dienstname erforderlich. Bei all diesen Optionen unterscheidet das System nach Groß- und Kleinschreibung. Anders als sonst bei NT üblich muß hier also peinlich genau auf die Schreibweise geachtet werden.
Unglücklicherweise liefert Netsvc keinen Errorlevel zurück, sondern gibt das Ergebnis der jeweiligen Aktion als Text auf dem Bildschirm aus. Das macht es schwierig, innerhalb von Batch-Dateien das Resultat zu testen, also festzustellen, ob der gewünschte Dienst gestartet oder gestoppt worden ist, oder ob er pausiert.
Folgende Batch-Datei überprüft den Status eines Dienstes und liefert eine Umgebungsvariable Errorlevel zurück:
et ERRORLEVEL=0
if “%1“==““ goto end
if “%2“==““ goto end
for /f “Tokens=1-4“ %%i in (‘netsvc %2 %1 /query’) do call
:test “%%k“
goto end
:test
if %1==“running“ set ERRORLEVEL=1&goto end
if %1==“stopped“ set ERRORLEVEL=2&goto end
if %1==“paused“ set ERRORLEVEL=3
:end
Die Syntax für den Aufruf von Svcstat.bat sieht dann so aus:
call svcstat \\
Der zurückgegebene Errorlevel ist wie folgt zu interpretieren:
l 0 = Computername oder Dienstname sind ungültig.
l 1 = Der Dienst ist gestartet.
l 2 = Der Dienst ist nicht gestartet.
l 3 = Der Dienst pausiert.
Folgender Beispielausschnitt aus einer Batch-Datei überprüft den Status des Zeitplandienstes auf dem lokalen Computer :
call SVCSTAT \\%Computername% Schedule
if %ERRORLEVEL% EQU 0 goto err
if %ERRORLEVEL% EQU 1 goto running
if %ERRORLEVEL% EQU 2 goto stopped
ELSE goto paused
NT: Undokumentiertes IF/ELSE
Sehr lästig bei der Entwicklung von Batch-Jobs ist das Fehlen eines Else-Zweigs bei Fallunterscheidungen. Das muß wohl auch den NT-Systementwicklern ein Dorn im Auge gewesen sein, so daß der Kommandointerpreter tatsächlich eine entsprechende Syntaxerweiterung bekommen hat. Allerdings ist diese nicht dokumentiert. Hier das Syntaxschema:
IF test ([True Command]) ELSE ([False Command])
Beispiel 1:
if “%UserStatus%“==“Helped“
(goto ThankYou) else (goto WhyNot)
Beispiel 2:
if not exist c:\boot.ini
(@echo don’t reboot) else (shutdown.exe)
Platzabfrage für Directories
Bei einem Serverbetriebssystem bieten sogenannte Quoten ("Quota") große Erleichterung für den Administrator, weil er damit den maximalen Plattenplatz für jeden Benutzer individuell begrenzen kann.
Bisher verfügt Windows NT allerdings noch über keine eingebaute Möglichkeit, die maximale Größe eines Verzeichnisses festzulegen, zum Beispiel für Benutzerverzeichnisse. Diese Quoten werden erst mit NT 5.0 eingeführt. Im Windows NT Resource Kit findet sich allerdings das Programm Diskuse, das den Speicherplatz einzelner Verzeichniseinheiten ausliest und damit zumindest eine Kontrollfunktion bietet. Bei der zu untersuchenden Einheit kann es sich um ein einzelnes Verzeichnis, einen Verzeichnisbaum oder ein komplettes Laufwerk handeln.
Diskuse gibt seine Ergebnisse wahlweise auf den Bildschirm oder in eine Text- beziehungsweise Tabellendatei aus. Zudem kann das Tool die Dateien der jeweiligen Verzeichniseinheit nach verschiedenen Kriterien filtern.
Die Aufrufsyntax ist einfach:
diskuse [Optionen]
Allerdings haben es die Optionen, die als Parameter angegeben werden können, in sich.
Wenn der Anwender beim Aufruf keinen Pfad genannt hat, nimmt Diskuse das aktuelle Verzeichnis an. Es läßt sich wahlweise ein absoluter, relativer oder UNC-Pfad angeben.
Sofern man beim Aufruf auf Optionen verzichtet, ignoriert das Programm Unterverzeichnisse und präsentiert seine Ausgabe im Standardformat. Mit Hilfe der Optionen läßt sich das Ergebnis sehr weitgehend beeinflussen, wie die abgedruckte Tabelle zeigt.
Das folgende Beispiel gibt die Syntax an, mit der sich ermitteln läßt, wieviel Speicherplatz jeder einzelne Benutzer auf Laufwerk C:\ belegt hat:
diskuse c:\ /s
Ein weiteres Beispiel: Diesmal soll die Aufgabe darin bestehen, die jeweils ersten fünf Dateien mit Größen von über 2 MByte für jeden einzelnen Benutzer zu erfassen. Anschließend soll das Ergebnis in der Datei c_drive.txt gespeichert werden. Die passende Aufrufsyntax dazu sieht so aus:
diskuse c:\ /s /v /n:5 /x:2000000 /f:c_drive.txt
Die folgende Variante zeigt alle Benutzer, die den in der Textdatei restrict.txt festgelegten Maximalspeicherplatz auf Laufwerk C: überschritten haben:
diskuse c:\ /s /v /o /r:restrict.txt
Das nächste Beispiel gibt den belegten Speicherplatz für den Benutzer "JSI\Jerry" auf Laufwerk C: an.
diskuse c:\ /s /u:JSI\Jerry
Als letztes soll ermittelt werden, wieviel Platz jeder Benutzer auf der Freigabe \\server\share belegt. Das Ergebnis soll im Tabellenformat in der Datei usage.csv gespeichert werden. Eine solche Datei läßt sich dann beispielsweise mit Excel weiterverarbeiten:
diskuse \\server\share /s /t /f:usage.csv
ASP-Debugging mit Monitor und Log-Files
Ein Webmaster ist im Regelfall gern darüber informiert, ob die von ihm betreuten Web-Sites auch fehlerfrei funktionieren. Während eine manuelle Überprüfung bei statischen HTML-Seiten noch leichtfällt, ist die Funktionskontrolle bei Active Server Pages (ASP) schon deutlich schwieriger. Weil diese von Benutzereingaben und Datenbank-Output abhängen, läßt sich ihre Arbeit kaum lückenlos abchecken, wenn alle realistischen Umstände berücksichtigt werden sollen.
Es könnte fast so aussehen, als müsse der Webmaster somit auf Problemmeldungen seitens der Web-Besucher warten. Ganz so schlimm ist die Lage jedoch nicht.
Ein kaum beachtetes Werkzeug, das im NT-Startmenü unter dem Stichwort Verwaltung ein Mauerblümchendasein fristet, ist der Systemmonitor. Er bietet die Möglichkeit, verschiedene Ereignisse und Zustände des Systems zu protokollieren. Mit seiner Hilfe werden auch Fehler in ASPs einer Verfolgung zugänglich. Wenn dann beim Abruf einer aktiven Seite irgendwelche Probleme auftreten, erfährt der Webmaster dies zuverlässig.
Im Regelfall braucht man aber auch die Information, in welcher ASP konkret welcher Fehler aufgetreten ist. Zu diesem Zweck hält der Microsoft Internet Information Server 4.0 (IIS 4) erweiterte Protokolloptionen bereit, die der Webmaster bei Bedarf aktiviert. Dazu wählt er im Internet-Dienstmanager als aktives Protokollformat für die Web-Site W3C-erweitert. Dort ruft der Button Eigenschaften den Dialog für die erweiterten Protokolleigenschaften auf. In diesem gilt es dann, bei den erweiterten Protokoll-Optionen die URI-Abfrage mit zu aktivieren.
Danach findet der Webmaster bei eventuellen Problemen mit ASPs ausführliche Angaben im Server-Log. Details wie beispielsweise ODBC-Fehlermeldungen sind mit im Log-File abgespeichert. Besonders bei stark frequentierten Servern kann sich die Suche nach Fehlermeldungen in den umfangreichen Logfiles des IIS problematisch gestalten. Benutzer der Version 4 haben dann eine sehr elegante Lösung, indem sie eine bislang undokumentierte Eigenschaft nutzen, die allerdings mit NT 5.0 und dem IIS 5.0 offiziellen Status bekommen wird.
Das Betriebssystem-Event-Log des Servers kann Fehlermeldungen des ASP-Systems speichern. Die Ereignisanzeige (Event Viewer) erlaubt dann einen Blick auf die betreffenden Einträge.Dazu ist lediglich in der Registry des Servers unter dem Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\ASP\Parameters
die Variable ErrorsToNtLog mit einem Wert von 1 einzutragen. So gewinnt der Webmaster eine sehr effektive Möglichkeit, Probleme mit ASP-basierten Server-Inhalten zu lokalisieren.
Cookie-Sharing für Sub-Domains
Web-Sites senden für verschiedene Zwecke Cookies an den Browser des jeweiligen Besuchers. Ein beliebter Einsatzzweck besteht darin, eine Benutzer-ID zu hinterlegen, damit der Server den betreffenden Anwender beim nächsten Besuch wiedererkennen und dann beispielsweise mit einer personalisierten Begrüßung erfreuen kann. Innerhalb einer ASP sendet der Server dann etwa mit einer Code-Sequenz wie
<%
Response.Cookies(“UID“) = 42
Response.Cookies(“UID“).Expires = “1/1/2000“
%>
einen permanenten Cookie mit einer angegebenen Lebensdauer bis zum 1.1.2000 zum Client.
Das solchermaßen ausgelagerte "Notizblatt" kann später wieder abgerufen werden. Ein Problem kann allerdings dann entstehen, wenn mehrere Domänen beim selben Informationsanbieter betrieben werden. Zum Beispiel:
www.hanfdunk.de www2.hanfdunk.de secure.hanfdunk.de
Der Definition nach kann erst einmal nur diejenige Domain einen Cookie wieder beim Client abholen, die ihn ursprünglich auch dorthin geschickt hat. Diese Regel macht aus Sicherheitsgründen durchaus Sinn: So kann nicht jeder Server beliebige Cookie-Informationen, die bei einem Client liegen, ausspähen und sich so fremde Daten aneignen. Für Strukturen, die in Sub-Domains organisiert sind, ist das aber eher hinderlich. In unserem Beispiel müßte sich ein Anwender bei allen drei Domänen separat registrieren lassen, um Zugang zu geschlossenen Benutzergruppen der "Hanfdunk"-Site zu bekommen. Für Sub-Domains, die solchermaßen von einer gemeinsamen Basisdomäne abgeleitet sind, bietet ein Eingriff im Code zum Versenden des Cookies eine Lösung: Die veränderte Fassung bringt den Client-Browser dazu, an alle von der Basisdomäne abgeleiteten Sub-Domains auf Anfrage den Cookie zurückzuliefern:
<%
Response.Cookies(„UID“) = 42
Response.Cookies(„UID“).Domain = “.hanfdunk.de“
Response.Cookies(„UID“).Expires = “1/1/2000“
%>
Wichtig ist der führende Punkt "." bei der Domänenangabe, weil laut RFC 2109 zwei Punkte in Domänennamen zwingend sind.
Schwieriger wird die Geschichte, wenn tatsächlich separate Domänen vorliegen. In einem solchen Fall sind direkte Kommunikationsmethoden zwischen den Servern zu schaffen, damit diese ihre Cookie-Informationen untereinander austauschen können. So lassen sich entsprechende Daten beispielsweise mit Hilfe der Redirect-Funktion über ASPs weitergeben, die auf den gewünschten Servern liegen.
ASP-Option "Explicit"
Die Deklaration von Variablen gilt von jeher als guter Stil in der Programmierung. Weil aber insbesondere VB-Script keinen Deklarationszwang für Variablen kennt, vernachlässigen viele Entwickler diese Tugend bei der Arbeit an ASPs.
Die Strafe folgt meist auf dem Fuße, weil bereits der kleinste Tippfehler in einem Variablennamen dazu führt, daß das entsprechende Script mit nicht initialisierten Variablen arbeitet. Der Unterschied zwischen den Variablennamen Angel und Angle geht im Eifer des Gefechts leicht unter. Die Option Explicit im Kopf eines ASP-Quelldokuments veranlaßt die Scripting-Engine, zu prüfen, ob Variablen vor ihrer Verwendung deklariert worden sind. So vermeidet man zuverlässig, daß unbemerkte Tippfehler bei der Verwendung von Variablen für Chaos sorgen.
ASP-Caching bei Proxies
In der Regel übernehmen Proxy-Server das Ergebnis von ASP-Abrufen nicht in ihre Zwischenspeicher. Dieses Verhalten ist normalerweise auch sinnvoll: Die aktiven servergenerierten Seiten zeichnen sich ja vom Konzept her durch dynamisches Verhalten aus und können somit laufender Veränderung unterworfen sein. Sie eignen sich dann kaum dazu, im Proxy konserviert zu werden. Deswegen sendet der IIS defaultmäßig im Seitenheader das Statement
Cache-Control: Private
Dieses führt dazu, daß ein Proxy diese Seite nicht zwischenspeichert. Generell wirkt sich der beschriebene Mechanismus allerdings auch nachteilig auf die Gesamtperformance im Internet aus. Viele ASPs erscheinen nämlich in der Praxis alles andere als dynamisch; das Ergebnis der Abrufe verändert sich eher selten. Das hängt beispielsweise damit zusammen, daß viele ASPs auf Datenbankinhalten basieren. Diese bleiben oft weitgehend unverändert.
Microsofts IIS bietet ab Version 4 eine Möglichkeit, das Proxy-Verhalten bei ASPs von Fall zu Fall zu kontrollieren. Mit
<%
Response.CacheControl = Public
%>
können Entwickler dafür sorgen, daß der Proxy entsprechend den Expires-Einstellungen das Caching der betreffenden Seite übernimmt, so daß Netzwerkteilnehmer und Internet-User von der Pufferung profitieren können.
ASP: Datenbankleistung verbessern
Der ODBC-Standard (ODBC = Open Database Connectivity), der ja auch von ASPs für den Datenbankzugriff verwendet wird, bietet seit der Version 3.0 eine Option namens Connection Pooling an. Diese kann die Performance bei Datenbankzugriffen deutlich verbessern.
Dabei bewahrt der Server die Ergebnisse von Datenbankzugriffen der Clients auf, um sie bei nachfolgenden erneuten Anforderungen wiederverwenden zu können.
Bei ASPs ist diese Option leider standardmäßig ausgeschaltet. Wer jedoch den Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ServicesW3SVC\ASP\Parameters\StartConnectionPool
in der NT-Registry auf den Wert 1 setzt, aktiviert dadurch das Connection Pooling beim nächsten Start des IIS.
Bildschirmauflösung des Clients
Wer die Seiten einer Web-Site gestalten möchte, muß dabei gelegentlich bestimmte Bildschirmauflösungen durch maßgeschneiderte Layouts berücksichtigen. Wenn die verfügbare Auflösung beim Client bekannt ist, kann der Web-Entwickler gezielt darauf reagieren und etwa durch eine ASP ein Bildschirmlayout erzeugen, das mit der konkreten Auflösung besser klarkommt als das berüchtigte Kompromiß-Design der Marke
Eine Codesequenz nach dem Schema
<%
response.write(request.servervariables(“http_ua_pixels“))
%>
holt die aktuelle Auflösung vom Browser. Leider spielen einige Versionen des Netscape-Clients dabei nicht mit. Wir empfehlen deswegen, zusätzlich manuelle Umschaltmöglichkeiten einzuplanen. (sz)