Nagios-Connector

Dieses Modul ist eine kostenpflichtige opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können. Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie beim Kauf der Erweiterung. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an sales@uib.de).
Weitere Details hierzu finden Sie in Freischaltung kostenpflichtiger Module.

Technische Voraussetzungen sind opsi 4.0.2 mit den Paketständen:

Vorrausgesetzt wird eine Nagios Installation in einer aktuellen 3.x Version oder eine Icinga Installation mindestens in der Version 1.6. Der opsi-Nagios-Connector sollte auch mit allen Nagios-Kompatiblen Monitoring-Lösungen benutzbar sein, getestet wird diese opsi Erweiterung allerdings nur gegen Nagios und Icinga. Sollte eine grafische Darstellung der opsiconfd-Performance Werte gewünscht werden, wird zusätzlich noch eine Installation des Addons pnp4nagios benötigt.

Für weitere Informationen siehe auch:

Eines der Hauptschwerpunkte des opsi-Nagios-Connectors ist eine Erweiterung des opsi-Webservice. Die Webserviceschnittstelle bietet damit die Möglichkeit, Checks vom opsi-Server anzufordern. Das bedeutet, der Nagios Server verwendet die erweiterten Webservicemethoden zum Auslösen und Abfragen von Checks. Der Vorteil dieser Lösung ist, dass die eigentliche Checkausführung im opsi-System ausgeführt wird und somit der Aufwand auf den überwachten Systemen gering bleibt.

Diese Erweiterung stellt eine Sammlung von Checks zur Verfügung, die in einem späteren Kapitel einzeln vorgestellt werden. Hauptsächlich wurden opsi spezifische Checks eingebaut. "Normale" Systemchecks werden nicht über den opsi-Nagios-Connector angeboten und müssen auf konventionelle Weise ausgeführt werden.

Ein weiterer Teil des opsi-Nagios-Connectors ist eine Erweiterung des opsi-client-agent. Da in einer opsi-Umgebung jeder Managed-Client einen laufenden opsi-client-agent hat, bietet es sich an, diesen als Nagios-Agent zu benutzen. Wichtig bei dieser Erweiterung ist zu wissen, dass nicht alle Funktionen eines Nagios-Agenten, wie z.B. NSClient++ implementiert wurden.

Die Möglichkeiten des opsi-client-agent umfassen das Ausführen von Pluginbefehlen auf der Kommandozeile und das Zurückliefern der Ergebnisse.

Für Situationen in denen erweiterte Funktionen vom Nagios-Agent wie NSCA benötigt werden, wird ein opsi-Paket für die Verteilung und Pflege des NSClient++ per opsi bereitgestellt.

Der Vorteil der Verwendung des opsi-client-agent ist zum Einen, dass kein zusätzlicher Agent benötigt wird und das der Monitoring-Server keine Zugangsdaten vom Client haben muss, da die Checks zum Client alle über den opsiconfd laufen. Dies vereinfacht auch die Konfiguration auf der Monitoring Seite um Einiges.

In der allgemeinen Monitoring Sprache wird zwischen aktiven und passiven Checks unterschieden. Die Bedeutung besagt, ob Nagios/Icinga die Checks selber auslöst und ausführt (aktiv) oder ob die Hosts die Checks eigenständig ausführen und die Ergebnisse an Nagios/Icinga selbstständig zurückmelden (passiv).

Auch bei der opsi-Nagios-Connector Erweiterung gibt es diese zwei Unterscheidungen. Allerdings werden diese bei opsi als direkte- bzw. indirekte-Checks bezeichnet:

Ein gutes Beispiel für einen indirekten Check ist check-opsi-client-status. Dieser Check bezieht sich eigentlich auf einen Client, ausgeführt wird er aber auf dem opsi-Backend. Der Client-Status ist in diesem Fall der Zustand des Clients aus Sicht von opsi. Im Gegensatz dazu wird jeder Check der tatsächlich am Client ausgeführt wird als direkter Check bezeichnet.

Die richtige Verteilung der Checks und damit die richtige Konfiguration erfordert zunächst die Analyse der eigenen opsi-Umgebung. Da opsi sehr flexibel einsetzbar ist, können verschiedene Szenarien auftreten. Hier werden die am häufigsten mit opsi eingesetzten Installationsvarianten abgehandelt. (Für spezielle Installation sollten Sie uns kontaktieren oder direkt über einen bestehenden Supportvertrag Ihre Situation schildern.)

