test

SunLink Server Administrationshandbuch

Fehlerbehebungsverfahren

Im Rahmen der SunLink Server-Fehlerbehebung werden Probleme systematisch isoliert. Dann werden detaillierte Daten gesammelt, um die Module zu identifizieren, die das Problem verursachen. Im folgenden finden Sie eine Reihe einfacher Verfahren zum Isolieren eines Server-Problems. Dann folgenden einige Hinweise zum Sammeln zusätzlicher Informationen zu dem Problem.

Isolieren des Problems

Das SunLink Server-Programm läuft auf einem Solaris-System-Computer. Der Server ist abhängig von einem voll funktionsfähigen NetBIOS-Netzwerk, um seine Datei- und Druck-Server-Funktionen ausführen zu können.

Ein NetBIOS-Netzwerk umfaßt in der Regel die folgenden Komponenten: eine Anwendung, die eine NetBIOS-Protokollschnittstelle zur Verfügung stellt, eine Anwendung, die eine Netzwerktransportprotokollschnittstelle zur Verfügung stellt (zum Beispiel TCP/IP, obwohl bei einigen Transportimplementierungen NetBIOS in einem gemeinsamen Modul enthalten ist), und eine Anwendung, die Treiber für die Netzwerkadapterschnittstelle zur Verfügung stellt (kann auch als Teil des Transportmoduls vorliegen).

Jede NetBIOS-Netzwerkkomponente muß konfiguriert und funktionsfähig sein, damit SunLink Server in einer Netzwerkumgebung funktionieren kann. Darüber hinaus müssen ähnliche Module auf der Maschine laufen, die versucht, die Datei- und Druckdienste des SunLink Server-Programms zu verwenden, zum Beispiel auf einem Windows NT Workstation-Computer oder einem Microsoft Windows-Client-Computer.

Wenn ein NetBIOS-Netzwerk nicht zur Verfügung steht, zeigt das System beim Server-Start in der Regel die folgende Meldung an:


unable to post servername on any network

Wenn man bedenkt, wie viele Module in einer Ende-zu-Ende-Verbindung zwischen einem Client und SunLink Server enthalten sind, dann ist leicht zu verstehen, daß die Isolierung eines Problem in einer Client-Server-Umgebung der erste Schritt zur Lösung dieses Problems ist.

Bevor Sie davon ausgehen, daß ein Problem vom Server verursacht wird, müssen Sie sicherstellen, daß die übrige Netzwerk-Software ordnungsgemäß funktioniert. Dies gilt insbesondere für neue Installationen, bei denen die Wahrscheinlichkeit eines Transport- oder physischen Netzwerkproblems am höchsten ist.

Es ist sinnlos, bei einem Problem, das nur einen einzelnen Client oder Benutzer betrifft, ausführliche Überprüfungen jeder Software-Schicht durchzuführen. Mit wachsender Erfahrung werden Sie ein Gespür dafür entwickeln, wann ein umfassendes und wann ein Server-spezifisches Problemisolierungsverfahren angebracht ist. In den folgenden Abschnitten finden Sie Richtlinien zur Durchführung beider Verfahren. Wenden Sie immer das Verfahren an, das am besten auf das aktuelle Problem paßt.

Überprüfen des Netzwerks

Bevor Sie davon ausgehen, daß immer der Server die Ursache aller Netzwerkprobleme ist, sollten Sie Überprüfungen durchführen, um die Funktionsfähigkeit des Netzwerks zu testen. Dies ist besonders dann wichtig, wenn alle oder sehr viele Server-Benutzer gleichzeitig Probleme melden.

Anhand der folgenden Schritte können Sie die Funktionsfähigkeit des Netzwerks testen.

Schritt 1: Überprüfen des Status des physischen Netzwerks

Zuerst sollten Sie das physische Netzwerk überprüfen. Der größte Teil der heutigen Netzwerk-Hardware ist mit Statusanzeigen ausgestattet, anhand derer Sie den Status der verschiedenen Netzwerkverbindungen erkennen können (10-BASE-T-Hubs verwenden zum Beispiel LEDs). Überprüfen Sie diese Verbindungen immer zunächst auf Probleme am physischen Netzwerk hin, zum Beispiel auf zu viele erneute Übertragungen, auf Unstimmigkeiten bei der Verbindungsintegrität und auf Jabber-Bedingungen.

