Projektdokumentation

Planung und Realisierung einer Service Availability ManagementLosung auf Basis von Nagios fur das bestehende Netzwerk

der Technischen Fakultat 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 Fakultat . 4

2.2 Administrative Tatigkeiten 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 uberwachenden Dienste . . . . . . . . . . . 7

5 Realisierung 8

5.1 Vorbereitung der Installation . . . . . . . . . . . . . . . . . . . 8

5.2 Ubersetzen 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 Weboberflache . . . . . . . . . . . . . . . . . . 13

7 Bewertung / Fazit 15

7.1 Funktionalitat 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 20C.1 httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20C.2 contacts.cfg und contactgroups.cfg . . . . . . . . . . . . . . . . 20C.3 checkcommands.cfg . . . . . . . . . . . . . . . . . . . . . . . . 21C.4 hosts.cfg und hostgroups.cfg . . . . . . . . . . . . . . . . . . . 21C.5 services.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22C.6 escalations.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . 24C.7 misccommands.cfg . . . . . . . . . . . . . . . . . . . . . . . . 24C.8 timeperiods.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3

1 Projektdefinition

1.1 Projektbeschreibung / Ziel des Projekts

Ziel des Projektes ist es, durch Installation einer Service Availability Mana-gement Software die Moglichkeit zu schaffen, im Netzwerk verteilte Diensteund Ressourcen aktiv auf ihre Verfugbarkeit zu uberwachen.Nagios soll die Mitarbeiter der Rechnerbetriebsgruppe moglichst fruhzeitiguber Ressourcenknappheit und Probleme bei der Verfugbarkeit von Diensteninformieren, damit diese geeignete Gegenmaßnahmen ergreifen konnen. Diessoll helfen Ausfallzeiten zu minimieren oder im besten Fall zu vermeiden.

1.2 Projektumfang

Das Projekt umfasst die gesamte technische Realisierung, die Prufung derPraxistauglichkeit sowie eine anschließende Bewertung der Installation.Zu den einzelnen Arbeitsschritten zahlt die Auswahl geeigneter Soft- undHardware, das Ermitteln und Zusammenstellen zu uberwachender Ressour-cen und Dienste, die korrekte Installation und Konfiguration der Software,Anpassungsarbeiten an vorhandener benotigter Hilfssoftware (Webserver),sowie die Entwicklung und Durchfuhrung von Testszenarien zur abschließen-den Funktionsuberprufung und Bewertung der Implementierung.

2 Ist–Analyse

2.1 Die Netzwerk- und Dienststruktur der TechnischenFakultat

Das interne Netzwerk der Technischen Fakultat erstreckt sich uber achtGebaude die mittels Lichtwellenleiter durch ein Gigabit-Backbone unterein-ander vernetzt sind. In den einzelnen Gebauden befinden sich insgesamt etwa350 Bildschirmarbeitsplatze (PC und SUN Workstations) die mittels TwistedPair (100 MBit/s) uber Switches an das Backbone angeschlossen sind. DiePC-Arbeitsplatze, die großtenteils Microsoft Windows NT 4.0 oder Windows2000 als Betriebssystem verwenden sind alle Mitglieder einer Windows NT-Domane, die von zwei NT-Domaincontrollern verwaltet wird. Mehrere UNIX-(SUN Solaris) und Linux-Server stellen zentral Dienste zur Verfugung. DieseDienste umfassen unter anderem HTTP, Mail, News, Datei- und Druckdien-ste sowie eine zentrale Benutzerverwaltung.

4

2.2 Administrative Tatigkeiten der Rechnerbetriebs-gruppe

Die Rechnerbetriebsgruppe stellt den Betrieb aller zentraler Rechenanlagenund Dienste sicher. Sie verwaltet den Zugang zu Rechnersystemen, vergibtund entzieht Benutzerkennungen und teilt Ressourcen und Prioritaten zu.Weiterhin ubernimmt sie die Betreuung der EDV-Arbeitsplatze in der Ver-waltung sowie in einigen Lehrstuhlen.

3 Soll-Konzept

3.1 Anforderungen

Durch Absprache mit den Administratoren der Rechnerbetriebsgruppe wur-den die Anforderungen und Kriteriern, die an ein Service Availability Mana-gement Konzept gestellt werden, ermittelt:

• Alle Dienste die via Netzwerk erreichbar sind sollen aktiv auf ihre kor-rekte Funktion hin gepruft werden.

• Lokale Ressourcen, wie beispielsweise freier Festplattenspeicher oderCPU-Auslastung, sollen von zentraler Stelle aus uber das Netzwerkuberwacht werden konnen.

