Projektdokumentation

Projektdokumentation Planung und Realisierung einer Service Availability Management Lösung auf Basis von Nagios für das bestehende Netzwerk der Technischen Fakultät der CAU Tim Grebien

Inhaltsverzeichnis 1 Projektdefinition 4 1.1 Projektbeschreibung / Ziel des Projekts............ 4 1.2 Projektumfang.......................... 4 2 Ist Analyse 4 2.1 Die Netzwerk- und Dienststruktur der Technischen Fakultät. 4 2.2 Administrative Tätigkeiten der Rechnerbetriebsgruppe.... 5 3 Soll-Konzept 5 3.1 Anforderungen.......................... 5 4 Planung der Implementierung 6 4.1 Auswahl der Software....................... 6 4.2 Auswahl der Hardware...................... 6 4.3 Aufstellung der zu überwachenden Dienste........... 7 5 Realisierung 8 5.1 Vorbereitung der Installation................... 8 5.2 Übersetzen des Nagios-Quelltextes................ 8 5.3 Konfiguration des Webservers.................. 9 5.4 Konfiguration der CGI-Programme und des CGI-Wrappers.. 9 5.5 Installation und Funktionstest der Nagios-Plugins....... 9 5.6 Installation und Konfiguration von nrpe............ 10 5.7 Konfiguration des Nagios-Basispaketes............. 11 5.8 Erster Start von nagios und Funktionstests........... 11 5.9 Abschließende Arbeiten...................... 12 6 Arbeiten mit Nagios 13 6.1 Bedienung der Weboberfläche.................. 13 7 Bewertung / Fazit 15 7.1 Funktionalität der Implementierung............... 15 7.2 Performance............................ 16 A Projektverlauf 17 B Hintergrundwissen 17 B.1 Funktionstheorie von Nagios................... 17 B.2 Glossar............................... 18 2

C Konfigurationsdateien 20 C.1 httpd.conf............................. 20 C.2 contacts.cfg und contactgroups.cfg................ 20 C.3 checkcommands.cfg........................ 21 C.4 hosts.cfg und hostgroups.cfg................... 21 C.5 services.cfg............................. 22 C.6 escalations.cfg........................... 24 C.7 misccommands.cfg........................ 24 C.8 timeperiods.cfg.......................... 24 3

1 Projektdefinition 1.1 Projektbeschreibung / Ziel des Projekts Ziel des Projektes ist es, durch Installation einer Service Availability Management Software die Möglichkeit zu schaffen, im Netzwerk verteilte Dienste und Ressourcen aktiv auf ihre Verfügbarkeit zu überwachen. Nagios soll die Mitarbeiter der Rechnerbetriebsgruppe möglichst frühzeitig über Ressourcenknappheit und Probleme bei der Verfügbarkeit von Diensten informieren, damit diese geeignete Gegenmaßnahmen ergreifen können. Dies soll helfen Ausfallzeiten zu minimieren oder im besten Fall zu vermeiden. 1.2 Projektumfang Das Projekt umfasst die gesamte technische Realisierung, die Prüfung der Praxistauglichkeit sowie eine anschließende Bewertung der Installation. Zu den einzelnen Arbeitsschritten zählt die Auswahl geeigneter Soft- und Hardware, das Ermitteln und Zusammenstellen zu überwachender Ressourcen und Dienste, die korrekte Installation und Konfiguration der Software, Anpassungsarbeiten an vorhandener benötigter Hilfssoftware (Webserver), sowie die Entwicklung und Durchführung von Testszenarien zur abschließenden Funktionsüberprüfung und Bewertung der Implementierung. 2 Ist Analyse 2.1 Die Netzwerk- und Dienststruktur der Technischen Fakultät Das interne Netzwerk der Technischen Fakultät erstreckt sich über acht Gebäude die mittels Lichtwellenleiter durch ein Gigabit-Backbone untereinander vernetzt sind. In den einzelnen Gebäuden befinden sich insgesamt etwa 350 Bildschirmarbeitsplätze (PC und SUN Workstations) die mittels Twisted Pair (100 MBit/s) über Switches an das Backbone angeschlossen sind. Die PC-Arbeitsplätze, die größtenteils Microsoft Windows NT 4.0 oder Windows 2000 als Betriebssystem verwenden sind alle Mitglieder einer Windows NT- Domäne, die von zwei NT-Domaincontrollern verwaltet wird. Mehrere UNIX- (SUN Solaris) und Linux-Server stellen zentral Dienste zur Verfügung. Diese Dienste umfassen unter anderem HTTP, Mail, News, Datei- und Druckdienste sowie eine zentrale Benutzerverwaltung. 4