Selbst in Fällen, in denen nur ein Client betroffen ist, sollten Sie nie die Möglichkeit einer fehlerhaften Kabelverbindung ausschließen. Bei einem einzigen betroffenen Client ist es am einfachsten zu überprüfen, ob das Problem immer auftritt, unabhängig davon, auf welchen Server der Client zuzugreifen versucht.

Wenn ein Client in einem Netzwerk, das in jeder anderen Hinsicht problemlos funktioniert, "nichts sehen kann", können Sie davon ausgehen, daß das Problem mit der Netzwerkkonfiguration dieses Clients zusammenhängt. Wenn ein solcher Client andere Knoten im Netzwerk sehen, jedoch keine Verbindung zu einem bestimmten Server herstellen kann, dann liegt die Ursache des Problems wahrscheinlich im Netzwerkpfad zum Server, im Server selbst oder in dem Konto, das dieser Client verwendet.

Es gibt eine Reihe von Produkten anderer Hersteller zum Überprüfen der physischen Funktionsfähigkeit eines Netzwerks. Es lohnt sich, mit einem solchen Gerät regelmäßig den Netzwerkverkehr zu überprüfen, um zu sehen, ob am physischen Netzwerk Probleme zu erkennen sind.

Schritt 2: Überprüfen des Transportprotokollstatus

Wenn an den physischen Netzwerkverbindungen kein Fehler zu finden ist, besteht der nächste Schritt darin zu überprüfen, ob die verschiedenen Computer im Netzwerk einander im Hinblick auf das Transportprotokoll "sehen" können. Die meisten Transportprotokollanwendungen umfassen ein Programm zum Testen der Konnektivität, mit dem die Verbindung zwischen Client und Server über das Netzwerk auf der Transportschicht überprüft werden kann.

Wenn Sie einen Server von einem bestimmten Client aus nicht mit dem Befehl ping erreichen können, dann kann auch dieser Client keine Verbindung zu dem Server herstellen. Wenn Sie einen Server mit dem Befehl ping von mehreren Client-Computern aus nicht erreichen können, dann liegt unter Umständen eine der folgenden Bedingungen vor: Der Server läuft nicht, das Transportprotokoll läuft nicht oder es gibt ein Konfigurationsproblem, das die Konnektivität im Netzwerk stört.

Schlagen Sie die Empfehlungen in der Software-Dokumentation zu Ihrem Transportprotokoll nach. Führen Sie dann gegebenenfalls die weiteren Verfahren in diesem Kapitel durch, nämlich die Überprüfung des Status des NetBIOS-Protokolls und der SunLink Server-Software.

Schritt 3: Überprüfen des NetBIOS-Protokollstatus

Überprüfen Sie die NetBIOS-Protokollschicht. Die meisten NetBIOS-Module enthalten Testprogramme zum Prüfen der Konnektivität zwischen NetBIOS-Namen im Netzwerk.

Wenn zwar die Konnektivität zwischen Knoten über TCP/IP gegeben ist, zwischen den NetBIOS-Namen jedoch nicht, dann funktioniert die SunLink Server-Software nicht. Die gesamte SunLink Server-Kommunikation basiert auf NetBIOS-Namenssitzungen. Überprüfen Sie mit dem Testprogramm, das zu Ihrer Protokoll-Software gehört, die Konnektivität in der NetBIOS-Schicht. Wenn Sie ein Problem finden, isolieren Sie es, wie in der Dokumentation zum NetBIOS-Protokoll beschrieben.

Schritt 4: Überprüfen der Funktionsfähigkeit des Solaris-Systems

Wenn an den Netzwerkkonnektivitätsmodulen keine Fehler zu finden sind, sollten Sie als nächstes die Solaris-Betriebsumgebung auf dem Computer überprüfen, auf dem das SunLink Server-Programm residiert. Das Betriebssystem enthält eine Reihe von Protokolldateien und Systemprüfungen, anhand derer Sie die Funktionsfähigkeit des Systems überprüfen können. Erläuterungen zu diesen Prüfungen finden Sie in der Administrationsdokumentation zum Solaris-System.

Die SunLink Server-Software ist besonders anfällig für folgende Systemprobleme:

Betriebssystemprobleme betreffen in der Regel alle oder die meisten Client-Computer, die an den Server angeschlossen sind. Wenn es sich also um einen Fehler an einem einzigen Client handelt, sollten Sie in diesen Schritt nicht zu viel Zeit investieren.