• Lokale Prozesse, die keine Netzwerkschnittstelle bieten, sollen auf Vor-handensein gepruft werden.

• Das System soll flexibel an neue Anforderungen angepasst werden kon-nen.

• Der aktuelle Zustand aller uberwachten Objekte soll zu jedem Zeit-punkt von jedem Ort uber ein Webinterface abrufbar sein. Dieser Zu-gang ist mit einem Passwort vor unauthorisiertem Zugriff zu schutzen.

• Es sollen verschiedene Eskalationsstufen definiert werden konnen.

• Bei Problemen sollen die zustandigen Administratoren per E-Mail oder,bei anhaltenden Fehlerzustanden außerhalb der Dienstzeiten, auch viaSMS benachrichtigt werden konnen.

• Die Software soll frei und im Quellcode verfugbar sein.

5

4 Planung der Implementierung

4.1 Auswahl der Software

Es gilt eine passende Software fur ein Service Availability Management Sy-stem zu finden, die den gestellten Anforderungen gerecht wird.

Nagios wird diesen Anforderungen voll gerecht. Durch die interne Dreitei-lung in das Nagios-Kernprogramm, das die Zeitplanung und Ausfuhrung derServicechecks sowie die Ereignisbehandlung ubernimmt, die CGI-Programmefur die Webdarstellung und die Nagios-Plugins, die zum Prufen der Dien-ste dienen, ist Nagios einfach und flexibel erweiterbar. Um beispielsweiseeinen vollig neuen Dienst uberprufen zu konnen, muss lediglich ein passen-des Plugin programmiert werden. Es sind keine Anderungen am Basispro-gamm notwendig. Da sowohl das Nagios-Basisprogramm als auch die Plug-ins im Quelltext vorliegen ist es problemlos auf verschiedene UNIX-artigeSysteme portierbar. Dies erleichtert den Einsatz von Nagios in der hetero-genen Systemumgebung (SUN Solaris und Linux) der Technischen Fakultat.Des Weiteren bietet Nagios mit Hilfe der Benutzerverwaltung des Webser-vers die Moglichkeit eine Rechtestruktur auf der Weboberflache zu imple-mentieren, die einen fakultatsweiten Einsatz mit delegierten Kompetenzenermoglicht. Die Kommandos fur die Problembenachrichtigung konnen freigewahlt werden, so dass beliebige Formen der Benachrichtigung (E-Mail,SMB-Nachrichten, SMS, Pager, etc.) moglich sind.

4.2 Auswahl der Hardware

Als Server kommt ein vorhandener SUN Enterprise 450 Server zum Einsatz.Der Server verfugt uber zwei Prozessoren, zwei Gigabyte Hauptspeicher undein 1000MBit/s Netzwerkinterface. Auf dem System ist bereits ein Webserverfur die Internetprasenz der Technischen Fakultat installiert. Dieser soll dannauch die Bereitstellung der Weboberflache mittels eines vituellen Netzwerk-interfaces ubernehmen. Der Server hat genugend freie Rechenkapazitat furdie Ausfuhrung der Servicechecks.

6

4.3 Aufstellung der zu uberwachenden Dienste

Folgende Dienste sollen von Nagios auf ihre Verfugbarkeit uberwacht werden:

Host(s) IP-Addresse Dienst Typ BeschreibungAlle SUN- ssh Netzwerk Secure ShellWorkstations disk Lokal Festplattenauslastung

zombies Lokal ZombieprozesseAlle Switches ping Netzwerk Erreichbarkeitbatman 134.245.244.176 ssh Netzwerk Secure Shell

smtp Netzwerk SMTP-Serverpop3 Netzwerk POP3-Server

crest 134.245.244.131 ssh Netzwerk Secure Shelldns Netzwerk DNS-Serversmtp Netzwerk SMTP-Serverimaps Netzwerk IMAP-Server mit SSLnews Netzwerk News-Serveramavis Lokal Mail-Virenscannerdisk Lokal Festplattenauslastungsds Lokal Festplattenspiegelungzombies Lokal Zombieprozesse

hope 134.245.244.140 ssh Netzwerk Secure Shellhttp Netzwerk Webserversquid Netzwerk Webcachedns Netzwerk DNS-Serverdisk Lokal Festplattenauslastungsds Lokal Festplattenspiegelungzombies Lokal Zombieprozesse

mort 134.245.244.155 ssh Netzwerk Secure Shellsnort Lokal Snort IDSdisk Lokal Festplattenauslastungzombies Lokal Zombieprozesse