Ein opsi-Server (Standalone Installation): Diese Variante ist die am häufigsten eingesetzten Variante. Bei dieser Installation ist der Configserver auch gleichzeitig der Depotserver und somit werden alle Checks über den opsi-Configserver aufgerufen.

Mehrere opsi-Server mit einer zentralen Administration (Multi-Depot Umgebung): Um bei dieser Art der Installation die Checks richtig zu verteilen, muss man als erstes Verstehen, wie eine Multi-Depot Umgebung aufgebaut ist:

Wie im Bild zu erkennen, gibt es nur ein Daten-Backend, welches am opsi-Configserver angesiedelt ist. Jeder Check, der gegen das Backend ausgeführt wird, muss somit zwangsläufig über den opsi-Configserver. Somit werden alle Checks, die an die Depotserver gehen, intern an den Configserver weitergeleitet. Deshalb ist es sinnvoller diese Checks direkt gegen den opsi-Configserver auszuführen. Eine Ausnahme können die aktiven Checks gegen den opsi-client-agent bilden. Wenn zum Beispiel zwischen den Servern eine Firewall aufgestellt ist, die nur den Port 4447 durchlässt, können Clients an der Außenstelle eventuell nicht erreicht werden (Standardport 4441). In solchen Fällen kann es nützlich sein den aktiven Check am Depotserver in der Außenstelle auszuführen.

Auf dem Nagios Server gibt es nur ein opsi-check-plugin, welches aber eine große Zahl von Checks unterstützt. Deshalb hat dieses Plugin auch ziemlich viele Optionen. Eine Auflistung dieser Optionen wäre der Erläuterung nicht dienlich, deshalb wird an dieser Stelle darauf verzichtet. Die einzelnen Optionen, die benötigt werden oder möglich sind, werden bei den einzelnen Checks erläutert. Das opsi-check-plugin wird aufgerufen mit dem Befehl check_opsi. Eine Übersicht der möglichen Optionen erhält man mit dem Parameter -h oder --help.
Die folgenden Optionen sind für alle Checks notwendig:

Die oben aufgeführten Parameter müssen immer gesetzt werden. Das nachfolgende Kapitel erläutert als erstes, wie man das opsi-check-plugin manuell aufrufen würde. Wie diese über Nagios/Icinga gesetzt werden, wird im Kapitel der Konfiguration erläutert.

Um das check-plugin vom opsi-Nagios-Connector zu installieren, können Sie einfach das opsi-Repository auf dem Nagios-Server eintragen und mit folgendem Befehl das Paket installieren:

Für Redhat/Centos:

Für OpenSuse/SLES:

Das Plugin selbst ist in Python geschrieben und sollte auch auf anderen Distributionen laufen. Dieses Paket basiert auf dem Paket: 'nagios-plugins-basic' bzw. 'nagios-plugins' und installiert entsprechend das Plugin ins Verzeichnis: /usr/lib/nagios/plugins. Die Konfiguration der Nagios-Check-Commands wird nicht automatisch angelegt, da dieses Plugin sehr flexibel einsetzbar ist. Deshalb wird dieser Teil im Kapitel über die Konfiguration etwas später näher erläutert.

Mit diesem Check wird der opsi-Webservice-Prozess überwacht. Dieser Check liefert auch Performancewerte. Deshalb sollte dieser Check auf jedem opsi-Server selbst ausgeführt werden, da jeder opsi-Server seinen eigenen opsiconfd-Prozess hat, der überwacht werden kann bzw. sollte.

Dieser Check liefert in der Regel OK zurück. In folgenden Situationen kann dies Abweichen:

Info: Die CPU-Werte beziehen sich immer nur auf eine CPU, da ein Prozess auch nur einen Prozessor benutzen kann. Eine Ausnahme bildet hier das Multiprocessing von opsi.

Für die Perfomance-Auswertung gibt es ein Template für das pnp4nagios, welches die Werte kombiniert darstellt. Wie man das pnp4nagios installiert, wird hier nicht explizit beschrieben, sondern es wird davon ausgegangen, dass pnp4nagios richtig installiert und konfiguriert wurde. Die notwendige Vorgehensweise kann sich von der hier beschriebenen Lösung unterscheiden, wenn das pnp4nagios mit anderen Pfaden installiert wurde (kann bei selbst kompilierten Installationen vorkommen).

