David Guerrero M@ail an den Autor Inhalt Einleitung Was ist SNMP? Sicherheitsaspekte Was ist MIB? Wie sieht die Zukunft von SNMP aus? SNMP unter Linux MRTG: Multi Router Traffic Grapher Andere Programme Schlußfolgerungen Literaturverweise

Netzwerkmanagement und Überwachung mit Linux

Zusammenfassung:
Der Autor beschreibt in diesem Artikel Aspekte der Netzwerkverwaltung und stellt Dienste und Software für das Management und die Überwachung von Netzen vor.
(Dieser Artikel erschien im Linux Journal und wurde, mit der Einwilligung des Autors, nochmals veröffentlicht und übersetzt)

Einleitung

Heutzutage spielen Netzwerke eine wichtige Rolle, nimmt die Arbeit für die Systemadministratoren immer weiter zu. Diese sind verantwortlich für die Verfügbarkeit von Resourcen, wie etwa Routern, Hubs, Servern und vielen kritischen Geräten in einem Netzwerk.

Es gibt viele Gründe für die Überwachung von Netzwerkeinheiten, sei es die Auslastung der Bandbreite, der operationelle Zustand einer Verbindung, Engpässe, Probleme mit der Verkabelung oder dem Informationsaustausch zwischen Geräten, uvm. Auch für das Aufspüren von Sicherheitsproblemen und Mißbrauch dient das sogenannte Monitoring als guter Ansatzpunkt.

Vielfach ist ein lokales Netzwerk einer Organisation über eine teure Verbindung zu anderen Netzen (WAN) oder dem Internet verbunden, deren Kosten abhängig vom Datenvolumen sein können. Es ist dann ausgesprochen wichtig, Statistiken über den Verkehr, der über diese Verbindung geht, zu führen. In Europa, wo X.25 Verbindungen noch recht verbreitet sind, ist dies eine häufig auftretende Aufgabe. Die Kosten für diese Verbindungen werden auf Basis der empfangenen und gesendeten Pakete abgerechnet.

Andere Verbindungsarten, wie Point to Point oder Frame Relay, werden normalerweise über die Bandbreite abgerechnet, die vom Provider gewährleistet wird. In diesem Fall ist es halt wichtig, diese auch zu überwachen.

Im letzten Teil dieses Artikels wird detailierter auf ein Werkzeug eingegangen, welches für die Verkehrsüberwachung eines Routers und seinen Ports entwickelt wurde. Dieses Programm bietet eine hervoragende grafische Aufbereitung der Daten und kann auch recht einfach für das Monitoring anderer Informationen modifiziert werden.

Was ist SNMP?

Die oben genannten Bedürfnissse werden durch das Simple Network Management Protocol (SNMP) erfüllt. In den 80er Jahren entwickelt, wurde es für die einheitliche Verwaltung verschiedener Netzwerktypen etnwickelt. Dabei sollte ein einfaches Design zum Tragen kommen, welches wenig Auswirkungen auf das Netz haben sollte.

SNMP operiert auf der Anwendungsebene, unter Einsatz von TCP/IP Transport Protokollen, so daß es unabhängig von der zugrundeliegenden Netzwerk-Hardware arbeitet. Die Managementsoftware verwendet IP, wodurch Netwerkeinheiten in jedem verbundenen Netzwerk (und nicht nur in den physikalisch verbundenen Netzen) kontrolliert werden können. Ein Nachteil liegt natürlich darin, daß bei inkorrektem IP Routing zwischen zwei Geräten, das Zielgerät nicht mehr überwacht oder rekonfiguriert werden kann.

Das SNMP Design basiert auf zwei Komponenten: dem Agenten und dem Manager. SNMP ist eine Client-Server Architektur, in der der Agent den Server und der Manager den Client repräsentieren.

Der Agent ist ein Programm, welches auf jedem überwachten oder verwalteten Netzwerkelement läuft. Er verfügt über eine Schnittstelle, welche Zugriff auf alle Elemente der Gerätekonfiguration bietet. Diese Elemente werden in einer Datenstruktur verwaltet, die sich Management Information Base (MIB) nennt. Diese wird später erläutert. Dies ist die Serverseite, solange hier die verwalteten Informationen gepflegt und Befehle vom Client erwartet werden.