7

5 Realisierung

Im Folgenden wird die Realisierung des Projektes in chronologischer Reihen-folge beschrieben.

5.1 Vorbereitung der Installation

Zunachst wird ein neuer Benutzer fur das Nagios-System angelegt. Spatersollen die Nagios-Prozesse unter dessen Kennung laufen. Der neue Benut-zer erhalt den Namen nagios mit UID 775 die primare Gruppe des Benut-zers heißt auch nagios (GID 775) und wird ebenfalls angelegt. Das Home-Verzeichnis fur den Benutzer ist /home/nagios und wird mittels NFS an alleUNIX-Rechner exportiert.

5.2 Ubersetzen des Nagios-Quelltextes

Der Quelltext fur Nagios Version 1.0b6 wird heruntergeladen und entpackt.Auf der obersten Ebene im Nagios-Quellbaum wird als erstes das Shell-Skriptconfigure ausgefuhrt. configure versucht den Systemtyp sowie die Prozes-sorarchitektur des Systems zu ermitteln und pruft weiterhin die Funktionund das Vorhandensein verschiedener Bibliotheks- und Systemaufrufe. Demconfigure-Skript werden verschiedene Parameter ubergeben:

–prefix=/home/nagios Die Software soll unterhalb von /home/nagios in-stalliert werden.

–with-cgiurl=/cgi-bin/cgiwrap/nagios Die URL unter der spater dieCGI-Programme fur das Webinterface liegen.

–with-htmurl=/ Die URL unter der die html-Seiten fur das Webinterfaceliegen.

–with-nagios-user=nagios Die Nagios-Prozesse sollen unter der Userken-nung Nagios laufen.

–with-nagios-group=nagios Die Nagios-Prozesse sollen unter der Grup-penkennung Nagios laufen.

–with-openssl=/usr/local/ssl Der Installationsort der OpenSSL Biblio-thek fur SSL-Verschlusselung

Nach dem Ablaufen von configure startet der Aufruf von make die Uber-setzung des Quelltexts. Danach wird Nagios durch den Aufruf von make

install in das Verzeichnis /home/nagios installiert. Dies schließt die In-stallation des Nagios Basispakets ab.

8

5.3 Konfiguration des Webservers

Fur die Bereitstellung der Weboberflache muss die Konfiguration des bereitsinstallierten Webservers angepasst werden. Da die Oberflache spater unterhttp://nagios.tf.uni-kiel.de erreichbar sein soll, wird zunachst ein vir-tuelles Netzwerkinterface erstellt. Der IP-Addresse des Interfaces wird derDNS-Name nagios.tf.uni-kiel.de zugewiesen. In der Konfigurationsdateides Webservers werden Eintrage fur den neuen virtuellen Host angelegt. EinAuszug aus der Datei findet sich im Anhang C. Danach wird fur die Benut-zerauthentifizierung die Datei htpasswd.users angelegt. Dort wird der Be-nutzer admin mit Passwort eingetragen. Zum Aktivieren der Eintrage mussder Webserver durch Aufruf von apachectl restart neu gestartet werden.Nach dem Neustart wird die prinzipielle Funktion der Weboberflache duchAufruf von http://nagios.tf.uni-kiel.de im Webbrowser getestet. DieNagios-Startseite wird angezeigt, die Konfiguration war erfolgreich.

5.4 Konfiguration der CGI-Programme und des CGI-Wrappers

Fur die Generierung aktueller Statusberichte werden bei Anforderung desentsprechenden Berichtes im Webbrowser CGI-Programme auf dem Webser-ver ausgefuhrt. Die Programme sind im Nagios-Basispaket enthalten undbefinden sich nach der Installation in /home/nagios/sbin. Standardmaßigwurden diese Skripte mit der Benutzerkennung (UID) des Webservers aus-gefuhrt werden. Da die Programme allerdings auf Daten zugreifen mussen,die nur fur den Benutzer nagios lesbar sein sollen, wird ein CGI-Wrapper ver-wendet. Der CGI-Wrapper ist ein Programm, das die entsprechenden CGI-Programme als Benutzer nagios ausfuhrt. Weiterhin erhalt der Benutzer na-gios die Berechtigung zum Ausfuhren von CGI-Programmen.

5.5 Installation und Funktionstest der Nagios-Plugins

Alle Dienst- und Ressourcentests sind in Plugins ausgelagert, das bisher in-stallierte Nagios-Kernprogramm ist lediglich fur die Ausfuhrung der Pluginsund die Webdarstellung verantwortlich. Die Nagios-Plugins werden analogzum Nagios-Basispaket durch die Aufrufe von configure, make und make