Es werden Standard-Templates verwendet, welche für jeden einzelnen Performancewert ein eigenes Diagramm erstellen. Um das oben genannte Template mit der kombinierten Ansicht zu verwenden, muss man folgendermaßen vorgehen:

Schritt 1: Erstellen Sie unterhalb von: /etc/pnp4nagios/check_commands eine Datei mit der Bezeichnung: check_opsiwebservice.cfg und folgendem Inhalt:

Schritt 2: Legen Sie die Datei check_opsiwebservice.php unterhalb von /usr/share/pnp4nagios/html/templates ab. Diese Datei können Sie über svn.opsi.org auschecken.

Wichtig bei diesen Templates ist, dass die Namen der PHP-Dateien genauso heißen wie der 'command_name', welcher in der Datei /etc/nagios3/conf.d/opsi/opsicommands.cfg definiert ist. Stimmen die Bezeichnungen nicht überein, wird ein Standardtemplate von pnp4nagios verwendet.

Sollte diese Anpassung vorgenommen werden, wenn die ersten Checks für den opsi-webservice schon stattgefunden haben, müssen die schon erstellten RRD-Datenbanken erst mal gelöscht werden, da mit diesen Templates auch die Struktur der RRD-Datenbanken neu konfiguriert werden.

In der Regel sind die RRD-Datenbanken unter folgendem Pfad zu finden: /var/pnp4nagios/perfdata/<host>/ .

Dabei reicht es aus, alle Dateien, die entweder mit opsi-webservice.rrd oder mit opsi-webservice.xml beginnen, zu löschen. (Vorsicht: Hier werden auch andere RRD-Datenbanken von anderen Checks für diesen Host angelegt, die nicht unbedingt gelöscht werden sollten.).

Damit das Ganze automatisch funktioniert, müssen diese Dateien genauso heißen, wie das check_command vom opsi-Webservice. Der Grund dafür liegt in der Arbeitsweise von pnp4nagios. Sollte also die Konfiguration des opsi-Webservice von dieser Dokumentation abweichen, so müssen auch diese Template-Dateien umbenannt werden, da ansonsten pnp4nagios keine richtige Zuordnung treffen kann.

Wurde bis hierhin alles richtig konfiguriert und die Konfigurations-Schritte im Konfigurationskapitel richtig befolgt, sollten die Diagramme wie im folgenden Screenshot automatisch generiert werden:

Mit diesem Check werden die opsiconfd-Ressourcen auf Füllstand überwacht. Die folgende Tabelle zeigt, welche Ressourcen damit gemeint sind.

Bitte auch hier beachten, dass nur die Füllstände der Pfade, die für opsi relevant sind, beim Check berücksichtigt werden. Dieser Check soll keinen allgemeinen DiskUsage-Check ersetzen.

Mit folgendem Befehl kann man alle Ressourcen gleichzeitig abfragen:

Zusätzlich zu der normalen Checkvariante gibt es die Möglichkeit, nur eine Ressource zu checken. Das folgende Beispiel checkt nur nach der Ressource repository:

Standardmäßig gibt dieser Check OK zurück und gibt den freien Speicherplatz der Ressource oder der Ressourcen zurück. Die Einheit ist dabei Gigabyte. Folgende weitere Zustände sind möglich:

Die oben genannten Werte sind die Standard-Thresholds. Diese können durch zusätzliche Angabe von den Optionen -C und -W bzw. --critical und --warning selber bestimmt werden. Dabei gibt es zwei mögliche Einheiten: 10G bedeutet mindestens 10 Gigabyte freier Speicherplatz, durch diese Angabe wird der Output auch in dieser Datei ausgegeben. Wenn die Thresholds in Prozent oder ohne Angaben angegeben werden, wird auch der Output in Prozent generiert. Abschließend noch ein Beispiel zur Veranschaulichung:

Einer von zwei Schwerpunkten des opsi-Nagios-Connectors ist das Überwachen von Software-Rollouts. Dafür wurde dieser Check konzipiert. Er bezieht sich immer auf einen Client innerhalb von opsi.

