Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
5 Der Kernel
6 Die Grundlagen aus Anwendersicht
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP
20 DNS-Server
21 Secure Shell
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in die Sicherheit
33 Netzwerksicherheit überwachen
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Die Buch-DVDs
F Glossar
G Literatur
Stichwort

Download:
- ZIP, ca. 15,7 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Linux von Johannes Pl&ouml;tner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
geb., mit 2 DVDs
1302 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1704-0
Pfeil 33 Netzwerksicherheit überwachen
  Pfeil 33.1 Snort
    Pfeil 33.1.1 Aufbau der Intrusion Detection
    Pfeil 33.1.2 snort.conf
  Pfeil 33.2 Netzwerkmonitoring mit Nagios
    Pfeil 33.2.1 Die Installation
    Pfeil 33.2.2 Die Konfiguration
    Pfeil 33.2.3 Die Plugins
  Pfeil 33.3 Nmap: Der wichtigste Portscanner
    Pfeil 33.3.1 Prinzip eines Portscanners
    Pfeil 33.3.2 Techniken des Scannens
    Pfeil 33.3.3 Weiterer Informationsgewinn
    Pfeil 33.3.4 Nmap in der Praxis
  Pfeil 33.4 Nessus: Ein Security-Scanner
    Pfeil 33.4.1 Die Installation
    Pfeil 33.4.2 Die Konfiguration
    Pfeil 33.4.3 Nessus benutzen
  Pfeil 33.5 Sniffer
    Pfeil 33.5.1 tcpdump
    Pfeil 33.5.2 Wireshark (ehemals ethereal)
    Pfeil 33.5.3 dsniff
  Pfeil 33.6 Zusammenfassung


Galileo Computing - Zum Seitenanfang

33.2 Netzwerkmonitoring mit Nagios  Zur nächsten ÜberschriftZur vorigen Überschrift

Nagios (www.nagios.org) erfüllt als Nachfolger des populären NetSaint alle Anforderungen, die wir im letzten Abschnitt an ein Netzwerkmonitoringtool gestellt haben:

  • Überwachen von Rechnern und Diensten
    Man kann diverse Dienste (z. B. HTTP, SMTP, POP3, FTP, ...) sowie auch ganze Rechner (über PING) überwachen. Außerdem kann man auch Ressourcen wie Festplattenplatz, CPU-Auslastung oder den Speicherverbrauch kontrollieren.
  • Flexibles Benachrichtigungssystem
    Natürlich kann man auch konfigurieren, wer wie kontaktiert werden soll, wenn Probleme auftreten. Dazu gehört neben der obligatorischen E-Mail-Benachrichtigung auch der Support von SMS-Nachrichten oder von anderen benutzerdefinierten Möglichkeiten.
    • Die verschiedenen Benutzer des Systems kann man außerdem in unterschiedlichen Kontaktgruppen organisieren, auf die man die unterschiedlichen Problemfälle verteilen kann.
  • Pluginsystem und proaktive Problemlösung
    Über ein einfaches Pluginsystem kann man auch selbst Servicechecks schreiben, die dann von Nagios regelmäßig ausgeführt beziehungsweise überprüft werden.
    • Außerdem kann man mittels Event-Handlern auch einfache Maßnahmen zur proaktiven Problemlösung definieren.
  • Webinterface
    Neben den erwähnten Möglichkeiten der E-Mail-Benachrichtigungen kann man den Status der überwachten Systeme auch über ein State-of-the-art-Webinterface betrachten. Zu diesem gehört auch ein WML-Interface, sodass Sie den Status der Rechner selbst von unterwegs via Handy abfragen können.

Open Source!

Gehen wir also näher auf die Software ein. Nagios steht unter der GNU General Public License und ist damit als freie Software für jeden verfügbar. Als Voraussetzungen für die Installation genügen bereits ein einfacher Linux-Rechner mit Webserver (am besten Apache) sowie die GD-Bibliothek, die aber auch bei jeder Distribution mit dabei sein sollte.