2.2 Administrative Tätigkeiten der Rechnerbetriebsgruppe Die Rechnerbetriebsgruppe stellt den Betrieb aller zentraler Rechenanlagen und Dienste sicher. Sie verwaltet den Zugang zu Rechnersystemen, vergibt und entzieht Benutzerkennungen und teilt Ressourcen und Prioritäten zu. Weiterhin übernimmt sie die Betreuung der EDV-Arbeitsplätze in der Verwaltung sowie in einigen Lehrstühlen. 3 Soll-Konzept 3.1 Anforderungen Durch Absprache mit den Administratoren der Rechnerbetriebsgruppe wurden die Anforderungen und Kriteriern, die an ein Service Availability Management Konzept gestellt werden, ermittelt: Alle Dienste die via Netzwerk erreichbar sind sollen aktiv auf ihre korrekte Funktion hin geprüft werden. Lokale Ressourcen, wie beispielsweise freier Festplattenspeicher oder CPU-Auslastung, sollen von zentraler Stelle aus über das Netzwerk überwacht werden können. Lokale Prozesse, die keine Netzwerkschnittstelle bieten, sollen auf Vorhandensein geprüft werden. Das System soll flexibel an neue Anforderungen angepasst werden können. Der aktuelle Zustand aller überwachten Objekte soll zu jedem Zeitpunkt von jedem Ort über ein Webinterface abrufbar sein. Dieser Zugang ist mit einem Passwort vor unauthorisiertem Zugriff zu schützen. Es sollen verschiedene Eskalationsstufen definiert werden können. Bei Problemen sollen die zuständigen Administratoren per E-Mail oder, bei anhaltenden Fehlerzuständen außerhalb der Dienstzeiten, auch via SMS benachrichtigt werden können. Die Software soll frei und im Quellcode verfügbar sein. 5

4 Planung der Implementierung 4.1 Auswahl der Software Es gilt eine passende Software für ein Service Availability Management System zu finden, die den gestellten Anforderungen gerecht wird. Nagios wird diesen Anforderungen voll gerecht. Durch die interne Dreiteilung in das Nagios-Kernprogramm, das die Zeitplanung und Ausführung der Servicechecks sowie die Ereignisbehandlung übernimmt, die CGI-Programme für die Webdarstellung und die Nagios-Plugins, die zum Prüfen der Dienste dienen, ist Nagios einfach und flexibel erweiterbar. Um beispielsweise einen völlig neuen Dienst überprüfen zu können, muss lediglich ein passendes Plugin programmiert werden. Es sind keine Änderungen am Basisprogamm notwendig. Da sowohl das Nagios-Basisprogramm als auch die Plugins im Quelltext vorliegen ist es problemlos auf verschiedene UNIX-artige Systeme portierbar. Dies erleichtert den Einsatz von Nagios in der heterogenen Systemumgebung (SUN Solaris und Linux) der Technischen Fakultät. Des Weiteren bietet Nagios mit Hilfe der Benutzerverwaltung des Webservers die Möglichkeit eine Rechtestruktur auf der Weboberfläche zu implementieren, die einen fakultätsweiten Einsatz mit delegierten Kompetenzen ermöglicht. Die Kommandos für die Problembenachrichtigung können frei gewählt werden, so dass beliebige Formen der Benachrichtigung (E-Mail, SMB-Nachrichten, SMS, Pager, etc.) möglich sind. 4.2 Auswahl der Hardware Als Server kommt ein vorhandener SUN Enterprise 450 Server zum Einsatz. Der Server verfügt über zwei Prozessoren, zwei Gigabyte Hauptspeicher und ein 1000MBit/s Netzwerkinterface. Auf dem System ist bereits ein Webserver für die Internetpräsenz der Technischen Fakultät installiert. Dieser soll dann auch die Bereitstellung der Weboberfläche mittels eines vituellen Netzwerkinterfaces übernehmen. Der Server hat genügend freie Rechenkapazität für die Ausführung der Servicechecks. 6