install ubersetzt und nach /home/nagios/libexec installiert. Die korrek-te Funktion einzelner Plugins setzt teilweise zusatzliche Software voraus,die zunachst installiert werden musste. Beispielsweise benotigt das Plugincheck radius, das die Verfugbarkeit eines RADIUS-Dienstes pruft, das Pa-ket ’libradiusclient-0.50’. Bei anderen Plugins mussten zunachst Teile des

9

Quelltextes angepasst werden, da mitunter Kommandozeilenparameter gean-dert werden mussten. Das Plugin check hpjd verwendet das externe Kom-mando snmpget um via SNMP den Status eines HP Druckers abzufragen.Hier war etwas Anpassungsarbeit am Quelltext notig, da die installierte Ver-sion von snmpget andere Kommandozeilenparameter erwartete als die vomPlugin vorausgesetzte.Nach der Installation wird zunachst die korrekte Funktion der einzelnen Plug-ins gepruft. Hierzu werden die Plugins manuell an der Kommandozeile auf-gerufen und die Ausgabe ausgewertet. Es wurde festgestellt, dass das Plugincheck disk, das die Ausgabe des Systembefehls df -k verarbeitet um denfreien Festplattenspeicher zu ermitteln, alle gemounteten Dateisysteme (alsoauch via NFS uber das Netzwerk gemountete) pruft. Dies ist ungunstig, danur lokale Dateisysteme getestet werden sollen. Durch Umschreiben des Be-fehls 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-Auslas-tung uber das Netzwerk uberwachen zu konnen wird auf den Clients einZusatzmodul, der Nagios Remote Plugin Executor (nrpe), installiert. Nrpewird mittels configure, make und make install nach /home/nagios/bin

installiert und ist, da /home/nagios via NFS an alle UNIX-Rechner expor-tiert wird, dann auf allen Nagios-Clients verfugbar. Auf den Clients wird dernrpe vom Internet Super Server, dem inetd, gestartet. Dazu wird der nrpe indie jeweilige Konfigurationsdatei des inetd eingetragen. Der Zugriff auf nr-pe ist uber einen TCP-Wrapper abgesichert. In der Konfigurationsdatei desWrappers wird der Zugriff auf nrpe nur vom Nagios-Server aus erlaubt. Nacheinem Neustart des inetd wartet nrpe auf Port 5666 auf Verbindungen vomNagios-Server.Die auszufuhrenden Servicechecks werden in die Datei nrpe.cfg eingetragen,damit nrpe korrekt arbeitet. Die Syntax der Eintrage 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 gepruft werden. Ein Test mit dem obrigen Aufrufverlief wie erwartet. Nrpe arbeitet korrekt.

10

5.7 Konfiguration des Nagios-Basispaketes

Die Konfigurationsdateien fur das Nagios-Basispaket befinden sich im Ver-zeichnis /home/nagios/etc. Es gibt 4 Arten von Konfigurationsdateien:

Hauptkonfigurationsdatei In der Hauptkonfigurationsdatei nagios.cfgwerden die Einstellungen fur das Nagios-Basisprogramm festgelegt. Da-zu gehoren beispielsweise Angaben zur Planung der einzelnen Service-checks, der Speicherort der Logdatei und die Benutzerkennung unterder das Nagios-Basisprogramm und die Plugins ausgefuhrt werden.

CGI Konfigurationsdatei In der Datei cgi.cfg stehen Einstellungen furdie CGI-Programme. Unter anderem werden hier die Zugriffsrechte aufdie Programme festgelegt. Da es in unserem Fall nur den Benutzeradmin gibt, bekommt dieser alle Rechte zugewiesen.

Ressourcen-Konfigurationsdatei In dieser Datei konnen Makros und Va-riablen definiert werden. In unserem Fall wird hier nur die Variable$USER1$ auf den Plugin-Pfad /home/nagios/libexec gesetzt.

Objekt-Konfigurationsdateien Die zu uberwachenden Hosts, zu prufen-de Dienste, Kontakte, Kontaktgruppen usw. werden in jeweils eine Da-tei eingetragen. Die Eintrage werden auch als Objekte bezeichnet. Auchdie Kommandos fur die einzelnen Servicechecks sowie fur die Benach-richtigungen werden in Objektkonfigurationsdateien erfasst. Es bestehtdie Moglichkeit Eintrage als Vorlagen zu kennzeichnen, um Gemein-samkeiten zwischen einzelnen Objekten nur einmal erfassen zu mussen.Beispieleintrage sind in Anhang C zu finden.