Der Status der Produkte auf dem Client entscheidet über das Ergebnis des Checks. Auf diese Weise erkennt man schnell, ob eine Produktinstallation auf dem betreffenden Client ansteht oder aktuell ein Problem verursacht hat. Aber nicht nur der Produktstatus des Clients kann das Checkergebnis beeinflussen, sondern auch wann dieser Client sich das letzte mal am Service gemeldet hat. Wenn der Client länger als 30 Tage nicht am Service war, wird der Check mindestens ein Warning als Ergebnis zurückgeben. Dieser Zeitraum orientiert sich an der Abfolge der Microsoft Patchdays. Wenn ein Client länger als 30 Tagen von der Softwareverteilung abgeschottet ist, sollte man den Client checken. Auf diese Weise kann man auch Clients im System finden, die schon lange inaktiv sind, die man im normalen Betrieb schnell übersieht.

Die Ergebnisse der Tests werden von folgenden zwei Grundregeln bestimmt:

Dieser Check kann auf verschiedene Weisen durchgeführt werden; die einfachste Variante:

Man kann einzelne Produkte anhand ihre ID von diesem Check ausschließen. Dies würde zum Beispiel so aussehen:

Das obige Beispiel schließt das Produkt 'firefox' aus diesem Check aus, somit würde dieser Check auch ein OK liefern, selbst wenn das Produkt 'firefox' bei dem Client auf 'failed' steht.

Der zweite Schwerpunkt des opsi-Nagios-Connectors ist das Überwachen von Software-Rollouts. Mit die wichtigste Aufgabe in einem Software-Verteilungssystem. Sobald eine neue Software, egal ob Standard-Software oder eigene Software mit opsi verwaltet, verteilt und aktuell gehalten wird, muss man den Rollout-Status im Auge behalten.

Das Ergebnis dieses Checks wird durch die folgenden Grundregeln bestimmt:

Der Software Rollout Status ist:

Durch einige Parameter kann man diesen Check flexibel einsetzen. Um dies besser zu verdeutlichen werden einige Beispielaufrufe aufgeführt und erläutert. Im einfachsten Fall ruft man den Check einfach für ein Produkt auf. Dieser wird als productId (opsi-interner Name) angegeben.

In einer normalen opsi-Umgebung reicht dieser Aufruf, um den Zustand für das Produkt firefox zu überwachen. Die Ausgabe zeigt an, ob alles in Ordnung ist oder wie viele Installationen anstehen (setup), wie viele Clients ein Problem mit diesem Produkt haben (failed) und wie viele Clients nicht die aktuelle Version installiert haben.

Dies ist zur Übersicht in den meisten Fällen schon ausreichend, wenn man aber nun genau wissen will, auf welchen Clients, welcher Zustand zu diesem Produkt zu diesem Checkergebnis geführt hat, kann man den Befehl im verbosemode ausführen:

Bei einer Multi-Depot Umgebung wird der obige Befehl aber nicht die komplette Umgebung nach diesem Produkt überwachen, sondern nur den Configserver. (Oder exakter: Die Clients die dem depot auf dem config server zugewiesen sind). Wenn man mehrere Depotserver hat, kann man das Depot auch direkt mit angeben:

Der Grund dafür ist, dass jeder Depotserver diese Produkt zur Verteilung haben kann. Dies muss nicht überall die selbe Version sein, auch wenn die productId genau die Selbe ist. Aus diesem Grund müssen alle Clients anders beurteilt werden, je nachdem an welchem Depot sie registriert sind. Dies hat zusätzlich noch den Vorteil, dass man diesen Check später im Nagios beim Depotserver ansiedeln kann, was zusätzlich die Übersichtlichkeit erhöht. Wenn man nur ein oder zwei Depotserver hat, kann man auch mit der Angabe von all alle Depotserver mit einem Check abdecken oder Komma separiert mehrere Depotserver angeben.

Zusätzlich kann man mit diesem Check auch mit opsi-Gruppen arbeiten. Man kann zum Beispiel eine ganze Produktgruppe mit einem Check abfragen. Wenn man zum Beispiel eine Produktgruppe: buchhaltung bildet, kann man mit folgendem Aufruf:

Nun werden alle Produkte, die Mitglieder in dieser Produktgruppe sind über diesen Check überwacht. Die Auswertung dieser Gruppe findet immer während des eigentlichen Checks statt; das bedeutet, man kann über opsi diese Gruppe bearbeiten und beeinflusst somit direkt die Check-Parameter ohne das man die Nagios-Konfiguration anpassen muss.