Die Managersoftware läuft auf der Überwachungsstation des Netzwerkes. Ihre Aufgabe ist es, die verschiedenen aktiven Agenten im Netzwerk zu kontaktieren und die Werte der internen Daten zu erfragen. Dies ist die Clientseite der Kommunikation.

Im SNMP Befehlssatz gibt es ein spezielles Kommando namens trap, welches dem Agenten erlaubt, auch unaufgefordert Daten an den Manager zu senden. Dadurch wird dieser über Ereignisse, wie Fehler, das Herunterfahren des Gerätes, uvm. informiert.

Prinzipiell ist SNMP ein recht einfaches Protokoll, solange alle Operationen auf Basis des Prinzipes von Anfrage und Speicherung beruhen. Dadurch wird nur ein recht geringer Befehlssatz benötigt. Der Manager kann nur zwei verschiedene Operationen ausführen: Den Wert einer MIB Variable des Agenten erfragen (Get-Request) oder ihn setzen (Set-Request). Es gibt ein Kommando, welches als Antwort auf einen Get-Request gedacht ist (Get-Response) und nur vom Agenten verwendet wird.

Die Erweiterbarkeit des Protokolles hängt direkt mit der Fähigkeit der MIB zusammen, neue Elemente verwalten zu können. Möchte ein Hersteller etwa neue Befehle einem Gerät, etwa einem Router, beibringen, so muß er die entsprechenden Variablen dessen Datenbestand (MIB) hinzufügen.

Beinahe alle Hersteller verwenden Versionen von SNMP Agenten in ihren Geräten, etwa Routern und Hubs, aber auch in Betriebssystemen, uvm. Linux macht da keine Ausnahme, frei verfügbare SNMP Agenten für Linux können im Internet gefunden werden.

Sicherheitsaspekte

SNMP bietet kaum Unterstützung von Authentifizierungsmaßnahmen. Es kennt nur das zwei-Passwort System. Das public Passwort erlaubt Managern, die Werte von Variablen zu erfragen, während das private Passwort das Setzen dieser Werte ermöglicht. Diese Passworte werden Communities genannt, jede Einheit, die an ein SNMP verwaltetes Netzwerk angebunden ist, muß diese beiden Communities konfiguriert haben.

Sehr häufig sind die beiden Communities auf "public" und "private" gesetzt, es ist allerdings recht wichtig, diese Werte zu ändern, um dem Sicherheitsaspekt auch Rechnung zu tragen.

Was ist MIB?

SNMP definiert einen separaten Standard für die Daten, die von dem Protokoll verwaltet werden. Dieser Standard erklärt die verwalteten Daten einer Netzeinheit und welche Operationen auf ihnen erlaubt sind. Die Daten werden durch einen Baumstruktur repräsentiert, zu jeder Variable gibt es einen eindeutigen Pfad. Diese Baumstruktur heißt halt Management Information Base (MIB) und wird in verschiedenen RFCs dokumentiert.

Die gegenwärtige Version von TCP/IP MIB ist MIB-II und wird in RFC-1213 definiert. Hier werden die zu verwalteten Informationen einer TCP/IP Einheit in acht Kategorien unterteilt (in Tabelle 1 dargestellt), jede Variable dieser Informationen muß unter eine dieser Kategorien fallen.

Die MIB Definition eines bestimmten Eintrages legt auch den erlaubten Datentyp für die Werte fest, die gespeichert werden können. Normalerweise enthalten MIB Elemente einzelne Integer Werte, es können aber ebensogut Zeichenketten oder komplexere Strukturen, wie etwa Tabellen, sein. Elemente einer MIB werden als Objekte bezeichnet. Objekte sind die Blattelemente des MIB Baumes, allerdings kann ein Objekt mehr als eine Instanz beinhalten, wie eben zum Beispiel ein Tabellenobjekt. Um auf einen Wert in einem Objekt zugreifen zu können, muß der Index der Instanz angegeben werden. Existiert nur eine Instanz in einem Objekt, so ist dies die Instanz 0.

Das Objekt ifNumber der Kategorie "interfaces" zum Beispiel beinhaltet einen Integer Wert, welcher die Zahl der verfügbaren Netzwerkschnittstellen des Gerätes darstellt, während das Objekt ipRountingTable der Kategorie "ip" hingegen die Routingtabelle des Gerätes enthält.