5.8 Erster Start von nagios und Funktionstests

Nach dem Anpassen der Konfiguration wird die syntaktische Korrektheitund Konsistenz der verschiedenen Dateien untereinander mit dem Befehlnagios -v nagios.cfg uberpruft. Hier traten zunachst einige Fehler (Feh-lende Klammern, Tippfehler...) auf. Nach der Korrektur wird Nagios mitder Befehlszeile nagios nagios.cfg -d gestartet. Der Parameter -d be-wirkt, dass der Prozess als Daemon, nicht interaktiv im Hintergrund star-tet. Nach dem ersten Start benotigt Nagios etwas Zeit (ca. 10 Minuten beider vorliegenden Anzahl von Service-Checks) um die initialen Dienst- undSystemzustande festzustellen. Nach Ablauf dieser Zeitspanne wird als er-stes die korrekte Funktion der Weboberflache und der CGI-Programme ge-testet. Dies geschieht durch Abrufen der einzelnen Berichte im Webbrowser.

11

Zunachst funktionierten einige CGI-Programme nicht wie erwartet. Die Feh-leranalyse ergab, dass die betreffenden Programme benotigte Bibliothekennicht finden konnten. Dies war auf fehlende Parameter bei der Kompilierungzuruckzufuhren. Nach dem Neuubersetzen der entsprechenden Programmemit korrekten Parametern funktionierte alles wie erwartet. Nach diesem er-sten erfolgreichen Test werden verschiedene Testszenarien zur Uberprufungder korrekten Funktion der Service- und Hostchecks sowie der Fehlerbenach-richtigungen durchgespielt:

• Gezieltes Abschalten von Diensten

• Gezieltes Unterbrechen von Netzwerkverbindungen

• Leeren des Papierschachts des Druckers

Die maximal beobachtete Latenzzeit zwischen Auftreten und Erkennendes Fehlers betrug zwei Minuten. Die Weboberflache zeigte den Fehlerstatuskorrekt an. Fehlerbenachrichtigungen wurden an die entsprechenden Kontak-te versandt.

5.9 Abschließende Arbeiten

Um zu erreichen, dass Nagios bei einem Neustart des Servers automatischstartet wird noch ein Startskript angelegt. Die Kommandos zum Anlegendes virtuellen Interfaces fur die Weboberflache beim Systemstart werden indas Startskript des Webservers eingetragen. Die Nagios-Installation ist nunvollstandig abgeschlossen.

12

6 Arbeiten mit Nagios

6.1 Bedienung der Weboberflache

Nach dem Aufruf von nagios.tf.uni-kiel.de im Webbrowser erscheintzunachst ein Dialogfeld zur Passworteingabe. Nach erfolgreicher Uberprufungdes Passworts gelangt man auf die Startseite.

Hier erhalt man einen kurzen Uberblick uber den aktuellen Systemstatus.Im linken Frame befinden sich weitere Auswahlmoglichkeiten, mit denen de-tailliertere Berichte abgefragt werden konnen. Uber den Punkt Service Detailwerden erweiterte Informationen uber einzelne Dienste angezeigt.

13

Dies ist die Detailansicht des Dienstes SMTP auf dem Server crest. Un-ter Service State Information finden sich viele Informationen bezuglich desDienstzustands und der letzten Prufung. Auf der rechten Seite unter ServiceCommands besteht die Moglichkeit Befehle an das Nagios-Basisprogramm zusenden, um beispielsweise eine sofortige Prufung des Dienstes zu erzwingenoder Fehlerbenachrichtigungen fur den Dienst abzuschalten.

14

Des Weiteren besteht uber die Weboberflache die Moglichkeit, sich Stati-stiken bezuglich der Verfugbarkeit von Diensten anzeigen zu lassen.

Dies ist die Verfugbarkeitsstatistik fur den Dienst SMTP auf dem Hostbatman uber den Zeitraum von sieben Tagen. Der Balken zeigt die Verfugbar-keit des Dienstes, Ausfallzeiten sind in Rot markiert. Die Zeit, in der derDienst erreichbar war ist grun gekennzeichnet. Weiter unten auf der Seitelasst sich die Gesamtverfugbarkeit absolut und relativ in Prozent ablesen.

7 Bewertung / Fazit

7.1 Funktionalitat der Implementierung

