Das Problem: $KUNDE hat einen Nagios welcher außerhalb einer DMZ steht. Um diese zu erreichen zu können, gibt es ein Tor, welches nur SSH durchlässt, nach innen, wie nach außen.

Damit er die Rechner innerhalb der DMZ prüfen kann, wird derzeit ein Sammelsurium aus Skripten und NSCA verwendet, für passive Checks.

Dieses Konstrukt lässt sich vereinfachen, wenn die Rechner innerhalb der DMZ Ports verwenden dürfen. Das folgendende, neben- stehende und spontan entstandene Bild, soll dies verdeutlichen:

Das Wunderbare an den Nagios Plugins besteht darin, dass sie kein Nagios benötigen. Genau dieses Verhalten machen wir uns zu nutze. Nagios setzt einen aktiven Check mittels

check_by_ssh

ab und führt als Befehl eben den

check_nrpe

mit den entsprechenden Parametern ab, welcher wiederum einen NRPE Deamon abfragt, der auf den Rechner innerhalb der DMZ installiert wurde. Damit haben wir vieles vereinfacht:

  • Aktive Checks sind besser als passive 😉
  • Der »freshness« Parameter muss nicht bemüht werden, da die Checks immer dem aktuellen Stand entsprechen
  • Es wunderbar erweiterbar und dank SSH sowie SSL sicher.
  • Es ließen sich auch nicht definierte Argumente vom Nagios aus mitgeben, sofern NRPE mit der Option übersetzt wurde
  • … und bestimmt noch viele mehr

Wie sieht nun eine entsprechende Konfiguration aus?

In der commands.cfg definieren wir zuerst zwei neue Kommandos:

[…]

define command{ command_name ssh_check_dmz_icmp command_line $USER1$/check_by_ssh -H ssh-tor \ -C “$USER1$/check_icmp -H $ARG1$” }

define command{ command_name ssh_check_dmz_rootdisk command_line $USER1$/check_by_ssh -H ssh-tor \ -C “$USER1$/check_nrpe -H $ARG1$ -c check_hda5” }

Ersterer sorgt ohne noch NRPE dafür, dass wir einen Ping absetzen können, mittels

check_icmp

, dem Nachfolger des alten

check_ping

und zwar von unserem (SSH)Tor zu einem der Rechner in der Burg DMZ. Als Argument wird einfach der Rechnername/IP mitgegeben.

Zweites Kommando prüft den Datenträger »/dev/hda5« und zwar mittels

check_nrpe

. Das bedeutet,

check_hda5

ist also ein Kommando, welches in der nrpe.cfg Daemon Konfig definiert wurde. Ich hätte es also auch genauso gut

check_rootdisk

nennen können.

Nun folgt die host.cfg, in der der DMZ Rechner definiert wird:

define host{ use linux-server host_name dmzpc01 address 192.168.198.101 check_command ssh_check_dmz_icmp!dmzpc01 }

define service{ use generic-service host_name dmzpc01 service_description Check rootdisk check_command ssh_check_dmz_rootdisk!dmzpc01 }

Unser Rechner innerhalb der DMZ hat hier also den Namen »dmzpc01«. Um den Status des jeweiligen zu überprüfen, loggt sich Nagios über SSH ein und ruft von dort das NRPE Plugin auf und schon erhält Nagios einen frischen Status.

Statt »dmzpc01« als Argument, täte es auch eine IP Adresse (was im allgemeinen besser wäre) od. vermutlich auch

$HOSTADDRESS$

. Dann holt er sich die IP direkt aus der Hostconfig.

Überhaupt, ob die Wahl von IP oder Hostname ist nicht so einfach zu lösen, wenn die Systeme Redundant ausgelegt sind. Verlässt sich der Admin auf DNS, kann man die IP schnell per DNS umschalten, auf unser Ersatz Tor. Fällt DNS aus, hat Admin ein Problem, wobei sich dies mit einer /etc/hosts lösen ließe, dann aber wiederum statisch wäre (eventuell in der nsswitch die Reihenfolge ändern »dhcp file«).

Wird dagegen die IP umgezogen, ist IP definitiv zu bevorzugen.