Man muß immer daran denken, die Nummer der Instanz des Objektes anzugeben, deren Wert erfragt werden soll. In diesem Fall kann die Zahl der Netzwerkschnittstellen eines Routers über die Instanz ifNumber.0 ermittelt werden.

Im Fall des Tabellenobjektes muß der Index der Tabelle als letzte Nummer angegeben werden, um eine bestimmte Instanz (Zeile der Tabelle) anzudeuten.

Es gibt noch einen weiteren Standard, über den MIB Variablen definiert und identifiziert werden, der sogenannten Structure of Management Information (SMI). SMI spezifizierte MIB Variablen müssen in einer formalen Sprache, genannt ASN.1 (ISO), deklariert werden, durch welche die Form und Inhalt dieser Variablen eindeutig sind.

Der ISO Namensraum befindet sich in einem globalen Namensraum mit den anderen Bämen für andere Standarisierungs-Organisationen. Innerhalb des ISO Namensraumes ist eine spezieller Baum für die MIB Information. Innerhalb des MIB Teilbaumes sind dann Bereiche für die Objekte aller Protokolle und Applikationen, sodaß ihre Informationen eindeutig repräsentiert sind.

Abbildung 1 zeigt, daß der TCP/IP Namensraum direkt unterhalb des MGMT Namensraumes der IAB lokalisiert ist. Die Hierarchie legt auch eine Nummer für jede Ebene fest.

Abbildung 1: TCP/IP Organisationsbaum

Wichtig zu wissen ist, daß der Großteil der Software den führenden Punkt (Wurzel) benötigt, um ein Objekt in der MIB zu lokalisieren. Sollte der Punkt fehlen, so wird ein relativer Pfad von .iso.org.dod.internet.mgmt.mib-2. aus angenommen.

Auf diese Art und Weise wird das Objekt ifNumber der Kategorie "interface" wie folgt angesprochen:

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber

.1.3.6.1.2.1.2.1

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber.0

.1.3.6.1.2.1.2.1.0

Weitere MIBs können zu diesem Baum hinzugefügt werden, falls die Hersteller sie erzeugen und die passenden RFCs veröffentlichen.

Wie sieht die Zukunft von SNMP aus?

Eine neue Spezifikation, SNMPv2 genannt, wird gerade entwickelt. Behoben werden sollen die Sicherheitsprobleme, die das aktuelle Protokoll besitzt, mittels Mechanismen, die sich auf Privacy, Authentifizierung und Zugriffskontrolle konzentrieren. Desweiteren erlaubt das neue Protokoll die komplexere Spezifikation von Variablen und bietet zusätzliche Kommandos. Hauptproblem von SNMPv2 ist die (noch) fehlende Akzeptanz des Standards, im Gegensatz zu SNMPv1. Es ist recht schwer, SNMPv2 Versionen von Software und Agenten zu finden und so die neuen Befehle nutzen zu können. Mal sehen, was die Zukunft bringt...

SNMP unter Linux

Eine der am häufigsten verwendeten SNMP Distributionen ist CMU-SNMP. Ursprünglich an der Carnegie Mellon University entwickelt, wurde es von Jürgen Schönwälder und Erik Schönfelder nach Linux portiert. Es ist SNMPv1 konform, bietet aber darüber hinaus noch einiges an neuer Funktionalität von SNMPv2.

In dem Softwarepaket enthalten sind einige Management-Werkzeuge, die es im Kommandozeilen Stil erlauben, Anfragen (Requests) an Geräte zu senden, auf denen SNMP Agenten laufen. Desweiteren beinhaltet die Software einen SNMP Agenten, welcher unter Linux arbeitet und eventuellen Managern im Netzwerk (oder auf dem gleichen System) Informationen über den Zustand der Netzwerkschnittstellen, die Routing Tabelle, die Systemlaufzeit, Kontaktadressen, uvm. zu Verfügung stellen kann.

Einen wertvollen Zusatz stellt die SNMP C-API (Programmierbibliothek) dar, die mit CMU-SNMP mitkommt. Diese erlaubt dem Programmierer, komplexere Management-Werkzeuge zu schreiben, basierend auf den Netzwerkfähigkeiten der Distribution.