Nachdem es installiert – und vor allem konfiguriert – worden ist, kann man sich mit Nagios nicht nur über aufgetretene Probleme informieren lassen, sondern sich auch schöne Statistiken ansehen.

Abbildung 33.1  Netzwerkmonitoring mit Nagios

Nur haben die Götter vor die Grafik leider die Konfiguration gesetzt, die bei einem Netzwerkmonitoringsystem natürlich nicht von selbst erfolgen kann. Aus diesem Grund wollen wir uns an dieser Stelle etwas näher mit dieser Thematik auseinandersetzen, da die Maßnahmen, die sich aus den Meldungen ergeben, wieder vollkommen in den Aufgabenbereich eines Systemadministrators fallen.

Da die Konfiguration also naturgemäß recht komplex werden kann, verweisen wir für Detailfragen wieder einmal auf die Webseite des Projektes, www.nagios.org, und auf die dort verlinkte ausführliche Dokumentation.


Galileo Computing - Zum Seitenanfang

33.2.1 Die Installation  Zur nächsten ÜberschriftZur vorigen Überschrift

Beginnen wir also mit der Installation. Am besten laden Sie sich die aktuellste Version von der Webseite herunter und entpacken die Dateien in einem Verzeichnis Ihrer Wahl. Anschließend sollten Sie einen eigenen Benutzer samt Gruppe für die Software und das spätere Installationsverzeichnis – am besten /usr/local/nagios – anlegen.

# tar -xzf nagios-1.1.tar.gz
# mkdir /usr/local/nagios
# adduser nagios

Listing 33.14  Die eigentliche Installation vorbereiten

Quelltext konfigurieren

Als Nächstes kann man in dem entpackten Verzeichnis das configure-Skript aufrufen, bei dem man einige Parameter nicht vergessen sollte:

../configure --prefix=prefix --with-cgiurl=cgiurl

--with-htmurl=htmurl --with-nagios-user=user

--with-nagios-grp=group

Listing 33.15  Die Software vor dem Übersetzen an das eigene System anpassen

  • Mit »prefix« gibt man das Installationsverzeichnis an, normalerweise ist das /usr/local/nagios.
  • Die »cgiurl« wird die URL angeben, unter der man später die CGIs ansprechen will, normalerweise /nagios/cgi-bin [Achtung: Am Ende der URL darf kein Slash stehen!].
  • Analog gibt die »htmlurl« die URL der späteren HTML-Seiten an, normalerweise /nagios/.
  • Schließlich sollte man den eben angelegten Benutzer samt dessen Gruppe (standardmäßig ist beides »nagios«) angeben.

Quelltext übersetzen

Als Nächstes kann man die Software übersetzen und die entsprechenden Dateien an ihren zukünftigen Platz im Dateisystem verschieben. Falls gewünscht, kann man sich auch ein Initskript erstellen lassen:

# make
# make install
# make install-init

Listing 33.16  Übersetzen, installieren und Initskript erstellen

Möchte man auch noch einen Satz von Standardkonfigurationsdateien installieren, die man dann später nur noch anpassen muss, reicht es aus, make erneut zu bemühen:

# make config
# make install-config

Listing 33.17  Beispielkonfiguration installieren

Verzeichnisstruktur

Wechselt man nun mit cd /usr/local/nagios in das Installationsverzeichnis von Nagios, kann man sich dort die Verzeichnisstruktur der Software näher ansehen:


Tabelle 33.1  Die Verzeichnisstruktur

Verzeichnis Beschreibung

bin/

Der Nagios-Server an sich befindet sich in diesem Verzeichnis.

etc/

Hier befinden sich die Konfigurationsdateien. Dazu später mehr.

libexec/

In dieses Verzeichnis sollten die Plugins installiert werden.

sbin/

