In bester Bademeister-Tradition brauchen Admins einen guten Überblick über ihr Netzwerk, um eventuelle Fehlerquellen frühzeitig zu entschärfen. Dank SNMP kein Problem: Das Protokoll liefert gezielte Einblicke in jede SNMP-fähige Komponente und gibt ihr bei Bedarf auch Anweisungen.

MIBs einspielen

Die Erkundungsreise muss sich nicht auf den lokal laufenden SNMP-Agenten beschränken. Da recht häufig der Community-String unverändert »public« lautet, geben die Netzwerkgeräte der näheren Umgebung (Switches, Router) bereitwillig Auskunft. Somit taugt der SNMP-Dienst hervorragend zur Dokumentation eines Netzes, und zwar mit IP- und MAC-Adressen, Routing, Betriebssystemen, Patch-Ständen, installierten Applikationen und vielem mehr.

Interessante Informationen stecken in den herstellerspezifischen Zusatz-MIBs. Net-SNMP zeigt die Bedeutung der zusätzlichen OIDs, wenn die Software auf dem Managementsystem die MIB-Definition kennt. Mit deren Hilfe klappt auch die Übersetzung zwischen numerischen OIDs und deren Textform. Die Definitionsdateien sind auf den CDs zu finden, die zur verwalteten Hardware gehören, sowie auf den FTP-Servern der Hersteller oder im MIB-Depot [13]. Die Dateien enden auf ».txt«, ».mib« oder ».my«.

Tabelle 2 zeigt eine kleine Auswahl von Beispiel-OIDs. Alle (bis auf die von HP) befinden sich im ».enterprises«-Zweig. Der vollständige Pfad beginnt daher mit ».1.3.6.1.4.1«. Die Spalte "Bedeutung" wurde aus der Originalbeschreibung der MIBs übersetzt und glänzt gelegentlich mit ungewollter Komik.

Will ein Admin die MIB-Definition nicht systemweit in »/usr/share/snmp/mibs« hinterlegen (oder in »/usr/local/share/snmp/mibs«, je nach Installation), genügt es auch, sie in »~/.snmp/mibs/« zu kopieren. In beiden Fällen müssen die SNMP-Tools wissen, welche Zusatz-MIBs sie zu beachten haben. Das erfahren sie aus der Systemvariablen »MIBS«. Lautet ihr Inhalt auf »+Name«, dann beachten die Tools zusätzlich zu den Standard-MIBs die neu hinzugefügte. Deren Name steht am Anfang der MIB-Definitionsdatei vor »DEFINITIONS ::= BEGIN«. Da MIBs oft aufeinander aufbauen, ist es einfacher, alle auf einmal bekannt zu machen, »export MIBS=ALL« genügt.

Agent mit Sonderauftrag

Seine wahre Flexibilität zeigt SNMP, wenn Admins die Agenten um angepasste Funktionen ergänzen. Sie können dazu eigene MIBs entwickeln und den Agenten mit selbst programmiertem C-Code erweitern. In der Praxis ist das aber selten nötig, da Net-SNMP-Agenten bereits sehr leistungsfähig sind. Den kompletten Umfang der Konfigurationsmöglichkeiten verraten »man snmpd.conf« oder das Stöbern auf der Net-SNMP-Homepage [6].

Zum Beispiel kann Net-SNMP gezielt einzelne Prozesse überwachen. Die Beispielkonfiguration schlägt »mountd«, »ntalkd« und »sendmail« vor. Zusätzlich zum Namen erkennt der Agent auch, wie oft minimal und maximal dieser Prozess laufen soll:

proc sendmail 10 1

Diese Konfiguration in »/etc/snmpd.conf« legt fest, dass ein bis zehn Sendmail-Prozesse als Normalzustand gelten. Falls die Bedingung nicht zutrifft, setzt der Agent das entsprechende »prErrorFlag« und liefert den Fehlertext über »prErrMessage«. Bemerkt das Managementsystem einen Fehler, kann es über SNMP sogar erste Hilfe leisten: Die Konfiguration des Agenten enthält optional einen Befehl, der das Problem zu beseitigen versucht, etwa:

procfix sendmail /etc/init.d/sendmail restart

Schreibt der Manager den Wert »1« in das Agentenregister »prErrFix«, führt der Agent den Befehl aus. Im »snmpset«-Befehl ist die OID anzugeben, die zum überwachten Programm gehört: »prErrorFix.Nummer«. Danach folgen der Datentyp (hier »i« für Integer) und der gewünschte Wert:

snmpset -v1 -c private localhost prErrFix.1 i 1

Im Logfile sollte sich zeigen, ob Sendmail wirklich neu gestartet ist. Solche Aktionen vollautomatisch ausführen ist aber kritisch: Mehrfach hintereinander aufgerufen nimmt ihr Nutzen stark ab. Besser ist es, den Befehl manuell auszulösen oder das Managementsystem in mehreren Eskalationsstufen zu betreiben. Sinnvoll wäre: Zunächst den automatischen Fix versuchen und - wenn der Fehler in einer vorgegebenen Zeitspanne erneut auftritt - den Admin alarmieren.

In bester Bademeister-Tradition brauchen Admins einen guten Überblick über ihr Netzwerk, um eventuelle Fehlerquellen frühzeitig zu entschärfen. Dank SNMP kein Problem: Das Protokoll liefert gezielte Einblicke in jede SNMP-fähige Komponente und gibt ihr bei Bedarf auch Anweisungen.