Die Installation unter Linux ist recht einfach, weicht aber ein wenig von der der originalen CMU Distribution ab. Mit dabei sind vorkompilierte Versionen der Manager-Werkzeuge, des Daemons und der Bibliothek.

Zuerst sollte man sich zwischen der vorkompilierten Version oder dem Quelltext entscheiden. Es ist einfach, die Software im Netz zu finden (am Ende des Artikels findet man einen Verweis). Die vorkompilierten Programme laufen einwandfrei unter dem 2.0 Kernel und sind ELF basiert. Im folgenden wird die Installation der Binär-Distribution erläutert. Es wird empfohlen, die Programme nur von vertrauenswürdigen Servern (trusted sites) zu beziehen, da so das Risiko von Viren, Trojanern und anderen potentiellen Sicherheitsproblemen reduziert wird.

Die Datei cmu-snmp-linux-3.2-bin.tar.gz wird nach dem Download in das Wurzelverzeichnis (/) des Linuxsystemes kopiert und dort mit dem folgenden Kommando dekomprimiert:

gunzip cmu-snmp-linux-3.2-bin.tar.gz

Danach wird die Distribution mittels dem nächsten Befehl entpackt (die Verzeichnisse und Dateien erstellt):

tar xvf cmu-snmp-linux-3.2-bin.tar

Nun sind alle Programme und Bibliotheken korrekt auf dem System installiert, bis auf die Konfigurationsdatei des SNMP Agenten /etc/snmpd.conf. Diese kann mittels des Aufrufes des folgenden Skript erstellt werden:

/tmp/cmu-snmp-linux-3.2/etc/installconf

mit diesen Optionen:

/tmp/cmu-snmp-linux-3.2/etc/installconf -mini <password>

wobei password die public Community ist, die verwendet werden soll. Als nächstes kann die soeben installierte Konfigurationsdatei /etc/snmpd.conf bearbeitet werden. In ihr können die Werte des vom Agenten verwendeten UDP Portes, die Variablen systemContact, systemLocation und systemName gesetzt und die Geschwindigkeitswerte für die Netzwerkschnittstellen (LAN und/oder PPP) eingetragen werden.

Die wichtigsten Management-Werkzeuge sind:

• /usr/bin/snmpget Ein Programm, mit dem einzelne Werte einer MIB eines Agenten im Netz (auf einem Router, Hub, usw.) erfragt werden können
• /usr/bin/snmpgetnext Holt das nächste Objekt eines MIB Baumes, ohne dessen Namen zu kennen.
• /usr/bin/snmpset Programm, mit dem Werte eines Agenten gesetzt werden.
• /usr/bin/snmpwalk Werkzeug, welches ein komplettes Objekt oder eine Serie von Objekten erfragt, ohne die exakte Instanz zu spezifizieren. Recht brauchbar, wenn Tabellenobjekte betrachtet werden sollen.
• /usr/bin/snmpnetstat
• /usr/bin/snmptrapd Daemon, der auf traps wartet, die von Agenten gesendet werden.
• /usr/bin/snmptest Interaktives Werkzeug, welches die Fähigkeiten der API demonstriert.

Der Agent ist unter /usr/sbin/snmpd zu finden.

CMU-SNMP installiert desweiteren eine MIB Datei unter /usr/lib/mib.txt . Sie ist eine gute Referenz für die Suche nach Informationen, die von einem Gerät erfragt werden können.

Der SNMP Agent muß nach dem Booten gestartet werden, und kann mittels dem folgenden Kommando in einem der Startdateien des Systemes (z.B. /etc/rc.d/rc.local oder /sbin/init.d/boot.local) hochgefahren werden:

/usr/sbin/snmpd -f ; echo 'starting snmpd'

Wurde der Agent auf dem Linuxrechner gestartet, so können die Management-Werkzeuge getestet werden, zum Beispiel:

/usr/bin/snmpget -v 1 localhost public interfaces.ifNumber.0

wodurch die Anzahl der konfigurierten Netzwerkschnittstellen im System zurückgeliefert wird, oder:

/usr/bin/snmpwalk -v 1 localhost public system

was alle Werte des MIB Teilbaum des Systemes zurückgibt (in Abbildung 2 wird die Ausgabe des Kommandos dargestellt).

dragon:~$ /usr/bin/snmpwalk

usage: snmpwalk [-p ] host community [object-id]