4.3 Aufstellung der zu überwachenden Dienste Folgende Dienste sollen von Nagios auf ihre Verfügbarkeit überwacht werden: Host(s) IP-Addresse Dienst Typ Beschreibung Alle SUN- ssh Netzwerk Secure Shell Workstations disk Lokal Festplattenauslastung zombies Lokal Zombieprozesse Alle Switches ping Netzwerk Erreichbarkeit batman 134.245.244.176 ssh Netzwerk Secure Shell smtp Netzwerk SMTP-Server pop3 Netzwerk POP3-Server crest 134.245.244.131 ssh Netzwerk Secure Shell dns Netzwerk DNS-Server smtp Netzwerk SMTP-Server imaps Netzwerk IMAP-Server mit SSL news Netzwerk News-Server amavis Lokal Mail-Virenscanner disk Lokal Festplattenauslastung sds Lokal Festplattenspiegelung zombies Lokal Zombieprozesse hope 134.245.244.140 ssh Netzwerk Secure Shell http Netzwerk Webserver squid Netzwerk Webcache dns Netzwerk DNS-Server disk Lokal Festplattenauslastung sds Lokal Festplattenspiegelung zombies Lokal Zombieprozesse mort 134.245.244.155 ssh Netzwerk Secure Shell snort Lokal Snort IDS disk Lokal Festplattenauslastung zombies Lokal Zombieprozesse 7

5 Realisierung Im Folgenden wird die Realisierung des Projektes in chronologischer Reihenfolge beschrieben. 5.1 Vorbereitung der Installation Zunächst wird ein neuer Benutzer für das Nagios-System angelegt. Später sollen die Nagios-Prozesse unter dessen Kennung laufen. Der neue Benutzer erhält den Namen nagios mit UID 775 die primäre Gruppe des Benutzers heißt auch nagios (GID 775) und wird ebenfalls angelegt. Das Home- Verzeichnis für den Benutzer ist /home/nagios und wird mittels NFS an alle UNIX-Rechner exportiert. 5.2 Übersetzen des Nagios-Quelltextes Der Quelltext für Nagios Version 1.0b6 wird heruntergeladen und entpackt. Auf der obersten Ebene im Nagios-Quellbaum wird als erstes das Shell-Skript configure ausgeführt. configure versucht den Systemtyp sowie die Prozessorarchitektur des Systems zu ermitteln und prüft weiterhin die Funktion und das Vorhandensein verschiedener Bibliotheks- und Systemaufrufe. Dem configure-skript werden verschiedene Parameter übergeben: prefix=/home/nagios Die Software soll unterhalb von /home/nagios installiert werden. with-cgiurl=/cgi-bin/cgiwrap/nagios Die URL unter der später die CGI-Programme für das Webinterface liegen. with-htmurl=/ Die URL unter der die html-seiten für das Webinterface liegen. with-nagios-user=nagios Die Nagios-Prozesse sollen unter der Userkennung Nagios laufen. with-nagios-group=nagios Die Nagios-Prozesse sollen unter der Gruppenkennung Nagios laufen. with-openssl=/usr/local/ssl Der Installationsort der OpenSSL Bibliothek für SSL-Verschlüsselung Nach dem Ablaufen von configure startet der Aufruf von make die Übersetzung des Quelltexts. Danach wird Nagios durch den Aufruf von make install in das Verzeichnis /home/nagios installiert. Dies schließt die Installation des Nagios Basispakets ab. 8