Schritt 5: Isolieren von Problemen am SunLink Server-System

Wenn Sie feststellen, daß die gesamte zugrunde liegende Software ordnungsgemäß funktioniert, müssen Sie das SunLink Server-System überprüfen. Die Problemisolierung an einem Server richtet sich oft nach dem Typ des Problems, das von den Benutzern gemeldet wird.

Betrifft ein Problem nur einen einzigen Benutzer, dann können Sie sich bei Ihren Überprüfungen auf die Funktionen konzentrieren, die dieser Benutzer ausführen möchte.

Wenn bei einer Gruppe von Benutzern Probleme auftreten, bei vielen anderen Benutzern jedoch nicht, dann sollten Sie versuchen herauszufinden, welche Gemeinsamkeiten zwischen den Benutzern in der betroffenen Gruppe bestehen. Beispiele:

Tritt bei allen Benutzern an einem Server ein Problem auf, dann sollten Sie mit einer Überprüfung des grundlegenden Server-Status beginnen. Die Fragen, die zu einer solchen Überprüfung gehören, sind im folgenden beschrieben.

Läuft der Server?

Es ist durchaus sinnvoll zu überprüfen, ob der Server läuft. Dies ist ganz einfach. Sie brauchen lediglich an der Systemeingabeaufforderung folgenden Befehl einzugeben:

ps -ef | grep lmx

Daraufhin sollte das System (mindestens) das folgende anzeigen:

root 3554 3452 Feb28 19:39 lmx.srv -s 1

root 3452 1 0 Feb28 5:03 lmx.ctrl

root 3568 1 0 Feb28 2:16 lmx.dmn

An dieser Anzeige können Sie sehen, daß die drei notwendigen Server-Prozesse tatsächlich laufen, nämlich der Dämon (lmx.dmn), der Steuerprozeß (lmx.ctrl) und mindestens ein Arbeitsprozeß (lmx.srv). Darüber hinaus können auch andere Prozesse angezeigt werden, zum Beispiel lmx.browser und lmx.alerter.

Mehrere weitere Arbeitsprozesse, alle mit einer eindeutigen Nummer am Ende der Zeile, können ebenfalls angezeigt werden. Der Server generiert je nach der Anzahl der Clients, die er unterstützt, neue Arbeitsprozesse. Wenn neue Client-Sitzungen gestartet werden, werden in der Regel auch neue lmx.srv-Prozesse gestartet, jeder mit einer eindeutigen Prozeß-ID und Nummer. Das ist normal.

Wenn der Server nicht läuft, geben Sie an der Eingabeaufforderung den Befehl net start server ein.

Laufen alle Server-Dienste?

Wenn einer der notwendigen Server-Prozesse nicht läuft, stellen Sie fest, ob alle Server-Dienste ordnungsgemäß gestartet wurden. Es sind Situationen denkbar, in denen mehrere Server-Prozesse laufen, der Server aber trotzdem nicht zur Verfügung steht, weil ein bestimmter Dienst nicht gestartet wurde. Dies gilt insbesondere für den Anmeldedienst. Mit dem folgenden Befehl, eingegeben an der Eingabeaufforderung, können Sie überprüfen, welche Dienste laufen:

net start

Das System zeigt eine Liste der Dienste an, die zu diesem Zeitpunkt auf dem Server aktiv sind.

Der Anmelde- und der Server-Dienst müssen unbedingt angezeigt werden. Andernfalls liegt am Server ein Problem vor. Oftmals startet der Anmeldedienst nicht, weil am Server-Namen, am Domänennamen oder an der Domänenkonfiguration ein Problem vorliegt.

Überprüfen Sie die Fehlerprotokolle auf Probleme, wie sie im folgenden beschrieben werden.

Enthalten die Fehlerprotokolle Meldungen?

Sehen Sie in den Fehlerprotokollen des Servers nach. Sie können das System-, Sicherheits- und Anwendungsprotokoll mit der Ereignisanzeige von einem Client-Computer aus, mit SunLink Server Manager vom SunLink Server-System aus oder mit dem Befehl elfread von der Systemkonsole aus anzeigen lassen. Auch die Protokolle im PRINTLOG-Freigabebereich können Sie anzeigen lassen, falls ein Problem im Zusammenhang mit dem Drucken vorliegt. Bei Problemen mit dem Server-Start können Sie im Protokoll lmxstart.log im Verzeichnis /var/opt/lanman/logs nachsehen.