dragon:~$ /usr/bin/snmpwalk  localhost public system

system.sysDescr.0 = "Linux version 2.0.24 (root@dragon) 
                     (gcc version 2.7.2) #6 Mon Nov 25 15:08:40 MET 1996"
system.sysObjectID.0 = OID: enterprises.tubs.ibr.linuxMIB
system.sysUpTime.0 = Timeticks: (39748002) 4 days, 14:24:40
system.sysContact.0 = "David Guerrero"
system.sysName.0 = "dragon "
system.sysLocation.0 = "Madrid (SPAIN)"
system.sysServices.0 = 72
system.sysORLastChange.0 = Timeticks: (39748006) 4 days, 14:24:40
system.sysORTable.sysOREntry.sysORID.1 = OID: enterprises.tubs.ibr.linuxMIB.linuxAgents.1
system.sysORTable.sysOREntry.sysORDescr.1 = "LINUX agent"
system.sysORTable.sysOREntry.sysORUpTime.1 = Timeticks: (39748007) 4 days, 14:24:40
dragon:~$

Die C-Bibliothek ist unter /lib/libsnmp.so.3.1 zu finden.

Die dazugehörigen Headerdateien sind:

weitere Informationen sind in den Manual-Pages snmp_api(3) und variables(5) zu finden.

Es gibt noch ein Erweiterungsmodul für Perl, welches die Nutzung der CMU C API ermöglicht, wodurch die Aufrufe der Bibliothek einfach in Perl Skripte integriert werden können.

MRTG: Multi Router Traffic Grapher

MRTG ist ein recht forschrittliches Werkzeug, geschrieben von Tobias Ötiker und Dave Rand. Es bereitet die Daten, die von den SNMP Agenten an die SNMP Manager geschickt werden, grafisch auf und erzeugt hübsche HTML Seiten mit GIF Grafiken, über den eintreffenden und ausgehenden Netzwerkverkehr, beinahe in Echtzeit. Dadurch wird von der direkten Arbeit auf den MIB Objekten abstrahiert, wie es etwa die Werkzeuge des CMU-SNMP machen. MRTG ist das einfachste und leistungsfähigste Werkzeug für die Überwachung meiner Router, das ich im Netz finden konnte.

MRTG verwendet eine SNMP Implementierung, die komplett in Perl realisiert wurde, so daß keine weiteren Pakete installiert werden müssen. Das Hauptprogramm wurde in C geschrieben, um den Log-Prozeß und die Erzeugung der GIF Bilder zu beschleunigen. Die Grafiken werden mit Hilfe der GD Bibliothek erzeugt, welche von Thomas Boutell entwickelt worden ist.

Einer der Vorzüge von MRTG ist seine Erweiterbarkeit und die mächtige Konfigurierbarkeit. Es ist sehr einfach, irgendweine SNMP Variable anstelle des Netzverkehres zu beobachten, wie zum Beispiel fehlerhafte Pakete, die Systemlast, die Verfügbarkeit eines Modems, uvm. Es ist sogar möglich, Daten von anderen Programmen zu importieren, wodurch etwa das Einloggen und andere Dinge, die nicht mittels SNMP betrachtet werden können, beobachtbar werden.

Mit dem Programm kommen einige Werkzeuge für die Überwachung der Schnittstellen eines Routers, die Ermittlung ihrer Charakteristika und die Erzeugung einer minimalen Konfigurationsdatei mit. Diese Datei kann recht einfach für die jeweiligen Bedürfnisse angepaßt werden.

Ein weiteres interessantes Merkmal von MRTG ist die erzeugte Datenmenge. Es kann für jede Schnittstelle zwischen vier Detailstufen ausgesucht werden: der Verkehr der letzten 24 Stunden, der letzten Woche, des letzten Monates oder eine Jahresgrafik. Dadurch kann man effektiv Informationen für statistische Zwecke erhalten. Das Programm verwaltet eine wachsende Datenbank über all diese Informationen, wobei ein Algorithmus eingesetzt wird, welcher verhindert, daß die Logdaten zuviel Festplattenplatz belegen.

Desweiteren erzeugt das Programm eine Hauptseite, welche GIF Grafiken der täglichen Zusammenfassung für jede Schnittstelle eines Routers beinhaltet. Dadurch erhält man auf einen Blick eine Übersicht über den Gesamtstatus. Die Abbildungen 3 und 4 zeigen die Hauptseite, sowie eine Detailseite, welche von MRTG erzeugt worden sind.