5.3 Konfiguration des Webservers Für die Bereitstellung der Weboberfläche muss die Konfiguration des bereits installierten Webservers angepasst werden. Da die Oberfläche später unter http://nagios.tf.uni-kiel.de erreichbar sein soll, wird zunächst ein virtuelles Netzwerkinterface erstellt. Der IP-Addresse des Interfaces wird der DNS-Name nagios.tf.uni-kiel.de zugewiesen. In der Konfigurationsdatei des Webservers werden Einträge für den neuen virtuellen Host angelegt. Ein Auszug aus der Datei findet sich im Anhang C. Danach wird für die Benutzerauthentifizierung die Datei htpasswd.users angelegt. Dort wird der Benutzer admin mit Passwort eingetragen. Zum Aktivieren der Einträge muss der Webserver durch Aufruf von apachectl restart neu gestartet werden. Nach dem Neustart wird die prinzipielle Funktion der Weboberfläche duch Aufruf von http://nagios.tf.uni-kiel.de im Webbrowser getestet. Die Nagios-Startseite wird angezeigt, die Konfiguration war erfolgreich. 5.4 Konfiguration der CGI-Programme und des CGI- Wrappers Für die Generierung aktueller Statusberichte werden bei Anforderung des entsprechenden Berichtes im Webbrowser CGI-Programme auf dem Webserver ausgeführt. Die Programme sind im Nagios-Basispaket enthalten und befinden sich nach der Installation in /home/nagios/sbin. Standardmäßig würden diese Skripte mit der Benutzerkennung (UID) des Webservers ausgeführt werden. Da die Programme allerdings auf Daten zugreifen müssen, die nur für den Benutzer nagios lesbar sein sollen, wird ein CGI-Wrapper verwendet. Der CGI-Wrapper ist ein Programm, das die entsprechenden CGI- Programme als Benutzer nagios ausführt. Weiterhin erhält der Benutzer nagios die Berechtigung zum Ausführen von CGI-Programmen. 5.5 Installation und Funktionstest der Nagios-Plugins Alle Dienst- und Ressourcentests sind in Plugins ausgelagert, das bisher installierte Nagios-Kernprogramm ist lediglich für die Ausführung der Plugins und die Webdarstellung verantwortlich. Die Nagios-Plugins werden analog zum Nagios-Basispaket durch die Aufrufe von configure, make und make install übersetzt und nach /home/nagios/libexec installiert. Die korrekte Funktion einzelner Plugins setzt teilweise zusätzliche Software voraus, die zunächst installiert werden musste. Beispielsweise benötigt das Plugin check radius, das die Verfügbarkeit eines RADIUS-Dienstes prüft, das Paket libradiusclient-0.50. Bei anderen Plugins mussten zunächst Teile des 9

Quelltextes angepasst werden, da mitunter Kommandozeilenparameter geändert werden mussten. Das Plugin check hpjd verwendet das externe Kommando snmpget um via SNMP den Status eines HP Druckers abzufragen. Hier war etwas Anpassungsarbeit am Quelltext nötig, da die installierte Version von snmpget andere Kommandozeilenparameter erwartete als die vom Plugin vorausgesetzte. Nach der Installation wird zunächst die korrekte Funktion der einzelnen Plugins geprüft. Hierzu werden die Plugins manuell an der Kommandozeile aufgerufen und die Ausgabe ausgewertet. Es wurde festgestellt, dass das Plugin check disk, das die Ausgabe des Systembefehls df -k verarbeitet um den freien Festplattenspeicher zu ermitteln, alle gemounteten Dateisysteme (also auch via NFS über das Netzwerk gemountete) prüft. Dies ist ungünstig, da nur lokale Dateisysteme getestet werden sollen. Durch Umschreiben des Befehls im Quelltext in df -k -F ufs konnte dieses Verhalten beseitigt werden. Alle anderen Plugins arbeiteten wie erwartet. 5.6 Installation und Konfiguration von nrpe Um systemlokale Ressourcen wie freien Festplattenspeicher oder CPU-Auslastung über das Netzwerk überwachen zu können wird auf den Clients ein Zusatzmodul, der Nagios Remote Plugin Executor (nrpe), installiert. Nrpe wird mittels configure, make und make install nach /home/nagios/bin installiert und ist, da /home/nagios via NFS an alle UNIX-Rechner exportiert wird, dann auf allen Nagios-Clients verfügbar. Auf den Clients wird der nrpe vom Internet Super Server, dem inetd, gestartet. Dazu wird der nrpe in die jeweilige Konfigurationsdatei des inetd eingetragen. Der Zugriff auf nrpe ist über einen TCP-Wrapper abgesichert. In der Konfigurationsdatei des Wrappers wird der Zugriff auf nrpe nur vom Nagios-Server aus erlaubt. Nach einem Neustart des inetd wartet nrpe auf Port 5666 auf Verbindungen vom Nagios-Server. Die auszuführenden Servicechecks werden in die Datei nrpe.cfg eingetragen, damit nrpe korrekt arbeitet. Die Syntax der Einträge lautet: command[check disk]=check disk -w 3% -c 1% Nun kann die lokale Festplattenauslastung der Clients durch den Aufruf von: check nrpe <Hostname> -c check disk vom Nagios-Server aus geprüft werden. Ein Test mit dem obrigen Aufruf verlief wie erwartet. Nrpe arbeitet korrekt. 10