Die CGIs für das Webinterface befinden sich hier.

share/

die HTML-Dateien für das Webinterface sowie die Dokumentation

var/

das Verzeichnis für die Logfiles


Installieren der Plugins

Wie bereits aus der Tabelle zur Verzeichnisstruktur ersichtlich ist, müssen als Nächstes die Plugins separat heruntergeladen und ins Verzeichnis libexec/ installiert werden.

Plugins für Servicechecks

Die Plugins sind dabei entweder Skripte oder zu kompilierende Binarys, die die Service- und Hostchecks erst durchführen. Natürlich können Sie so, wenn Sie sich bereits fertige Skripte oder Codes als Vorbild nehmen, auch eigene Plugins für Nagios schreiben.

Das Webinterface

Nachdem wir die Software übersetzt und die Plugins installiert haben, ist als Nächstes das Webinterface an der Reihe. Es muss dem Webserver – in unserem Beispiel wollen wir auf den viel genutzten Apache eingehen – »gesagt« werden, wo die CGI-Skripte und die HTML-Dateien zu finden sind. Immerhin haben wir diese ja nicht in die DocumentRoot, also das »Stammverzeichnis des Webservers« installiert.

Webserver vorbereiten

Beginnen wir dazu mit dem Alias für die CGI-Skripte. Die folgenden Zeilen bewirken, dass wir die URL /nagios/cgi-bin ansprechen können, wobei in Wirklichkeit auf die Skripte in /usr/local/nagios/sbin zugegriffen wird. Dieses Verzeichnis wird beim Kompilieren durch den Parameter --cgiurl angegeben:

ScriptAlias /nagios/cgi-bin/ /usr/local/nagios/sbin/
<Directory "/usr/local/nagios/sbin/">
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

Listing 33.18  Den Alias für die CGI-Skripte setzen

Als Nächstes müssen wir noch die --htmlurl /nagios auf das Verzeichnis share/ unserer Installation umleiten:

Alias /nagios/ /usr/local/nagios/share/
<Directory "/usr/local/nagios/share">
Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all
</Directory>

Listing 33.19  Den Alias für die Nagios-HTML-Dateien setzen

Nun kann man den Apache mit dem Befehl

# apachectl restart

Listing 33.20  Apache neu starten

neu starten und bereits versuchen, das Webinterface über

http://localhost/nagios/

anzusprechen. Natürlich werden noch keine Informationen angezeigt, da das Monitoring erst noch konfiguriert werden muss; das Webinterface kann man aber schon betrachten.

Passwortschutz

Meistens ist es ganz sinnvoll, den Zugriff auf die Nagios-Software per htaccess zu beschränken. Um diesen Schutz zu konfigurieren, muss man zuerst im share/- und sbin/-Verzeichnis der Nagios-Installation eine .htaccess-Datei mit folgendem Inhalt anlegen:

AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
require valid-user

Listing 33.21  Die .htaccess-Datei

Mit dem Kommando htpasswd kann man anschließend die /usr/local/nagios/etc/ htpasswd.users mit dem -c-Switch anlegen und mit Benutzernamen und Passwörtern füllen:

htpasswd -c /usr/local/nagios/etc/htpasswd.users

nagiosadmin

Listing 33.22  Den User »nagiosadmin« hinzufügen

Möchte man weitere Nutzer hinzufügen, so entfällt die Option -c, und man gibt als einziges Argument den anzulegenden Benutzernamen an.


Galileo Computing - Zum Seitenanfang

33.2.2 Die Konfiguration  Zur nächsten ÜberschriftZur vorigen Überschrift

Nach der Installation läuft zwar Nagios bereits, aber ein Monitoring findet noch nicht statt. Dazu muss das System erst korrekt konfiguriert werden, was in diesem Abschnitt besprochen werden soll. Am besten beginnen wir dazu mit einem Überblick über die wichtigsten der zahlreichen Konfigurationsdateien:

Hauptkonfiguration

  • etc/nagios.cfg
    In der Hauptkonfigurationsdatei kann man alle möglichen Einstellungen für Nagios vornehmen, wie beispielsweise wo die restlichen Konfigurationsdateien zu finden sind, welche Logfiles angelegt werden sollen oder wie sich das Monitoring bezüglich der einzelnen Checks genau verhalten soll.
  • etc/cgi.cfg
    In dieser Konfigurationsdatei kann man zahlreiche Einstellungen für die CGIs treffen, so zum Beispiel, welche Nagios-Benutzer auf welche Funktionen Zugriff erhalten, falls eine Authentifizierung verwendet wird.
  • Resource Files
    Neben den beiden Hauptkonfigurationsdateien gibt es weitere Konfigurationsdateien, die man dann über die etc/nagios.cfg einbinden kann. Ein Typ dieser zusätzlichen Konfigurationseinstellungen sind die Resource Files (meist nur etc/resource.cfg), in denen man sensible Informationen wie Logins für eine Datenbank oder auch Makros speichern kann. Aus Sicherheitsgründen sind diese Informationen den CGIs nicht zugänglich.

Objekte definieren

  • Object Configuration Files
    Diese Dateien bindet man ebenfalls über die nagios.cfg ein, und hier endlich definiert man das eigentliche Monitoring. Für Nagios ist es egal, ob Sie einen Service (Dienst) oder einen zu überwachenden Rechner definieren, allerdings teilt man die recht umfangreichen Optionen meist auf mehrere Dateien auf:

    • etc/hosts.cfg
      Hier definiert man die zu überwachenden Rechner samt Namen und IP-Adressen. Dazu benötigt man die weiter unten erklärten host-Objekte.

    • etc/services.cfg
      Hier kann man die zu überwachenden Dienste definieren, die zwei wichtige Eigenschaften besitzen: den Rechner(n), auf dem sie laufen, sowie den Befehl beziehungsweise das Plugin, das für den Check verwendet werden soll.

    • etc/commands.cfg
      Die bei den Servicedefinitionen benötigten Dienste kann man auch als Objekte anlegen, was einem die Angabe der genauen Syntax bei jedem einzelnen zu konfigurierenden Dienst ersparen kann.

    • etc/contacts.cfg
      Hier kann man einzelne Benutzer samt E-Mail-Adresse oder anderer Benachrichtigungsmethoden eintragen sowie angeben, bei welchen Dringlichkeitsstufen verschiedener Events sie kontaktiert werden sollen.

    • etc/*groups.cfg
      Ob Rechner oder Kontakte: Beides kann und sollte man auch zu Gruppen zusammenfassen, um die Administration komplexer Netzwerke zu vereinfachen. Diese Gliederung ist vor allem für das Benachrichtigungssystem sinnvoll.
  • Weitere Objekttypen
    Es gibt noch viele weitere Objekttypen, die gerade für komplexe bis sehr komplexe Netzwerke interessant werden können. Für eine Dokumentation zu diesen Features seien Sie erneut auf die Webseite verwiesen, da weitere Details den Rahmen des Buches sprengen würden.
    • Denken Sie allerdings daran, dass die eben vorgestellten Dateien nicht unbedingt so auf Ihrem Nagios-Server vorhanden sein müssen – schließlich können Sie in der nagios.cfg flexibel einstellen, woher Ihre Objektdefinitionen kommen sollen.

Im Folgenden wollen wir weniger die Konfiguration von Nagios selbst (über die nagios.cfg beziehungsweise die cgi.cfg) erläutern, da diese standardmäßig recht sinnvoll und im Allgemeinen weniger interessant ist.

Stattdessen möchten wir lieber auf die umfangreichen Objektdefinitionen eingehen, die das Monitoring Ihres Netzwerks erst ermöglichen. Aus diesem Grund seien Sie erneut auf die Webseite des Projekts samt zugehöriger Dokumentation verwiesen, falls Fragen zur Konfiguration offen bleiben sollten.

Hostobjekte

Rechner definieren

Prinzipiell in jeder Object-Configuration-Datei kann man host-Objekte definieren, meist wird dazu jedoch die etc/hosts.cfg genutzt. Möchte man nun einen neuen Rechner zur Überwachung hinzufügen, kann man dort eine entsprechende Definition ablegen:

define host{
host_name                     Rechnername
alias                         Alias
address                       IP
(parents                      Rechnernamen)
(check_command                Kommando)
max_check_attempts            #
notification_interval         #
notification_period           timeperiod
notification_options          [d,u,r]
}

Listing 33.23  Ein Host-Objekt

Man gibt dem Objekt mit dem Rechnernamen zuerst einen eindeutigen Bezeichner, auf den man sich dann in der weiteren Konfiguration von Nagios auch beziehen kann. Der Alias dagegen wird verwendet, um den Rechnernamen über das Webinterface anzuzeigen.

Es folgt natürlich die obligatorische IP-Adresse. Wenn sich irgendwelche anderen Systeme wie zum Beispiel Router zwischen dem Host und dem Monitoringsystem befinden, werden diese im optionalen Parameter parent angegeben.

Ist ein Rechner an?

Das check-Kommando ist recht wichtig, um zu überprüfen, ob der Host noch »up« ist. Meist gibt man hier das standardmäßig in der commands.cfg definierte Kommando check-host-alive an, das schlicht einen Ping auf den Rechner versucht. Lässt man diesen Parameter weg, wird das System nicht überprüft und immer als »up« angenommen.

Als Nächstes muss man angeben, wie oft im Fehlerfall überprüft werden soll, bevor eine Nachricht abgeschickt beziehungsweise der Rechner als »down« deklariert wird. In so einem Fall werden entsprechende Kontakte alle notification_interval Minuten wieder informiert.

Eine timeperiod ist auch ein Objekt, über das man definieren kann, in welchem Zeitraum ein Rechner oder ein Dienst überwacht werden soll. Meist gibt man hier den in der etc/timeperiods.cfg definierten Zeitraum 24x7 an, der den Rechner ohne Unterbrechung kontrolliert.

Zum Schluss kann man noch einstellen, wann ein Admin benachrichtigt werden soll: wenn der Rechner »down« (d) geht, wenn er »unreachable« (u) ist, also ein Parent »down« geht und der Rechner nicht mehr zu erreichen ist, und/oder wenn er wieder »up« (r, engl. recover) ist.

Es gibt noch eine ganze Reihe weiterer möglicher Optionen, die wir aber nicht näher betrachten wollen.

Hostgruppen

Verknüpfung mit Kontakten

Was in der Definition zu einzelnen Rechnern noch fehlte, war natürlich die Verknüpfung mit entsprechenden Kontakten, die im Problemfall informiert werden sollen. Dazu fasst man nämlich mehrere Rechner zu einer »Gruppe« zusammen, indem man wieder einen Objektnamen samt Alias vergibt und der Gruppe eine Kontaktgruppe sowie natürlich ein bis mehrere durch Komma getrennte Mitglieder zuordnet. Die Mitglieder sind dabei selbstverständlich wieder Hostobjekte.

define hostgroup{
hostgroup_name                Gruppenname
alias                         Alias
contact_groups                Kontaktgruppen
members                       Mitglieder
}

Listing 33.24  Hostgruppen

Durch diese auf den ersten Blick komplexe Struktur kann man sehr sinnvolle und realitätsnahe Konfigurationen für das Monitoring schaffen. Und dies ist schließlich das Ziel, das wir mit der Software verfolgen.


Um letzte Fragen zu klären, wollen wir uns aber einmal ein kurzes Beispiel eines Hostobjekts sowie einer dazugehörigen Hostgruppe ansehen:


define host{
host_name                     fileserver
alias                         Data Store
address                       192.168.1.1
check_command                 check-host-alive
max_check_attempts            5
notification_interval         30
notification_period           24x7
notification_options          d,u,r
}
define hostgroup{
hostgroup_name                servers
alias                         Serverraum #1
contact_groups                linux-admins
members                       fileserver,mailserver
}

Listing 33.25  Host samt Hostgruppe

Diese Konfiguration sollte mit den Erläuterungen der Objekttypen eigentlich selbsterklärend sein. Das einzige, was Sie nicht verwundern sollte, ist die hier nicht weiter definierte Kontaktgruppe linux-admins. Da wir auf Kontaktgruppen erst später eingehen, haben wir diese Definition hier nämlich noch offengelassen.

Serviceobjekte

Serverdienste definieren

Bereits angesprochen wurden auch die Serviceobjekte. Das Wort »Service« bezeichnet dabei nicht nur klassische Dienste wie HTTP, FTP oder POP3, sondern auch jede andere »messbare« Eigenschaft eines Rechners.

So kann man über Serviceobjekte auch den Plattenplatz, die Anzahl momentan eingeloggter Benutzer, die Prozessorauslastung oder was auch immer überprüfen. Allerdings sollte man immer darauf achten, nicht zu viele Informationen zu sammeln, damit das Wichtige nicht untergeht.

define service{
host_name                     Rechnername
service_description           Beschreibung
check_command                 Kommando
max_check_attempts             #
normal_check_interval          #
retry_check_interval           #
check_period                  timeperiod
notification_interval         #
notification_period           timeperiod
notification_options          [w,u,c,r]
contact_groups                Kontaktgruppen
}

Listing 33.26  Serviceobjekte in der etc/services.cfg

Der Rechnername bezieht sich auf ein host-Objekt, auf dem dieser Dienst läuft beziehungsweise dessen Zustand überwacht werden soll. Ansonsten ist vor allem wieder das Kommando wichtig, bei dem oft auf eines der mitgelieferten Plugins zurückgegriffen wird.

Ähnlich wie die bereits erläuterten notification-Optionen verhalten sich auch die check-Optionen. So kann man über die check_period-Option kontrollieren, wann das Monitoring stattfinden soll (z. B. 24x7), oder mittels der interval-Optionen festlegen, wie regelmäßig die Überprüfungen wiederholt werden sollen.

Wann informieren?

Zu den notification_options ist allerdings noch eine weitere Option – (w) für Warnungen – hinzugekommen. Schließlich gibt es für Dienste drei Zustände: »ok«, »warning« und »critical«, während es mit »up« und »down« für Rechner an sich nur zwei messbare Zustände gibt.

Über die Option contact_groups kann man wie bei den Hostgruppen eine oder mehrere Kontaktgruppen angeben, die im Problemfall benachrichtigt werden.

Kontakte und Kontaktgruppen

Verantwortliche angeben

Daher wollen wir als Nächstes auch schon dieses Feature behandeln. Zu einem Kontakt gehört wie immer bei Nagios der Objektname, der »richtige« Name als Alias sowie natürlich neben den bereits bekannten Benachrichtigungsoptionen eine – optionale – E-Mail-Adresse.

define contact{
contact_name                  Kontakt
alias                         Alias
host_notification_period      timeperiod
service_notification_period   timeperiod
host_notification_options     [d,u,r,n]
service_notification_options  [w,u,c,r,n]
service_notification_commands notify-by-email
host_notification_commands    host-notify-by-email
(email                        E-Mail)
}

Listing 33.27  Kontakte in der etc/contacts.cfg

Natürlich gibt es auch für Kontakte noch weit mehr als die hier aufgeführten Optionen und damit natürlich auch mehr Möglichkeiten, wie eine Benachrichtigung erfolgen kann. Daher ist die E-Mail-Adresse als eine Kontaktoption unter vielen auch nicht zwingend für dieses Objekt erforderlich.

Um einen Kontakt nun aber mit einem Hostgruppen- oder Serviceobjekt verknüpfen zu können, benötigt man eine Kontaktgruppe. Auch wenn in einer solchen Gruppe nur ein einziger Kontakt steht, ist sie notwendig, damit man den Kontakt in Nagios nutzen kann:

define contactgroup{
contactgroup_name             Kontaktgruppe
alias                         Alias
members                       Mitglieder
}

Listing 33.28  Kontaktgruppe in der etc/contactgroups.cfg


Die Mitglieder einer solchen Gruppe sind natürlich wieder die entsprechenden Objektnamen, die durch Kommas getrennt werden. Aber sehen wir uns dazu ein einfaches Beispiel an:


define contact{
contact_name                  jploetner
alias                         Johannes Plötner
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                         jploetner@localhost
}
define contactgroup{
contactgroup_name             admins
alias                         Administratoren
members                       jploetner, swendzel
}

Listing 33.29  Ein Beispiel

Dieses Beispiel sollte eigentlich selbsterklärend sein. Man definiert zuerst den Kontakt und fügt ihn schließlich einer Kontaktgruppe hinzu.

Kommandodefinition

Plugins integrieren

Wir haben bei den Host- und den Serviceobjekten bereits auf die Kommandos Bezug genommen, mit denen diese entsprechend überwacht wurden. Dort konnte man entweder direkt einen Befehl eingeben oder eben auf ein definiertes Kommandoobjekt Bezug nehmen.

Ein solches Kommandoobjekt definiert man wie folgt:

define command{
command_name          Kommando
command_line          Kommandozeile
}

Listing 33.30  Kommandodefinition in der etc/commands.cfg


Dabei kann man in der Kommandozeile auch Makros nutzen, die mit einem Dollarzeichen beginnen müssen. Ein Beispiel soll diesen Sachverhalt verdeutlichen:


define command{
command_name           check_pop
command_line           /usr/local/nagios/libexec/

check_pop -H $HOSTADDRESS$
}

Listing 33.31  Ein Beispiel

In diesem Beispiel wird das Kommando check_pop definiert, das ein gleichnamiges Skript im libexec/-Verzeichnis mit dem entsprechenden Rechnernamen als Argument aufruft.

Wenn die Plugins installiert wurden, dann hat man schon eine ganze Reihe sinnvoller Kommandos zur Verfügung. Im Folgenden soll eine kleine Übersicht über die wichtigsten Skripte und Programme gegeben werden. Für eine ausführliche Übersicht sei Ihnen aber immer noch die Dokumentation der Plugins selbst ans Herz gelegt.


Galileo Computing - Zum Seitenanfang

33.2.3 Die Plugins  topZur vorigen Überschrift

Wie bereits angedeutet, besitzt Nagios selbst keinerlei Möglichkeiten, irgendeinen Dienst oder Rechner zu überwachen. Die Software verlässt sich voll und ganz auf die Plugins, die diese »Intelligenz« übernehmen.

Die Intelligenz

Bekanntermaßen unterscheidet Nagios allerdings zwischen Hostchecks und Servicechecks, die beide auf dieselbe Pluginarchitektur zurückgreifen. Der einzige Unterschied besteht darin, dass bei einem Hostcheck bei jedem Nicht-OK-Wert bei der Rückgabe angenommen wird, dass der Rechner »down« ist.

Dass man die Plugins schließlich über Kommandodefinitionen einbindet, die man dann in den Host- und Serviceobjekten angeben kann, sollte mittlerweile auch klar sein.

check_tcp

Portscan

Dieses Plugin ist eines der einfachsten und gleichzeitig wichtigsten Plugins. Über dieses Plugin kann man nämlich überprüfen, ob ein Port auf einem entfernten Rechner offen oder geschlossen ist. Mit dieser Information kann man dann den Rückschluss ziehen, ob der entsprechende Dienst läuft oder abgestürzt ist.

Ruft man das Plugin auf der Kommandozeile ohne Parameter auf, so wird ein Hilfetext mit allen verfügbaren Parametern ausgegeben:

# ./check_tcp
No arguments found
Usage: check_tcp -H host -p port [-w warn_time]
[-c crit_time] [-s send_string] [-e expect_string]
[-q quit_string] [-m maxbytes] [-d delay]
[-t to_sec] [-v]

Listing 33.32  Die Parameter des Plugins

In einer Kommandodefinition könnte man das Plugin also zum Beispiel wie folgt ansprechen:

define command{
command_name                  check_port_cups
command_line                  $USER1$/check_tcp -H

$HOSTADDRESS$ -p 631
}

Listing 33.33  Beispiel: check_tcp


In dem Beispiel wollen wir also einen Check definieren, der einen laufenden CUPS-Server überprüft. Dazu nutzen wir zwei Makros: Das in der etc/resource.cfg definierte $USER1$-Makro spart uns die Angabe des vollständigen Pfadnamens zum Pluginverzeichnis, und zur Laufzeit von Nagios wird das Makro $HOSTADDRESS$ durch die Adresse des zu überprüfenden Rechners ersetzt.


In einem Serviceobjekt könnte man nun wie folgt den CUPS-Server überwachen lassen:

define service{
host_name                     printserver,testserver
service_description           CUPS
check_command                 check_port_cups
...
}

Listing 33.34  CUPS-Server überwachen

check_ping

Rechnerstatus berechnen

Für Hostchecks möchte man natürlich am liebsten ICMP-Echo-Pakete mittels ping verschicken. Zu diesem Zweck gibt es das Plugin check_ping, das meist wie folgt als Kommando definiert wird:

define command{
command_name                  check-host-alive
command_line                  $USER1$/check_ping

-H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 1
}

Listing 33.35  check-host-alive

Das check-host-alive-Kommando ist uns aber schon in der Definition der Hostobjekte begegnet, wo wir es als sinnvolles Standardkommando zur Überprüfung des Hoststatus vorgestellt hatten.

NRPE und NSCA

Richtig interessant wird Nagios allerdings erst, wenn Erweiterungen wie NRPE beziehungsweise NCSA ins Spiel kommen. Diese Dienste laufen auf dem zu überwachenden Rechner und können Nagios diverse Informationen wie noch verfügbare Plattenkapazität, Prozessorauslastung oder Speicherauslastung mitteilen.

Aktive vs. passive Checks

Mit NRPE kann man dabei aktive Checks realisieren: Man installiert auf dem Clientsystem – die Software gibt es für Windows und Unix – den NRPE-Dienst und auf dem Nagios-Server das check_nrpe-Plugin. Entsprechend konfiguriert, überprüft Nagios nun über das Plugin regelmäßig den Status des Systems.

Setzt man dagegen NCSA ein, so kann man passive Checks realisieren. Dies ist zum Beispiel nützlich, wenn das zu überwachende System hinter einer Firewall sitzt. Mit dieser Software baut nämlich der Client regelmäßig selbst die Verbindung zu der auf dem Nagios-Server laufenden Software auf.

Wie Sie sehen, kann man mit Nagios sehr komplexe Monitoringstrukturen umsetzen. Da das Thema aber sehr komplex ist, wollen wir es bei diesem Einblick in die Thematik belassen und Sie ein letztes Mal auf die verfügbare Dokumentation verweisen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






 <<   zurück
  Zum Katalog
Zum Katalog: Linux, Ausgabe 2011






Linux, Ausgabe 2011
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: Debian GNU/Linux






 Debian GNU/Linux


Zum Katalog: openSUSE 11.2






 openSUSE 11.2


Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de