Ein SNMP-Agent für das Management von UNIX-Workstations

    Zum heutigen Zeitpunkt muß trotz zahlreicher Bemühungen der Hersteller die Problemstellung, integriertes Management von UNIX-Workstations von einer Managementplattform aus sicherzustellen, noch immer als ungelöst betrachtet werden: Es existieren zwar Werkzeuge, die eine Vielzahl von Parametern eines Endsystems erfassen und mit Hilfe eines standardisierten Managementprotokolls an die Managementplattform weiterleiten [#!IBMSysMon94!#]; aktive Eingriffsmöglichkeiten durch den Administrator fehlen jedoch völlig. Andererseits existieren Produkte, die zwar Eingriffe zur Steuerung des Systems erlauben; die Kommunikation mit der Managementplattform geschieht jedoch lediglich auf der Grundlage eines herstellerspezifischen, d.h. proprietären Protokolls, dessen Schnittstellen nicht offengelegt sind [#!itocg97!#]. Zusätzlich sind beide Ansätze von einer Bottom-up-Vorgehensweise geprägt, die nur selten die tatsächlichen Bedürfnisse der Netzbetreiber berücksichtigt. Von einer umfassenden, integrierten Managementlösung kann daher zur Zeit noch nicht die Rede sein.

  

Abbildung: Eine MIB für das Management von UNIX-Workstations

Im Gegensatz zu kommerziell erhältlichen Werkzeugen wurde in bereits vor einiger Zeit am Lehrstuhl durchgeführten Arbeiten (beschrieben u.a. in [#!guts95!#], [#!krie94!#]) ein Top-down-Ansatz verfolgt, der das typische Aufgabenspektrum eines UNIX-Systemadministrators abdeckt: Es wurden Möglichkeiten für das Einrichten und Löschen von Benutzerkennungen und -gruppen sowie deren Quoten für den Zugriff auf Betriebsmittel (Plattenplatz, Druckseiten) ebenso vorgesehen, wie Funktionen zum Erfassen und ggfs. Stoppen der momentan aktiven Prozesse oder zum Mounten/Unmounten von Dateisystemen. Es ist somit nicht nur passives Monitoring von UNIX-Workstations möglich, sondern auch das aktive Eingreifen in den Betrieb des Systems. Als Managementprotokoll wird SNMP in der Version 2 verwendet.

Im Rahmen der vorgenannten Arbeiten wurde eine Systemmanagement-MIB  entwickelt und der dazugehörige Agent auf verschiedenen Betriebssystemplattformen (IBM AIX, HP-UX, SunOS, Solaris) implementiert. Die MIB ist in Abbildung schematisch dargestellt; sie umfaßt 195 MIB-Variablen und 15 Tabellen und stellt (unter anderem) ein Modell folgender Komponenten eines UNIX-Systems zur Verfügung:

• Speicher (Hauptspeicher, Swap-Bereich)
• Geräte (Prozessoren, Drucker, Platten und deren Dateisysteme usw.)
• Prozesse
• Benutzer (Kenndaten, Gruppen, Quoten usw.)

Im Falle der Benutzer- und Gruppenverwaltung tritt jedoch durch eine Einschränkung des Internet-Informationsmodells folgendes Problem auf: in der Regel sind auf einem UNIX-System mehrere Benutzer eingetragen, die ihrerseits wieder zu mehreren Gruppen gehören. Tabellen innerhalb von Tabellen sind jedoch explizit durch den entsprechenden Internet-Standard [#!RFC1902!#] untersagt. ,,Zu den Internet-Standards konforme`` Managementsysteme akzeptieren jedoch MIBs, die diese Anomalie aufweisen, klaglos.

Als sehr vorteilhaft für die Kapselung des SNMP-Agentencodes hat sich der modulare Aufbau des SNMP-Agenten erwiesen, bei dem auf eine strikte Trennung zwischen Protokoll-  und Ressourcen-Modulen  geachtet wurde. Als Intra-Agenten-Schnittstelle  wird das Distributed Protocol Interface (DPI)  [#!RFC1592!#] eingesetzt, der Vorgänger des in Abschnitt beschriebenen AgentX  Implementierungskonzepts, das die Kommunikation zwischen Master- und Subagenten spezifiziert. Der Zugriff auf die MIB-Variablen erfolgt jeweils über eine Prozedur. Dies bedeutet, daß jede MIB-Variable in einem eigenen Modul implementiert worden ist und über eine bzw. zwei Schnittstellen verfügt, je nachdem, ob auf die Variable nur lesend oder auch schreibend zugegriffen werden kann. Die ausschließlich lesbare MIB-Variable sysName wird durch Aufruf der Prozedur get_sysName() ermittelt; eine schreib- und lesbare Variable wie sysLocation wird durch die Prozeduren get_sysLocation() und set_sysLocation() implementiert. Insgesamt besteht der SNMP-Agent aus 195 get- und 150 set-Prozeduren. Der ursprüngliche Grund für diese Modularisierung lag in der besseren Erreichbarkeit von Plattformunabhängigkeit, da man zwischen Betriebssystem-spezifischen Systemaufrufen und Aufrufen, die für alle unterstützten Betriebssysteme identisch sind, besser unterscheiden konnte.