5.7 Konfiguration des Nagios-Basispaketes Die Konfigurationsdateien für das Nagios-Basispaket befinden sich im Verzeichnis /home/nagios/etc. Es gibt 4 Arten von Konfigurationsdateien: Hauptkonfigurationsdatei In der Hauptkonfigurationsdatei nagios.cfg werden die Einstellungen für das Nagios-Basisprogramm festgelegt. Dazu gehören beispielsweise Angaben zur Planung der einzelnen Servicechecks, der Speicherort der Logdatei und die Benutzerkennung unter der das Nagios-Basisprogramm und die Plugins ausgeführt werden. CGI Konfigurationsdatei In der Datei cgi.cfg stehen Einstellungen für die CGI-Programme. Unter anderem werden hier die Zugriffsrechte auf die Programme festgelegt. Da es in unserem Fall nur den Benutzer admin gibt, bekommt dieser alle Rechte zugewiesen. Ressourcen-Konfigurationsdatei In dieser Datei können Makros und Variablen definiert werden. In unserem Fall wird hier nur die Variable $USER1$ auf den Plugin-Pfad /home/nagios/libexec gesetzt. Objekt-Konfigurationsdateien Die zu überwachenden Hosts, zu prüfende Dienste, Kontakte, Kontaktgruppen usw. werden in jeweils eine Datei eingetragen. Die Einträge werden auch als Objekte bezeichnet. Auch die Kommandos für die einzelnen Servicechecks sowie für die Benachrichtigungen werden in Objektkonfigurationsdateien erfasst. Es besteht die Möglichkeit Einträge als Vorlagen zu kennzeichnen, um Gemeinsamkeiten zwischen einzelnen Objekten nur einmal erfassen zu müssen. Beispieleinträge sind in Anhang C zu finden. 5.8 Erster Start von nagios und Funktionstests Nach dem Anpassen der Konfiguration wird die syntaktische Korrektheit und Konsistenz der verschiedenen Dateien untereinander mit dem Befehl nagios -v nagios.cfg überprüft. Hier traten zunächst einige Fehler (Fehlende Klammern, Tippfehler...) auf. Nach der Korrektur wird Nagios mit der Befehlszeile nagios nagios.cfg -d gestartet. Der Parameter -d bewirkt, dass der Prozess als Daemon, nicht interaktiv im Hintergrund startet. Nach dem ersten Start benötigt Nagios etwas Zeit (ca. 10 Minuten bei der vorliegenden Anzahl von Service-Checks) um die initialen Dienst- und Systemzustände festzustellen. Nach Ablauf dieser Zeitspanne wird als erstes die korrekte Funktion der Weboberfläche und der CGI-Programme getestet. Dies geschieht durch Abrufen der einzelnen Berichte im Webbrowser. 11

Zunächst funktionierten einige CGI-Programme nicht wie erwartet. Die Fehleranalyse ergab, dass die betreffenden Programme benötigte Bibliotheken nicht finden konnten. Dies war auf fehlende Parameter bei der Kompilierung zurückzuführen. Nach dem Neuübersetzen der entsprechenden Programme mit korrekten Parametern funktionierte alles wie erwartet. Nach diesem ersten erfolgreichen Test werden verschiedene Testszenarien zur Überprüfung der korrekten Funktion der Service- und Hostchecks sowie der Fehlerbenachrichtigungen durchgespielt: Gezieltes Abschalten von Diensten Gezieltes Unterbrechen von Netzwerkverbindungen Leeren des Papierschachts des Druckers Die maximal beobachtete Latenzzeit zwischen Auftreten und Erkennen des Fehlers betrug zwei Minuten. Die Weboberfläche zeigte den Fehlerstatus korrekt an. Fehlerbenachrichtigungen wurden an die entsprechenden Kontakte versandt. 5.9 Abschließende Arbeiten Um zu erreichen, dass Nagios bei einem Neustart des Servers automatisch startet wird noch ein Startskript angelegt. Die Kommandos zum Anlegen des virtuellen Interfaces für die Weboberfläche beim Systemstart werden in das Startskript des Webservers eingetragen. Die Nagios-Installation ist nun vollständig abgeschlossen. 12

6 Arbeiten mit Nagios 6.1 Bedienung der Weboberfläche Nach dem Aufruf von nagios.tf.uni-kiel.de im Webbrowser erscheint zunächst ein Dialogfeld zur Passworteingabe. Nach erfolgreicher Überprüfung des Passworts gelangt man auf die Startseite. Hier erhält man einen kurzen Überblick über den aktuellen Systemstatus. Im linken Frame befinden sich weitere Auswahlmöglichkeiten, mit denen detailliertere Berichte abgefragt werden können. Über den Punkt Service Detail werden erweiterte Informationen über einzelne Dienste angezeigt. 13