Die Nagios-Implementierung konnte bezuglich ihrer Funktionalitat voll uber-zeugen. Wahrend der Evaluierungsphase von einer Woche wurden durch Na-gios bisher noch nicht bemerkte Dienst- und Ressourcenprobleme entdeckt.So gibt es beispielsweise auf einem Linux-Server Erreichbarkeitsprobleme

15

der Netzwerkdienste, wahrend der nachtlichen Datensicherung. Dies ist ver-mutlich auf eine unperformante TCP/IP-Implementierung des Linux zuruck-zufuhren. Des Weiteren hat Nagios fruhzeitig Kapazitatsprobleme auf demDateisystem fur die Mailboxen der Benutzer erkannt und gemeldet. Um denfreien Speicherplatz zu erhohen wurde das Dateisystem vergrossert, bevor eszu Problemen kam.

7.2 Performance

Wahrend der Evaluierungsphase wurde die CPU- und Netzwerkbelastung desNagios-Servers sowie der uberwachten Clients besonders uberwacht. Es wur-de, obwohl etwa alle zwei Sekunden ein Servicecheck ausgefuhrt wird, nur einegeringfugige Erhohung der CPU- und Netzwerklast festgestellt. Ein einzel-ner Servicecheck dauert durchschnittlich eine Sekunde. Auch auf den Clientswurden keine auffallenden Lastspitzen beobachtet. Daraus ist zu schließen,dass die Verteilung der Checks zwischen den Clients gut ausgewogen ist.

16

A Projektverlauf

Projektphase Zeitraum

Einarbeitung und Aneignen von Hintergrundwissen 2 Std.

Ist–Analyse 2 Std.

Bestandsaufnahme und Analyse der bisherigen Administrationsund Dienststruktur

Soll–Konzept 2,5 Std.Absprache mit den Mitarbeitern der Rechnerbetriebsgruppeuber die Ziele und Anforderungen des Projekts. Gruppierung derrelevanten Dienste.

Planung der Implementierung 3 Std.

Erstellung des Grundkonzepts, Planen der notwendigen Schritte.

Durchfuhrung und Realisierung 12,5 Std.

Installation und Konfiguration des Nagios-Basispaketes und derPlugins, Konfiguration des vorhandenen Webservers.

Funktionstests 1 Std.

Bewertung / Fazit 2 Std.

Beurteilung der Implementierung hinsichtlich Funktionalitatund Performanceauswirkungen.

Erstellung der Projektdokumentation 10 Std.

Gesamtzeit: 35 Std.

B Hintergrundwissen

B.1 Funktionstheorie von Nagios

Eine Hauptfunktion des Nagios-Basisprogramms ist die Zeitplanung der Ser-vicechecks. Nagios versucht die Last fur die zu prufenden Clients durch soge-nanntes Service Check Interleaving moglichst gleichmaßig zu verteilen. WennBeispielsweise drei Hosts mit je drei Diensten gepruft werden sollen ist diePrufungsreihenfolge:

Host1, Dienst1; Host2, Dienst1; Host3, Dienst1; Host1, Dienst2...

Der Ruckgabewert eines Servicechecks landet zunachst in der Ereigniswarte-schlange (Event Queue). Der Inhalt der Queue wird etwa alle zehn Sekundenbearbeitet und die Queue geleert. Liefert ein bestimmter Servicecheck einen

17

Fehlerzustand zuruck wird, nachdem die in retry check interval angege-bene Zeitdauer verstrichen ist ein weiterer Check durchgefuhrt. Dies wirdin der Nagios-Terminologie als Soft Error State, weicher Fehlerstatus, be-zeichnet. Andert sich auch nach zwei weiteren Prufungen nichts am Zu-stand des Dienstes, geht Nagios in einen Hard Error State, harten Fehl-erstatus. Die entsprechenden Kontaktgruppen werden uber den jeweiligennotification command benachrichtigt. Sobald der Zustand des Dienstes kei-nen Fehler mehr aufweist geht Nagios zuruck in den OK Zustand. Wiederumwerden die entsprechenden Kontaktgruppen uber die Zustandanderung in-formiert.

B.2 Glossar

CGI-Programme/Skripte Uber das Common Gateway Interface bestehtdie Moglichkeit Programme auf dem Webserver auszufuhren um Web-seiten dynamisch zu generieren. Die CGI–Programme von Nagios er-stellen aus den gesammelten Daten Statusberichte.

DNS Der Domain Name Service ist ein Dienst zur Auflosung von Hostnamenin IP-Adressen und umgekehrt.

Domane Eine Gruppe von Servern und anderen Netzwerkobjekten untereinheitlichem Namen.