Auch die Clients, die für diesen Check abgearbeitet werden, können beeinflusst werden. Wie vorher schon erwähnt, wird die Clientliste durch Angabe des Depotservers beeinflusst, zusätzlich können opsi-Hostgruppen angegeben werden, die für diesen Check abgearbeitet werden. Dieser Aufruf sieht zum Beispiel wie folgt aus:

Dies würde die Produkte der Produktgruppe 'buchhaltung' für alle Clients der Gruppe produktivclients überprüfen. Auch bei den Hostgruppen gilt die Regel, dass Untergruppen dieser Gruppe nicht abgearbeitet werden. Für opsi-Productgroups gilt genauso, wie für opsi-Hostgroups, dass mehrere Gruppen Komma separiert angegeben werden können.

Abschließend kann man auch bei diesem Check opsi-Clients ausschließen:

Gerade in einer Multi-Depot Umgebung ist es wichtig, die Depotserver auf Synchronität zu überwachen. Entscheidend ist bei diesem Check die Software- und Paketversion der installierten Produkte. Manchmal ist ein differenzierter Einsatz der opsi-Produkte auf Depotservern gewünscht, birgt aber die Gefahr, dass bei einem Umzug von einem Client, von einem Depot zum anderen, Inkonsistenzen in der Datenbank entstehen können. Um dieser Problematik entgegenzuwirken, wird empfohlen die opsi-Pakete auf den Depotservern so synchron wie möglich zu halten.

Standardmäßig liefert dieser Check 'OK' zurück, sollte eine Differenz festgestellt werden, wird der Status: 'WARNING' zurückgegeben. Dieser Check ist ein klassischer Check, der auf dem Configserver ausgeführt werden sollte, da alle Informationen zu diesem Check nur im Backend auf dem opsi-Configserver zu finden sind.

Als nächstes folgen ein paar Anwendungsmöglichkeiten dieses Checks:

Dies ist dies Basis-Variante und äquivalent zu folgendem Aufruf:

Ohne konkrete Angabe von Depotserver werden die Produkt-Listen aller Depot-Server miteinander verglichen. Um eine bessere Übersichtlichkeit zu schaffen, sollte man diesen Check auf zwei Depotserver reduzieren und lieber auf mehrere Checks verteilen. Dies erreicht man durch direkte Angabe der Depotserver:

Mit diesem Aufruf werden alle Produkte verglichen, die auf beiden Depotservern installiert sind. Sollte ein Produkt auf einem Depotserver gar nicht installiert sein, hat dies keine Auswirkungen auf das Check-Resultat. Dies kann man ändern, indem man bei diesem Check den "strictmode" Schalter setzt:

Nun werden auch Produkte angezeigt, die auf einem Depotserver nicht installiert sind. Um ein bestimmtes Produkt oder bestimmte Produkte nicht mit zu checken, weil man zum Beispiel will, dass diese Produkte in verschiedenen Versionen eingesetzt werden, kann man diese Produkte von diesem Check ausschließen:

Dieser Check würde auch dann ein OK zurückgeben, wenn das 'firefox' und das 'thunderbird'-Paket nicht überall synchron eingesetzt werden.

Ein weitere Einsatzmöglichkeit wäre, dass nur eine Auswahl von Produkten auf Synchronität überwacht werden können. Dies kann man durch:

So werden nur 'firefox' und 'thunderbird' Produkte auf Synchronität überwacht. Bei diesem Check sollte der strictmode gesetzt sein, damit man auch erkennt, wenn die gewünschten Produkte auf Depotservern nicht installiert sind.

Während der Installation eines neuen opsi-Paketes auf einem opsi-Server wird eine Sperre für das Produkt auf diesem Depot gesetzt. Sobald die Installation erfolgreich abgeschlossen wurde, wird die Sperre entfernt. Die Installation eines opsi-Paketes kann manchmal eine ungewöhnliche lange Zeit dauern, ohne dass ein Problem besteht. Falls die Sperre eine lange Zeit besteht, kann dies ein Indikator für Installationsprobleme sein.

Dieser Check sucht nach existierenden Sperren auf opsi-Servern.

Die Rückgabewerte sind: * 'OK'
Falls keine Produkt-Sperren auf einem opsi-Server vorhanden sind. * 'Warning'
Falls eine oder mehr Produkt-Sperren auf einem opsi-Server vorhanden sind.