Abbildung 3: Hauptseite des Interfaces	Abbildung 4: Detailseite des Interfaces
(Für eine Bildvergrößerung einfach in die Bilder klicken)

Es wird nun ein typischer Installationsvorgang gezeigt. Zuerst braucht man das MRTG Paket. Zum Zeitpunkt, als dieser Artikel geschrieben worden ist, war Version 2.1 aktuell. Unter dem Verweis am Ende des Artikel findet man die jeweils aktuelle Version.

Ein Paket, welches vor der Übersetzung von MRTG installiert werden muß is die GD Grafikbibliothek. Einen Verweis auf diese findet man ebenfalls am Ende dieses Artikels. Die aktuelle Version von GD ist 1.2, welche problemlos kompiliert und installiert können werden sollte. Nach der Eingabe von make in dem Verzeichnis, welches nach dem Entpacken der Distribution erzeugt worden ist, wird eine Datei namens libgd.a erzeugt werden. Diese Datei sollte nach /usr/local/lib und alle .h Dateien nach /usr/local/include/gd kopiert werden.

Nun sollte GD einsatzbereit sein. Als nächstes wird das MRTG Paket installiert. Dazu wird die Distribution entpackt und ihr ../../common/January1998/Makefile entsprechend angepaßt, so daß die GD Bibliothek, ihre Headerdateien und das Pearlprogramm (Version 5.003) gefunden werden. Letzteres ist normalerweise unter /usr/bin/perl oder /usr/local/bin/perl zu finden. Zu diesem Zweck müssen die Variablen GD_LIB, GD_INCLUDE und PERL im ../../common/January1998/Makefile angepaßt werden.

Das Hauptprogramm wird durch die Eingabe von make rateup erzeugt. Sobald die Übersetzung beendet ist, gibt man make substitute ein, um den korrekten Pfad zum Perl Interpreter innerhalb der von MRTG eingesetzten Perl Skripte einzubinden.

Folgende Dateien müssen an die endgültige Stelle der Binärdateien (zum Beispiel /usr/local/mrtg/) kopiert werden: BER.pm, SNMP_Session.pm, mrtg and .rateup. Auch die beiden Konfigurationsprogramme indexmaker und cfgmaker können in dieses Verzeichnis kopiert werden.

Man stelle sicher, daß das Ausführungsbit der Programme gesetzt ist. Nun kann eine einfache Konfigurationsdatei erzeugt werden. Zu diesem Zeitpunkt braucht man SNMP Lese-Zugriff auf den jeweiligen Router. Für einen Cisco Router sehen dafür die Konfigurationseinträge wie folgt aus:

access-list 99 permit 193.147.0.8
access-list 99 permit 193.147.0.9
access-list 99 permit 193.147.0.130
snmp-server community public RO 99

Dadurch werden Lese-Zugriffe (und nur solche) von den Adressen, die in der Zugriffsliste 99 spezifiziert werden, unter Verwendung des public Passwortes (Community) zugelassen. Soll jedes Gerät im Netzwerk Read Only (RO) Zugang zum Router erhalten, kann dies durch folgende Zeile erreicht werden:

snmp-server community public RO

Im Handbuch des jeweiligen Routers sollte immer zu finden sein, wie man de SNMP Zugriff erlaubt.

Das cfgmaker Skript vereinfacht die Erzeugung einer Konfigurationsdatei erheblich. Alles, was man zu tun hat, ist, es mit den folgenden Argumenten aufzurufen:

cfgmaker <community>@<router-host-name or IP>

Zum Beispiel:

cfgmaker public@mec-router.rediris.es > mrtg.cfg

Es wird jede Schnittstelle des Routers finden und einen Abschnitt in der Datei mit den Spezifikationen, der Zahl der Schnittstellen, der maximalen Übertragungsgeschwindigkeit, der Beschreibung, usw. anlegen. Dabei werden zusätzliche HTML Tags für die Darstellung auf der Detailseite eingefügt, Es ist möglich, dieses HTML Layout den eigenen Wünschen, der Sprache, uvm. anzupassen. Abbildung 5 zeigt die Ausgabe für eine Schnittstelle meines Routers.