Dies ist die Detailansicht des Dienstes SMTP auf dem Server crest. Unter Service State Information finden sich viele Informationen bezüglich des Dienstzustands und der letzten Prüfung. Auf der rechten Seite unter Service Commands besteht die Möglichkeit Befehle an das Nagios-Basisprogramm zu senden, um beispielsweise eine sofortige Prüfung des Dienstes zu erzwingen oder Fehlerbenachrichtigungen für den Dienst abzuschalten. 14

Des Weiteren besteht über die Weboberfläche die Möglichkeit, sich Statistiken bezüglich der Verfügbarkeit von Diensten anzeigen zu lassen. Dies ist die Verfügbarkeitsstatistik für den Dienst SMTP auf dem Host batman über den Zeitraum von sieben Tagen. Der Balken zeigt die Verfügbarkeit des Dienstes, Ausfallzeiten sind in Rot markiert. Die Zeit, in der der Dienst erreichbar war ist grün gekennzeichnet. Weiter unten auf der Seite lässt sich die Gesamtverfügbarkeit absolut und relativ in Prozent ablesen. 7 Bewertung / Fazit 7.1 Funktionalität der Implementierung Die Nagios-Implementierung konnte bezüglich ihrer Funktionalität voll überzeugen. Während der Evaluierungsphase von einer Woche wurden durch Nagios bisher noch nicht bemerkte Dienst- und Ressourcenprobleme entdeckt. So gibt es beispielsweise auf einem Linux-Server Erreichbarkeitsprobleme 15

der Netzwerkdienste, während der nächtlichen Datensicherung. Dies ist vermutlich auf eine unperformante TCP/IP-Implementierung des Linux zurückzuführen. Des Weiteren hat Nagios frühzeitig Kapazitätsprobleme auf dem Dateisystem für die Mailboxen der Benutzer erkannt und gemeldet. Um den freien Speicherplatz zu erhöhen wurde das Dateisystem vergrössert, bevor es zu Problemen kam. 7.2 Performance Während der Evaluierungsphase wurde die CPU- und Netzwerkbelastung des Nagios-Servers sowie der überwachten Clients besonders überwacht. Es wurde, obwohl etwa alle zwei Sekunden ein Servicecheck ausgeführt wird, nur eine geringfügige Erhöhung der CPU- und Netzwerklast festgestellt. Ein einzelner Servicecheck dauert durchschnittlich eine Sekunde. Auch auf den Clients wurden keine auffallenden Lastspitzen beobachtet. Daraus ist zu schließen, dass die Verteilung der Checks zwischen den Clients gut ausgewogen ist. 16

A Projektverlauf Projektphase Einarbeitung und Aneignen von Hintergrundwissen Ist Analyse Bestandsaufnahme und Analyse der bisherigen Administrations und Dienststruktur Soll Konzept Absprache mit den Mitarbeitern der Rechnerbetriebsgruppe über die Ziele und Anforderungen des Projekts. Gruppierung der relevanten Dienste. Planung der Implementierung Erstellung des Grundkonzepts, Planen der notwendigen Schritte. Durchführung und Realisierung Installation und Konfiguration des Nagios-Basispaketes und der Plugins, Konfiguration des vorhandenen Webservers. Funktionstests Bewertung / Fazit Beurteilung der Implementierung hinsichtlich Funktionalität und Performanceauswirkungen. Erstellung der Projektdokumentation Gesamtzeit: Zeitraum 2 Std. 2 Std. 2,5 Std. 3 Std. 12,5 Std. 1 Std. 2 Std. 10 Std. 35 Std. B Hintergrundwissen B.1 Funktionstheorie von Nagios Eine Hauptfunktion des Nagios-Basisprogramms ist die Zeitplanung der Servicechecks. Nagios versucht die Last für die zu prüfenden Clients durch sogenanntes Service Check Interleaving möglichst gleichmäßig zu verteilen. Wenn Beispielsweise drei Hosts mit je drei Diensten geprüft werden sollen ist die Prüfungsreihenfolge: Host1, Dienst1; Host2, Dienst1; Host3, Dienst1; Host1, Dienst2... Der Rückgabewert eines Servicechecks landet zunächst in der Ereigniswarteschlange (Event Queue). Der Inhalt der Queue wird etwa alle zehn Sekunden bearbeitet und die Queue geleert. Liefert ein bestimmter Servicecheck einen 17