Dieser Check sollte immer auf dem Config-Server ausgeführt werden, weil die benötigten Daten aus dem Backend des Config-Servers stammen.

Dieser Check benötigt mindestens die folgenden Versionen:

Einfacher Aufruf des Checks:

Diese Variante ist gleichbedeutend mit dem folgenden Aufruf:

Falls Sie die Prüfung auf bestimmte Depotserver einschränken wollen, müssen diese als kommaseparierte Liste angegeben werden. Das Ergebnis kann schwerer zu interpretieren sein, wenn die Ausgabe für mehrere Server gemischt wird, weshalb die Empfehlung ist, eine Prüfung pro Depot einzurichten.

Das folgende Beispiel prüft die beiden Depotserver 'configserver.domain.local' und 'depotserver.domain.local':

Der Standard ist, dass alle Produkte geprüft werden. Die Einschränkung auf bestimmte Produkte ist möglich. Es wird eine kommaseparierte Liste der Produkt IDs zum Filtern verwendet.

Das folgende Beispiel schränkt den vorherigen Check auf weiter ein und prüft nur die Produkte 'opsi-client-agent' und 'opsi-winst':

Dieser Check führt ein Check-Plugin auf dem Client direkt aus und fängt die Ausgabe ein.

Diese Erweiterung soll keinen Ersatz für einen richtigen Nagios-Agent bieten, sondern eine Alternative. Man kann diese Erweiterung einsetzen, wenn man Plugins auf dem opsi-Client checken will. Die eingesetzten Plugins müssen den sogenannten Nagios plug-in development guidelines entsprechen.

Um ein Plugin ausführen zu können, muss man das Plugin erst einmal auf den Clients verteilen. Dies sollte man über ein opsi-Paket lösen. Der Ablageort für die Plugins auf dem Client ist im ersten momentan egal, da man den Pfad beim Checken mit angeben muss. Allerdings sollte man die Plugins nicht einzeln verteilen, sondern in einem Verzeichnis zusammenführen, damit das Aktualisieren und Pflegen der Plugins einfacher wird. Weiterhin sollte man auch Sicherheitstechnisch im Hinterkopf behalten, dass die Plugins im Systemkontext des opsiclientd-Services aufgerufen werden. Normale Anwender sollten auf dieses Verzeichnis keinen Zugang haben.

Es gibt diverse Plugins, die es schon vorgefertigt im Internet herunterzuladen gibt. Eine mögliche Anlaufstelle ist Nagios Exchange.

Im Folgenden wird davon ausgegangen, dass unter C:\opsi.org\nagiosplugins\ das Plugin check_win_disk.exe vom Paket nagioscol abgelegt wurde.

Dieser Aufruf checkt auf dem Client client.domain.local das Plugin check_win_disk.exe und übergibt diesem den Parameter C:. Dies bedeutet, dass das Laufwerk 'C' auf dem Client gecheckt wird. Die Ausgabe und der Rückgabewert dieses Plugins wird direkt vollständig ausgewertet und diese Werte können in Nagios unmittelbar weiter verarbeitet werden.

Ein besonderes Feature ist das Beibehalten von Zuständen. Diese Implementation ist aus der Problemstellung entstanden, dass Clients nicht wie Server durchlaufen, sondern in der Regel nur einen bestimmten Zeitraum eingeschaltet sind. Man kann den Check auf Nagios-Seite zwar mit sogenannten Timeperiods eingrenzen, aber so ein Vorgehen ist nicht praktikabel, da man zum Beispiel auch bei Urlaub von Anwendern flexibel reagieren muss. Dies würde eine ständige Konfigurationsarbeit nach sich ziehen. Wenn man darauf verzichtet, wird der Status ständig geändert, auch wenn ein aufgetretenes Problem noch gar nicht gelöst ist. Deshalb kann man den letzten bekannten Status an opsi übergeben. Sollte der Client nicht erreichbar sein, wird dieser letzte bekannte Status zurückgegeben. Ein 'Critical'-Zustand bleibt beispielsweise in diesem Falle auch auf 'Critical' stehen und wechselt nicht auf 'Unknown', was rein logisch aber richtig wäre.

Um dieses Feature später mit Nagios zu verwenden, kann man die Nagios-Makros: '$SERVICESTATEID$' und '$SERVICEOUTPUT$' nutzen.