Domain-Controller Ein Server der die Benutzer und Rechner fur eineDomane authentifiziert. Jede Domane muss mindestens einen Domain-Controller fur die Verwaltung besitzen.

GID Unter UNIX ist jeder Benutzer Mitglied in zumindest einer Gruppe.Jede Gruppe hat zusatzlich zu ihrem Namen eine numerische Gruppen-ID, die fur die interne Verwaltung benotigt wird.

Host-Check Ein Hostcheck uberpruft die prinzipielle Erreichbarkeit einesHosts uber das Netzwerk. Im Gegensatz zu Servicechecks werden Host-checks nur durchgefuhrt, wenn ein Servicecheck fehlschlagt. Dies dientder Prufung ob nur der Dienst oder der ganze Host von dem Problembetroffen ist.

inetd Der Internet Super Server (inetd) bindet Ports fur verschiedene Netz-werkdienste wie beispielsweise POP3, Telnet, rsh. Bei einer Verbindungauf einen Port startet der inetd bedarfsweise den eigentlichen Serverpro-zess, der dann die Anfrage bearbeitet. Die durch den inetd gestartetenDienste konnen wahlweise durch TCP-Wrapper abgesichert werden.

18

NFS Das Network File System (NFS) dient unter UNIX zur Bereitstellungvon Dateisystemen uber das Netzwerk. Im Gegensatz zu Netzwerklauf-werken unter Windows ist die Anbindung transparent, der Benutzerweiß nicht ob er gerade auf ein lokales oder entferntes Dateisystemschreibt.

RADIUS Das RADIUS-Protokoll dient der Authentifizierung von Einwahl-benutzern.

Service-Check Ein Servicecheck ist die vom Nagios-Basisprogramm initi-ierte Uberprufung eines bestimmten Dienstes oder einer bestimmtenRessource. Servicechecks werden automatisch in vorher definierten Zeit-abstanden geplant und durchgefuhrt.

Service Availability Management Service Availability Management be-deutet die Verfugbarkeit von Netzwerkdiensten und Ressourcen zu uber-wachen, um Ausfallzeiten moglichst gering zu halten.

SNMP Das Simple Network Management Protocol dient zur Verwaltungvon Netzwerkgeraten. Alle Parameter die uber das Netzwerk ausgelesenund gesetzt werden konnen sind in der Management Information Basefur das Gerat eingetragen.

TCP-Wrapper TCP-Wrapper dienen der Zugriffskontrolle auf TCP-Ebene.Anhand von Schwarz- und Weißlisten in den Dateien hosts.deny undhosts.allow wird entschieden, ob ein bestimmter Host auf einen be-stimmten Dienst zugreifen darf.

UID Unter UNIX bekommt jeder Benutzer zusatzlich zu seinem Login-Namen eine eindeutige numerische User-ID (UID). Diese UID wird furdie interne Verwaltung der User benotigt.

Zombies Zombieprozesse sind Kindprozesse, die Aufgrund eines nicht er-folgten wait-Systemaufrufs des Vaterprozesses nach Beendigung desProzesslaufes ihren Ruckgabewert nicht abliefern konnten. Diese Pro-zesse werden weiterhin in der Prozesstabelle gefuhrt. Wenn der Va-terprozess beendet wird erbt der init-Prozess alle Kindprozesse. Initfuhrt regelmassig wait-Aufrufe auf seine Kindprozesse aus. Erst dannverschwindet der Zombieprozess aus der Prozesstabelle.

19

C Konfigurationsdateien

C.1 httpd.conf

In der Konfigurationsdatei des Webservers httpd.conf wurden folgende Ein-trage fur die Weboberflache 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 Eintrage bewirken, dass ein virtueller Host mit dem vollstandigen Ser-vernamen nagios.tf.uni-kiel.de auf der IP-Adresse 134.245.244.162 an-gelegt wird. Ein Zugriff auf die Verzeichnisse mit den HTML-Dokumentenund CGI-Programmen ist erst nach erfolgreicher Passwortuberprufung er-laubt.

C.2 contacts.cfg und contactgroups.cfg

In der Datei contacts.cfg werden die einzelnen Kontaktpersonen, also dieMitglieder der Rechnerbetriebsgruppe eingetragen. Die Eintrage sind in derForm:

define contact{contact name tig

20

alias Tim Grebien

service notification period 24x7

host notification period 24x7

service notification options w,u,c,r

host notification options d,u,r

service notification commands notify-by-email

host notification commands host-notify-by-email

email tig@tf.uni-kiel.de

}