Fehlerzustand zurück wird, nachdem die in retry check interval angegebene Zeitdauer verstrichen ist ein weiterer Check durchgeführt. Dies wird in der Nagios-Terminologie als Soft Error State, weicher Fehlerstatus, bezeichnet. Ändert sich auch nach zwei weiteren Prüfungen nichts am Zustand des Dienstes, geht Nagios in einen Hard Error State, harten Fehlerstatus. Die entsprechenden Kontaktgruppen werden über den jeweiligen notification command benachrichtigt. Sobald der Zustand des Dienstes keinen Fehler mehr aufweist geht Nagios zurück in den OK Zustand. Wiederum werden die entsprechenden Kontaktgruppen über die Zustandänderung informiert. B.2 Glossar CGI-Programme/Skripte Über das Common Gateway Interface besteht die Möglichkeit Programme auf dem Webserver auszuführen um Webseiten dynamisch zu generieren. Die CGI Programme von Nagios erstellen aus den gesammelten Daten Statusberichte. DNS Der Domain Name Service ist ein Dienst zur Auflösung von Hostnamen in IP-Adressen und umgekehrt. Domäne Eine Gruppe von Servern und anderen Netzwerkobjekten unter einheitlichem Namen. Domain-Controller Ein Server der die Benutzer und Rechner für eine Domäne authentifiziert. Jede Domäne muss mindestens einen Domain- Controller für die Verwaltung besitzen. GID Unter UNIX ist jeder Benutzer Mitglied in zumindest einer Gruppe. Jede Gruppe hat zusätzlich zu ihrem Namen eine numerische Gruppen- ID, die für die interne Verwaltung benötigt wird. Host-Check Ein Hostcheck überprüft die prinzipielle Erreichbarkeit eines Hosts über das Netzwerk. Im Gegensatz zu Servicechecks werden Hostchecks nur durchgeführt, wenn ein Servicecheck fehlschlägt. Dies dient der Prüfung ob nur der Dienst oder der ganze Host von dem Problem betroffen ist. inetd Der Internet Super Server (inetd) bindet Ports für verschiedene Netzwerkdienste wie beispielsweise POP3, Telnet, rsh. Bei einer Verbindung auf einen Port startet der inetd bedarfsweise den eigentlichen Serverprozess, der dann die Anfrage bearbeitet. Die durch den inetd gestarteten Dienste können wahlweise durch TCP-Wrapper abgesichert werden. 18

NFS Das Network File System (NFS) dient unter UNIX zur Bereitstellung von Dateisystemen über das Netzwerk. Im Gegensatz zu Netzwerklaufwerken unter Windows ist die Anbindung transparent, der Benutzer weiß nicht ob er gerade auf ein lokales oder entferntes Dateisystem schreibt. RADIUS Das RADIUS-Protokoll dient der Authentifizierung von Einwahlbenutzern. Service-Check Ein Servicecheck ist die vom Nagios-Basisprogramm initiierte Überprufung eines bestimmten Dienstes oder einer bestimmten Ressource. Servicechecks werden automatisch in vorher definierten Zeitabständen geplant und durchgeführt. Service Availability Management Service Availability Management bedeutet die Verfügbarkeit von Netzwerkdiensten und Ressourcen zu überwachen, um Ausfallzeiten möglichst gering zu halten. SNMP Das Simple Network Management Protocol dient zur Verwaltung von Netzwerkgeräten. Alle Parameter die über das Netzwerk ausgelesen und gesetzt werden können sind in der Management Information Base für das Gerät eingetragen. TCP-Wrapper TCP-Wrapper dienen der Zugriffskontrolle auf TCP-Ebene. Anhand von Schwarz- und Weißlisten in den Dateien hosts.deny und hosts.allow wird entschieden, ob ein bestimmter Host auf einen bestimmten Dienst zugreifen darf. UID Unter UNIX bekommt jeder Benutzer zusätzlich zu seinem Login- Namen eine eindeutige numerische User-ID (UID). Diese UID wird für die interne Verwaltung der User benötigt. Zombies Zombieprozesse sind Kindprozesse, die Aufgrund eines nicht erfolgten wait-systemaufrufs des Vaterprozesses nach Beendigung des Prozesslaufes ihren Rückgabewert nicht abliefern konnten. Diese Prozesse werden weiterhin in der Prozesstabelle geführt. Wenn der Vaterprozess beendet wird erbt der init-prozess alle Kindprozesse. Init führt regelmässig wait-aufrufe auf seine Kindprozesse aus. Erst dann verschwindet der Zombieprozess aus der Prozesstabelle. 19