In der Regel wird im Monitoring-Bereich viel mit IP-Freischaltungen als Sicherheit gearbeitet. Da aber dieser Mechanismus nicht wirklich einen Schutz bietet, wurde beim opsi-Nagios-Connector darauf verzichtet. Aus diesem Grund wird das Ganze per Benutzer und Passwort geschützt. Diesen User als opsi-admin einzurichten, würde aber auch hier zu viele Rechte freischalten, da dieser User nur für diese Schnittstelle von Nöten ist und auch die Benutzbarkeit auf diesen Bereich eingeschränkt werden soll, wird der User nur intern in opsi eingerichtet. Folgender Befehl legt den User an:

Dieser Befehl legt den User: monitoring mit dem Passwort monitoring123 an. Der User wird in der /etc/opsi/passwd angelegt und ist auch kein User, mit dem man sich an der Shell anmelden könnte.

Bei einer Multi-Depot Umgebung muss man diesen User nur auf dem Configserver erzeugen.

Beim Nagios-Server kann man dieses Passwort vor den CGI-Skripten maskieren, indem man einen Eintrag in der /etc/nagios3/resource.cfg vornimmt. Dieser sieht zum Beispiel so aus:

Die Zahl hinter '$USER' kann variieren. Wenn diese Datei vorher nicht genutzt wurde, sollte in der Regel nur das $USER1$ belegt sein. Diese Konfiguration dient als Grundlage für die weiteren Konfigurationen.

Aus Gründen der Übersichtlichkeit empfiehlt es sich für die Konfigurationsdateien des opsi-Nagios-Connectors ein eigenes Verzeichnis anzulegen. Erzeugen Sie dazu unterhalb von: /etc/nagios3/conf.d ein Verzeichnis opsi. Dies macht die Konfiguration später übersichtlicher, da alle Konfigurationen, die den opsi-Nagios-Connector betreffen, gebündelt auf dem Server abgelegt sind.

Zu den Konfigurationsdateien in diesem Verzeichnis gehören:

Um die Übersichtlichkeit noch weiter zu erhöhen sollten Sie unterhalb von /etc/nagios3/conf.d/opsi noch ein Verzeichnis clients anlegen, dass im Weiteren dazu dient, die Konfigurationsdateien für die Clients aufzunehmen.

Es gibt diverse Templates für diverse Objekte im Nagios. Dies ist eine Standard-Nagios Funktionalität, die hier nicht näher beschrieben wird. Diese Funktionalität kann man sich für opsi zu nutze machen, um sich später bei der Konfiguration die Arbeit zu vereinfachen.

Da die meisten Checks auf dem Configserver ausgeführt werden, sollte man sich als erstes ein Template für die opsi-Server und ein Template für die opsi-Clients schreiben. Da es in einer Multi-Depot Umgebung nur einen Configserver geben kann, kann man direkt diesen ins Template übernehmen. Dies erreicht man am einfachsten über eine Custom-Variable. Diese erkennt man daran, dass sie mit einem _ beginnen. Es wird in das Template für den opsi-Server und die opsi-Clients folgendes zusätzlich eingetragen:

Auf diese beiden 'custom Variablen' kann man später einfach mit dem Nagios-Makro: $_HOSTCONFIGSERVER$ und $_HOSTCONFIGSERVERPORT$, verweisen. HOST muss vorher angegeben werden, da diese Custom-Variablen in einer Hostdefinition vorgenommen wurden. Weitere Informationen zu Custom-Variablen entnehmen Sie bitte der Nagios-Dokumentation. Da diese beiden Konfigurationen im Template vorgenommen werden müssen, gelten sie für jede Hostdefinition, die später von diesen Templates erben. Aber dazu später mehr.

Um nun die Templates anzulegen, sollte man unterhalb von: /etc/nagios3/conf.d als erstes ein Verzeichnis opsi erstellen. Dies macht die Konfiguration später übersichtlicher, da alle Konfigurationen, die den opsi-Nagios-Connector betreffen, gebündelt auf dem Server abgelegt sind. In diesem Verzeichnis erstellt man die Datei und benennt sie direkt so, dass man später erkennt, was genau hier konfiguriert werden soll: opsitemplates.cfg.

In dieser Datei können verschiedene Templates definiert werden. Die Templatedefinition richtet sich dabei nach folgendem Muster, bei dem zur besseren Verständlichkeit die Kommentare zu den einzelnen Einstellungen nicht gelöscht wurden:

Wir empfehlen Templates für folgende Objekte anzulegen:

Zunächst das Beispiel des opsi-Server-Templates:

Hier muss natürlich noch 'configserver.domain.local' an die lokalen Gegebenheiten angepasst werden. Auch die 'contact_groups' bedürfen evtl. der Anpassung.

Als nächster Teil der Datei opsitemplates.cfg das Template für die Clients:

Da die Clients in der Regel nicht durchlaufen, sollte die Option: "check command check-host-alive" nicht gesetzt werden. Somit werden die Clients als Pending angezeigt und nicht als Offline.

Hier muss natürlich noch 'configserver.domain.local' an die lokalen Gegebenheiten angepasst werden. Auch die 'contact_groups' bedürfen evtl. der Anpassung.

Als nächster Teil der Datei opsitemplates.cfg das Template für die opsi-services:

Wenn pnp4nagios für die grafische Darstellung der Performancedaten für den opsi-Webservice eingesetzt werden, sollten noch die folgenden zwei Objekte als Template in der Datei opsitemplates.cfg angelegt werden:

Als nächstes sollten folgende Hostgruppen erstellt werden. Dies dient zum einen der besseren Übersicht auf der Weboberfläche und hilft beim Konfigurieren der Services. Dafür sollte eine Datei Namens opsihostgroups.cfg mit folgendem Inhalt erstellt werden:

Als nächstes sollten die opsi-Server konfiguriert werden. Dies kann jeweils in einer eigenen Datei wie zum Beispiel configserver.domain.local.cfg oder eine Datei mit allen opsi-Hosts wie opsihost.cfg erfolgen. Der Inhalt sollte für opsi-Server folgendermaßen aussehen:

Folgende Erläuterungen zu den Werten: * 'use' bezeichnet, welches Template benutzt wird. * 'hostgroups' gibt an, welcher Hostgruppe der Server angehört.

Die opsi-Clients sollten mindestens folgendermaßen definiert werden:

Die Clientkonfiguration bedient sich einer Sonderfunktion von Nagios. Die Option _depotid ist eine sogenannte benutzerdefinierte Variable, die als Makro $_HOSTDEPOTID$ benutzt werden kann. Die Verwendung ist optional und wird verwendet, wenn die Ausführung eines direkten Checks nicht vom config server, sondern vom hier definierten Depotserver aus startet.

Um die Erstellung von vielen Client Konfigurationsdateien zu vereinfachen, können diese auf dem opsi-Config-Server mit folgendem Skript erstellt werden.

Die oben beschriebenen Check-Kommandos müssen nun mit den bisherigen Kommandos konfiguriert werden. Dafür sollte eine Datei mit dem Namen opsicommands.cfg erstellt werden. Hier wird eine Bespielkonfiguration angegeben; je nach dem, welche Funktionen Sie auf welche Weise verwenden wollen, müssen Sie diese Einstellungen nach eigenem Ermessen modifizieren.

Als erstes wird der Aufbau anhand eines Beispiels erläutert:

Der command_name dient zur Referenzierung der weiteren Konfiguration. In der Option command_line werden die Konfigurationen und das Check-Kommando als erstes vereint.

Nach diesem Prinzip baut man nun die ganze Datei opsicommands.cfg auf:

Hier müssen Sie natürlich 'adminuser' in einen bzw. mehrere reale User abändern.

In der Konfiguration der 'Services' wird nun endlich angegeben, was der Nagios-Server monitoren und anzeigen soll. Dabei wird nun auf die bisher definierten Templates, commands und hostgroups bzw. hosts zugegriffen.

Zunächst der Teil der Services, die die tatsächlichen Zustände der Server betreffen. Hierbei wird beim Check auf den Depotsync gegen alle bekannten Services ('all') geprüft.

Nun der Teil der das Softwarerollout überwacht. Dabei wird in einem Check auf das opsi-Produkt 'opsi-client-agent' verwiesen und zwei andere Checks verwenden hier eine opsi-Produktgruppe 'opsiessentials' sowie eine opsi-Clientgruppe 'productiveclients'.

Im dritten und letzten Teil werden die direkten Checks für die Clients definiert. Diese Checks richten sich in diesem Beispiel nicht an hostgroups, sondern einzelne hosts ('client.domain.local','depotclient.domain.local').