Enthalten einige dieser Protokolle Einträge, speichern Sie sie zum späteren Gebrauch. Löschen oder überschreiben Sie Fehlermeldungen nicht, denn diese können auf die Ursache eines Problems hinweisen. Daher sollten Sie sie behalten, um sie gegebenenfalls später dem Unterstützungspersonal vorlegen zu können.

Folgende Meldung weist im besonderen auf ein Server-Problem hin:


A server process has unexpectedly terminated

Diese Meldung besagt, daß ein Server-Prozeß auf einen unerwarteten Fehler gestoßen ist. Je nach Konfiguration des Servers befindet sich auf Ihrem System unter Umständen eine Core-Datei.

Ist der Wert des Schlüsselworts CoreOk in der SunLink Server-Registrierung auf 1 (ja) gesetzt, befindet sich eine Core-Datei irgendwo auf dem System. Der Wert CoreOk befindet sich im folgenden Schlüssel:

SYSTEM\CurrentControlSet\Services\ AdvancedServer\ProcessParameters

Wechseln Sie ins Stammverzeichnis, und führen Sie folgenden Befehl aus, um das Dateisystem nach Core-Dateien zu durchsuchen:

find . -name "core*" -print

Speichern Sie alle Dateien, die Sie finden. Ist der Parameter coreok auf Nein gesetzt, werden keine Core-Dateien angelegt. Daher ist es unter Umständen sinnvoll, das Schlüsselwort CoreOk auf Ja zu setzen, damit Core-Dateien erfaßt werden, die bei der Fehlerbehebung nützlich sind.

Sind alle Server-Ressourcen ordnungsgemäß freigegeben?

Einige Server-Ressourcen werden automatisch jedesmal freigegeben, wenn der Server gestartet wird. Diese Ressourcen werden von Clients im Hintergrund verwendet, während sie andere Server-Aktivitäten ausführen.

Die Liste der standardmäßig freigegebenen Ressourcen umfaßt:

ADMIN$

C$

D$

IPC$

LIB

NETLOGON

PRINTLOG

PRINT$

USERS

Die Ressourcen mit einem Dollarzeichen ($) sind spezielle Ressourcen, die zur Server-Verwaltung und -Kommunikation erforderlich sind. Eine weitere spezielle Ressource -- REPL$ -- steht zur Verfügung, wenn der Verzeichnisreplikationsdienst läuft.

Versuchen Sie nicht, diese Ressourcen zu löschen oder erneut freizugeben. Wenn eine dieser Ressourcen fehlt, funktioniert der Server nicht ordnungsgemäß. Wenn Sie sehen, daß eine dieser Ressourcen fehlt, stoppen Sie den Server, und starten Sie ihn erneut, um festzustellen, ob diese Ressourcen beim Server-Start freigegeben werden. Wenn sie nicht angezeigt werden, wenden Sie sich an Ihren Kundendienst.

Die übrigen Ressourcen sind Standardressourcen, die in der Regel von Clients bei Anmelden (NETLOGON), zum Herstellen von Verbindungen zu Basisverzeichnissen (USERS) und für den Zugriff auf Dienstprogramme oder Fehlerprotokolle (DOSUTIL, OS2UTIL, PRINTLOG) verwendet werden. Diese Komponenten können auf Ihrem Server aus gutem Grund fehlen. Wenn Sie jedoch die Freigabe dieser Ressourcen nicht aufgehoben haben, wurden sie aufgrund eines Problems am Server entfernt.

Kann der Server von der Konsole aus angesprochen werden?

Es gibt einen einfachen Test, um festzustellen, ob der Server über das Netzwerk kommuniziert. Geben Sie dazu den folgenden Befehl an der Systemkonsole ein.

net view

Das System zeigt den Namen des Servers und anderer Server an, die in der gleichen Domäne in Betrieb sind. Wenn der Name Ihres Servers erscheint, führen Sie den gleichen Befehl nochmals aus, und zwar mit dem Server-Namen:

net view \\asutrial

Das System zeigt eine Liste der freigegebenen Ressourcen etwa wie die folgende an:

Shared resources at \\asutrial