Nun kann das Programm mrtg zum ersten Mal ausgeführt werden:

./mrtg mrtg.cfg

Sollte alles glatt laufen, so wird der Router kontaktiert, einige Werte angefragt, einige Log-Dateien angelegt und ein paar GIF Dateien in der aktuellen Datei erzeugt. Man braucht sich keine Gedankten über die Beschwerde, daß Log-Dateien und Grafiken nicht gefunden worden seien, zu machen. Dies passiert nur beim ersten Mal. Man entferne die Graphiken und starte das Programm nochmals. Die erzeugten Bilder stellen den Verkehr dar, der seit dem letzten Programmaufruf aufgetreten ist. Gleichzeitig werden für jede Netzwerkschnittstelle HTM Seiten angelegt.

Nun wird es Zeit, MRTG ordentlich auf den System zum Laufen zu bewegen. Zuerst legt man ein Verzeichnis unterhalb dem Dokumentenverzeichnis des eigenen WWW Servers an (wenn man davon ausgeht, daß solch einer auf dem gleichen System läuft), in welchem die Seiten und Grafiken untergebracht werden, die MRTG bei jedem Aufruf erzeugt. Dieses Verzeichnis wird an den Anfang der Konfigurationsdatei in folgender Form gesetzt: WorkDir: /usr/local/web/mrtg (falls das Dokumentenverzeichnis des WWW Servers unter /usr/local/web zu finden ist). Wird MRTG das nächste Mal aufgerufen, werden die Log-Dateien und Grafiken in diesem Verzeichnis angelegt. Sie können unter http://your_host.domain/mrtg erreicht werden (your_host.domain ist dabei die URL des WWW Servers).

Nun mag man sicherlich die Hauptseite für alle Schnittstellen erzeugen, wie die, die in Abbildung 3 zu sehen war. Dies kann mittels des Programmes indexmaker erreicht werden:

indexmaker mrtg.cfg <router-name regexp> > /usr/local/web/mrtg/index.html

Dadurch wird eine HTML Seite mit den Grafiken über die tägliche Statistik der Schnittstellen, deren Routername den vorhergehenden regulären Ausdruck matched, erzeugt, und diese mit den jeweiligen Detailseiten gelinkt.

Wie man sich denken kann, muß MRTG regelmäßig gestartet werden, damit die Daten jedes Intervalles gesammelt und die Grafiken periodisch erzeugt werden, wodurch die Illusion einer Echtzeitüberwachung aufrechterhalten wird. Dies wird durch folgende Zeile in der crontab erreicht (wobei angenommen wird, daß /usr/local/mrtg-bin das endgültige Verzeichnis von mrtg ist):

0,5,10,15,20,25,30,35,40,45,50,55 * * * * \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1

Bei einer Red Hat Distribution, würde die korrekte Zeile, die zu der Datei /etc/crontab hinzugefügt werden würde, wie folgt aussehen:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * root \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1

Sollte alles klappen, so kann man nun ein wenig an der Konfiguration und der HTML Indexseite drehen. Eine gute Erweiterung ist es, <META .....> in den <HEAD> Abschnitt der Seite zu plazieren, sodaß der WWW Browser gezwungen wird, alle 300 Sekunden die Seite neu zu laden und so die neuesten Informationen auf dem Bildschirm darzustellen.

Desweiteren kann man in der Konfigurationsdatei die Direktive WriteExpire eintragen, welche MRTG zwingt, .meta Dateien für jede GIF und HTML Datei anzulegen. Dadurch wird unnötiges Caching von Proxy Servern und Browsern unterbunden. Dazu muß allerdings zusätzlich der WWW Server dazu gebracht werden, diese .meta Dateien zu lesen und die korrekten "Expire" Blöcke mit der MetaDir Direktive in der Datei XXXX zu schicken.

Weitere Direktiven können der Beispielkonfiguration der Distribution entnommen werden, welche recht ausführlich dokumentiert ist. Es ist möglich, das Layout der von MRTG erzeugten Bilder und Seiten zu modifizieren.

Ich hoffe, daß der Leser das Programm brauchbar finden wird. Sollte dies der Fall sein, so möge er den Autoren eine Postkarte schicken. Ihre Adresse ist auf der MRTG Homepage zu finden.