Es wird ein Kontakt tig eingerichtet. tig wird zu jeder Zeit uber alle Zu-standsanderungen per E-Mail an tig@tf.uni-kiel.de unterrichtet.In der Datei contactgroups.cfg werden die einzelnen Kontakte in Kontakt-gruppen organisiert. Es werden zwei Gruppen angelegt. Zum einen die Grup-pe rbg, in der alle RBG-Mitglieder vertreten sind. Zum Anderen die Gruppeazubi in der nur die RBG-Auszubildenden eingetragen sind.

C.3 checkcommands.cfg

In dieser Datei werden die Kommandozeilen fur die einzelnen Servicechecksfestgelegt. Beispieleintrag:

define command{command name check nntp

command line $USER1$/check nntp -H $HOSTADDRESS$

}

Es wird ein Objekt vom Typ command erzeugt. command name ist derName uber den aus anderen Konfigurationsdateien auf das Objekt zugegriffenwird. command line ist der Befehl der beim Zugriff auf das Objekt ausgefuhrtwird. $USER1$ ist ein Makro, dass nach /home/nagios/libexec aufgelostwird. $HOSTADDRESS$ wird in die IP-Addresse des zu prufenden Hostsaufgelost.Fur jeden Diensttyp wird ein Objekt vom Typ command angelegt.

C.4 hosts.cfg und hostgroups.cfg

In dieser Datei wird zunachst ein generischer Host als Vorlage angelegt. Dannwird fur jeden zu prufenden Host ein Objekt angelegt, welches die Eigenschaf-ten des generischen Hosts erbt. Eintrag fur 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 information1

max check attempts 10

notification interval 60

notification period 24x7

notification options d,u,r

register 0

}

Beispieleintrag fur 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 fur den Host balu angelegt. DerHost hat die IP-Addresse 134.245.242.10. Der Eintrag use generic-host

bewirkt, dass alle weiteren Parameter von der Vorlage generic-host uber-nommen werden. Falls ein Servicecheck fehlschlagt wird mit dem in der Dateicheckcommands.cfg definierten Befehl check-host-alive mitttels ICMP Echo-Reply gepruft, ob der Host prinzipiell uber das Netzwerk erreichbar ist.Alle eingetragenen Hosts konnen in der Datei hostgroups.cfg verschiedenenHostgruppen hinzugefugt werden. In der Hostgruppe sparcs sind beispiels-weise alle SUN-Rechner eingetragen.

C.5 services.cfg

Hier werden alle in 4.3 aufgelisteten Dienste eingetragen. Wie in der Dateihosts.cfg wird zunachst ein generischer Dienst als Vorlage fur alle weiterenDienst-Objekte erstellt. Der generische Eintrag:

22

define service{name generic-service

active checks enabled 1

passive checks enabled 1

parallelize check 1

obsess over service 1

check freshness 1

notifications enabled 1

event handler enabled 1

flap detection enabled 0

process perf data 1

retain status information 1

retain nonstatus information 1

contact groups rbg

max check attempts 3

normal check interval 3

retry check interval 1

notification interval 60

notification period 24x7

notification options w,u,c,r

check period 24x7

register 0

}

Die einzelnen Dienste werden dann so erfasst:

define service{use generic-service

host name crest

service description SMTP

check command check smtp

}

In diesem Beispiel wird der Dienst SMTP auf dem Host crest mit demBefehl check smtp getestet. Alle weiteren Konfigurationsparameter werdenvon der Vorlage generic-service ubernommen.

23

C.6 escalations.cfg

In dieser Datei werden Eskalationen definiert. Ist beispielsweise der Papier-schacht des Druckers leer, wird zuerst die Kontaktgruppe azubi benachrich-tigt. Ab der zweiten Benachrichtigung gehen alle weitern Nachrichten an dieKontaktgruppe rbg.Dies wird mit folgendem Eintrag erreicht:

define serviceescalation{host name nphpdek

service description HP Laserjet 4000

first notification 2

last notification 0

contact groups rbg

notification interval 240

}

C.7 misccommands.cfg

In der Datei misccommands.cfg werden spezielle Objekte vom Typ commanddefiniert. Dazu gehoren die Befehle notif-by-email und host-notify-by-emaildie bei Benachrichtigungen ausgefuhrt werden.

C.8 timeperiods.cfg

Hier werden Objekte vom Typ timeperiod definiert. Dies sind zum einen 24x7und zum anderen workhours. 24x7 bezeichnet 24 Stunden am Tag an jedemTag der Woche und workhours ist an Werktagen von 07:30–20:30 Uhr.

24