SunLink Server Systems

Sharename Type Used as Comment

----------------------------------------------------------------

DOSUTIL Disk DOS Utilities

LIB Disk Programming Aids

NETLOGON Disk Logon Scripts Directory

OS2UTIL Disk OS/2 Utilities

PRINTLOG Disk LP Printer Messages

USERS Disk User Directory

Es können auch weitere Einträge angezeigt werden, wenn Sie freigegebene Ressourcen zu Ihrem Server hinzugefügt haben.

Wenn einer dieser Befehle permanent fehlschlägt, liegt ein Problem an der Broadcast-Kommunikation im Netzwerk vor. Sind die Befehle erfolgreich, können Sie mit den Tests im nächsten Abschnitt fortfahren.

Unterstützt der Server die Höchstzahl an Benutzern?

Wenn ein Konnektivitätsproblem auftritt, stellen Sie sicher, daß die Höchstzahl an Clients, für die der Server konfiguriert ist, nicht überschritten ist. Diese Höchstzahl ist im Parameter maxclients in der Datei lanman.ini des Servers definiert. Sie können sie mit dem Befehl srvconfig - g maxclients anzeigen lassen.

Wurde die SunLink Server-Registrierung beschädigt?

Führen Sie den Befehl regcheck -C aus, um festzustellen, ob das interne Format der Registrierungsdatei beschädigt wurde. Wenn dieser Befehl eine Beschädigung erkennt, führen Sie den Befehl regcheck -R aus, um die Registrierungsdatei zu reparieren.

Wenn in die SunLink Server-Registrierung ungültige Werte eingegeben wurden, können Sie mit dem Befehl regload durch eine Reinitialisierung alle Registrierungswerte auf ihre Standardwerte zurücksetzen.

Kann der Server von einem Client aus angesprochen werden?

Versuchen Sie, sich von einem Client-Computer aus am Server anzumelden. Ist die Anmeldung erfolgreich, verknüpfen Sie die ID eines virtuellen Laufwerks mit einer freigegebenen Ressource. Lassen Sie dann den Inhalt des verknüpften Laufwerks anzeigen.

Wenn bei diesen Schritten Probleme auftreten, isolieren Sie die einzelnen Probleme mit Hilfe des folgenden Verfahrens.

Fehlerbehebung an einer freigegebenen Ressource

Wenn Sie mit dem Server kommunizieren, aber nicht auf eine freigegebene Ressource zugreifen können, gehen Sie folgendermaßen vor:

  1. Überprüfen Sie, ob die freigegebene Ressource existiert. Geben Sie dazu den Befehl net view \\servername ein. Wenn der Name der freigegebenen Ressource nicht angezeigt wird, ist sie nicht vorhanden. In diesem Fall müssen Sie die Ressource erneut freigeben.

  2. Stellen Sie eine Verknüpfung zu der freigegebenen Ressource her, während Sie als Administrator angemeldet sind. Wenn dies fehlschlägt, die Ressource aber existiert, dann wurde die Ressource unter Umständen in fehlerhafter Weise freigegeben. Löschen Sie die Ressource, und geben Sie sie erneut frei. Wenn dies gelingt, fahren Sie mit dem nächsten Schritt fort.

  3. Handelt es sich um eine Festplattenressource, überprüfen Sie beide Berechtigungsstufen der freigegebenen Ressource. Überprüfen Sie zunächst mit dem Server-Manager die Freigabeberechtigungen. Überprüfen Sie dann die Berechtigungen für das freigegebene Verzeichnis mit Windows Explorer an einem Verwaltungs-Client.

    Überprüfen Sie, ob die Ressource verwendet werden kann, und zwar entweder mit der Gruppenmitgliedschaft oder auf der Basis des Kontos des betreffenden Benutzers. Überprüfen Sie auch, ob die Zugriffsberechtigungen auf die Ressource die gewünschte Aktion überhaupt gestatten. Es ist zum Beispiel denkbar, daß ein Benutzer nur eine Leseberechtigung hat, aber versucht, eine Datei zu bearbeiten. Überprüfen Sie ebenfalls, ob die maximale Benutzeranzahl für eine bestimmte freigegebene Ressource überschritten ist.

  4. Überprüfen Sie an der freigegebenen Ressource die Dateiattribute und die Zugriffsberechtigungen des Solaris-Systems.