C Konfigurationsdateien C.1 httpd.conf In der Konfigurationsdatei des Webservers httpd.conf wurden folgende Einträge für die Weboberfläche angelegt: <VirtualHost 134.245.244.162> ServerAdmin webmaster@tf.uni-kiel.de DocumentRoot /home/nagios/share ServerName nagios.tf.uni-kiel.de ErrorLog /var/adm/apache/nagios-error_log TransferLog /var/adm/apache/nagios-access_log </VirtualHost> <Directory "/home/nagios/share"> AllowOverride AuthConfig Order allow,deny Allow from all </Directory> <Directory "/home/nagios/sbin"> AllowOverride AuthConfig Order allow,deny Allow from all Options ExecCGI </Directory> Die Einträge bewirken, dass ein virtueller Host mit dem vollständigen Servernamen nagios.tf.uni-kiel.de auf der IP-Adresse 134.245.244.162 angelegt wird. Ein Zugriff auf die Verzeichnisse mit den HTML-Dokumenten und CGI-Programmen ist erst nach erfolgreicher Passwortüberprüfung erlaubt. C.2 contacts.cfg und contactgroups.cfg In der Datei contacts.cfg werden die einzelnen Kontaktpersonen, also die Mitglieder der Rechnerbetriebsgruppe eingetragen. Die Einträge sind in der Form: define contact{ contact name tig 20

alias service notification period host notification period service notification options host notification options service notification commands host notification commands email } Tim Grebien 24x7 24x7 w,u,c,r d,u,r notify-by-email host-notify-by-email tig@tf.uni-kiel.de Es wird ein Kontakt tig eingerichtet. tig wird zu jeder Zeit über alle Zustandsänderungen per E-Mail an tig@tf.uni-kiel.de unterrichtet. In der Datei contactgroups.cfg werden die einzelnen Kontakte in Kontaktgruppen organisiert. Es werden zwei Gruppen angelegt. Zum einen die Gruppe rbg, in der alle RBG-Mitglieder vertreten sind. Zum Anderen die Gruppe azubi in der nur die RBG-Auszubildenden eingetragen sind. C.3 checkcommands.cfg In dieser Datei werden die Kommandozeilen für die einzelnen Servicechecks festgelegt. Beispieleintrag: define command{ command name command line } check nntp $USER1$/check nntp -H $HOSTADDRESS$ Es wird ein Objekt vom Typ command erzeugt. command name ist der Name über den aus anderen Konfigurationsdateien auf das Objekt zugegriffen wird. command line ist der Befehl der beim Zugriff auf das Objekt ausgeführt wird. $USER1$ ist ein Makro, dass nach /home/nagios/libexec aufgelöst wird. $HOSTADDRESS$ wird in die IP-Addresse des zu prüfenden Hosts aufgelöst. Für jeden Diensttyp wird ein Objekt vom Typ command angelegt. C.4 hosts.cfg und hostgroups.cfg In dieser Datei wird zunächst ein generischer Host als Vorlage angelegt. Dann wird für jeden zu prüfenden Host ein Objekt angelegt, welches die Eigenschaften des generischen Hosts erbt. Eintrag für die Vorlage: 21

define host{ name generic-host notifications enabled 1 event handler enabled 1 flap detection enabled 0 process perf data 1 retain status information 1 retain nonstatus information 1 max check attempts 10 notification interval 60 notification period 24x7 notification options d,u,r register 0 } Beispieleintrag für weitere Hosts: define host{ use generic-host host name balu alias SUN Lst. Seegebrecht address 134.245.242.10 check command check-host-alive } In diesem Beispiel wird der ein Objekt für den Host balu angelegt. Der Host hat die IP-Addresse 134.245.242.10. Der Eintrag use generic-host bewirkt, dass alle weiteren Parameter von der Vorlage generic-host übernommen werden. Falls ein Servicecheck fehlschlägt wird mit dem in der Datei checkcommands.cfg definierten Befehl check-host-alive mitttels ICMP Echo- Reply geprüft, ob der Host prinzipiell über das Netzwerk erreichbar ist. Alle eingetragenen Hosts können in der Datei hostgroups.cfg verschiedenen Hostgruppen hinzugefügt werden. In der Hostgruppe sparcs sind beispielsweise alle SUN-Rechner eingetragen. C.5 services.cfg Hier werden alle in 4.3 aufgelisteten Dienste eingetragen. Wie in der Datei hosts.cfg wird zunächst ein generischer Dienst als Vorlage für alle weiteren Dienst-Objekte erstellt. Der generische Eintrag: 22