Nagios: check_by_ssh mit nrpe kombinieren für DMZ

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:

Nagios und Rechner in einer DMZ

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.

„Für ein Morgen in Freiheit“

Die Spatzen haben es ja bereits von den Dächern gepfiffen. Nach der letzten Demo in Köln startet nun Phase zwei. Die Vorbereitungen laufen auf den höchsten Touren und es sind mehr Leute daran beteiligt, als ich Finger habe. Einige Parteien beteiligen sich, sowie die Piraten, CCC und weitere, also die klassischen „Verdächtigen“ 😉

180x350.jpg

Klaus treibt alle ordentlich an und es wird wohl ein Event der extra Klasse werden. Ich werde hoffentlich auch wieder mit dabei sein, am 15.03.08 auf dem Roncolla Platz, Punkt 14Uhr. Um zahlreiches Erscheinen wird gebeten.
Das alles lässt sich natürlich auf der freiheit-ist-sicherheit.de Seite nachlesen. Für einen Informationstausch, abseit der Mailinglisten, wurde auch ein Forum eingerichtet, was sich hier finden lässt.

Ich denke, wir werden dieses Mal die Domplatte mit Sicherheit komplett füllen 🙂 Der Countdown läuft … für uns, wie für den Staat.

Ohne Betreff

also ich habe meinen Mac Mini ja vor einiger Zeit mit Lenny bestückt, weil Ubuntu einfach nicht mehr die PPC Variante unterstützt und Etch auf dem Desktop einfach nur alt aussieht.
Das ich mich auf eine Testing Version einlassen würde mit all seinen Konsequenzen, war mir durchaus bewußt. Doch nun nervt es ein wenig, keinen gescheiten Mailclient zu haben. Thunderbird Icedove für PPC ist kaputt und das nicht erst seit gestern. Irgendein Bug sorgt dafür, dass er nicht mehr startet. Also habe ich mir als Notbehelf KMail eingerichtet. Schon damals, zu KDE2 Zeiten gefiel mir KMail nicht und das hat sich seither nicht geändert.
IMAP macht echt keinen Spaß und ist einfach nur langsam. Des weiteren leidet die Testing Version ebenfalls wohl unter einem Bug, der mich nicht mehr Anhänge speichern lässt. Warum auch immer. (ein NFS Laufwerk blockierte den Dialog. Server war offline) Auch verstehe ich nicht, warum so simple Sachen wie »Shift+Pfeil rauf/runter« zum markieren nicht funktionieren. Sicher wird das wieder über eine andere Tastenkombie erledigt, finde ich aber dennoch bescheuert. Mag Gewöhnungssache sein, dennoch …
Überhaupt ist er beim IMAP Langsam. Einen Ordner ausgewählt bedeutet erstmal einen tollen blauen Schirm zu sehen mit »Nachrichten werden geholt« ….

Also echt, Kmail als reiner Mail Client, -> blöd. Wie gut, das ich mich auf mein Horde/IMP verlassen kann.

[Update]

Alten IceDove Installieren:

# echo "deb http://snapshot.debian.net/archive pool icedove" >> /etc/apt/sources.list
# apt-get update
# apt-get install icedove=2.0.0.9-1  icedove-locale-de=2.0.0.9-1 \ 
 icedove-gnome-support=2.0.0.9-1 engimail

Und die Pakete bei Bedarf auf „hold“ setzen.

(Media)Wiki offline als reines HTML exportieren

Wer kennt das nicht. Da hat man ein wunderschönes Wiki, mit wunderbaren Inhalten, und man möchte dieses eben transportabel haben, um die verschiedenen Inhalte auch im Zug zu haben. Jetzt ist aber der Lustfaktor, einen MySQL und Webserver aufzusetzen recht gering. Was gibt es also besseres, als alles statisch als HTML vorliegen zu haben. Für genau dieses Zweck gibt es das Tool mw2html,welches ein Python Script ist. Sobald ich die dafür benötigte htmldata Lib in mein Python Lib Verzeichnis kopiert habe (als htmldata.py), kann ich mw2html folgendermaßen aufrufen:

~$ python mw2html.py http://www.pug.org/index.php/ pug-wiki

Und schon wandert das (Media)Wiki von der pug.org in den Ordner pug-wiki. Mitsamt Grafiken, Links, Archiven und dem passenden Layout 🙂

Ich stelle fest…

Cluster bauen macht kein Spaß. Allein wie unterschiedlich schon die Ansätze und Umsetzungen letzten Endes sind, kann einen ganz schön verwirren.
Durch das Lesen der Doku, versteht meiner einer allerdings mehr und mehr, wo was gebraucht wird. Im Falle meines Planes, Xen Hoch verfügbar zu »konstruieren«, stellen sich da diverse Probleme. Zum einen müssen alle Dom0 Rechner auf den gleichen Storage Poolzugreifen können, und zwar sowohl lesen, als auch schreibend(!). Dies ließe sich z.B. mittels NFS bewerkstelligen, allerdings passen NFS und Geschwindigkeit nicht wirklich zusammen. Des weiteren benötigt es eine Software, die dafür sorgt, dass die nötigen Schritte eingeleitet werden, bei einem Ausfall. Im Falle von Xen bedeutet dies, das ausgefallene DomUs auf anderen Dom0s hochgefahren werden.
ein weiteres Problem besteht im Storage selbst: dieser muss ebenfalls redundant sein. Nun gibt es da eine (an für sich) tolle Software: drbd. Diese Sofware synchronisiert Blockgeräte über ein Netzwerk hinweg. Anders formuliert, wenn sich auf Rechner1 ein Bit ändert, wandert dieses Bit auch auf Rechner 2. Also im Grunde nichts anderes, als ein Spiegel. Das Problem hierbei: nur einer lässt sich zur Laufzeit verwenden. Würde man auf beiden Rechnern diesen Datenträger einhängen (welcher über ein Dateisystem verfügt), würde dieses zielsicher zerlegt werden. Um dem vorzubeugen, unterbindet »drbd« dies, und lässt es nur zu, wenn der Primäre Spiegel nicht verfügbar ist. Wir lernen also, es gibt »primary« und »secondary«.

Das hilft uns allerdings nicht viel, denn wir möchten ja, zeitgleichen Zugriff auf dieses Blockgerät. Nun gibt es ab drbd 8.0.x die Möglichkeit, beide Spiegel auf »primary« zu setzen. Das versetzt uns in die Lage, auf beides Rechnern, diesen Datenträger einzubinden. Die Problematik was das Dateisystem angeht, wurde damit allerdings nicht entschärft, und hier kommt ein Clusterdateisystem zum Einsatz. Dieses regelt den syncronen Zugriff auf ein und die selben Datenstrukturen und verhindert, dass zwei Zugriffe von unterschiedlichen Rechnern, zur selben Zeit auf die selben Daten schreiben und damit ein inkonsistentes Dateisystem produzieren. Und genau hier hänge ich nun schon seit drei Tagen. Soviel zur Theorie.

Mir gelang es zwar, »drbd« aufzusetzen, aber bei dem mounten des Oracle Cluster Filesystems Version 2, gibt es nur eine Fehlermeldung. Dabei spielt es keine Rolle, ob als Linux ein SLES10sp1 werkelt, oder ein Debian Etch. Stellt sich also die Frage: wo liegt das Problem? Was »drbd« und »ocfs« gibt es zu hauf widersprüchliche Aussagen, die sehr an Voodoo grenzen und für meinen Geschmack nichts ist, was ich produktiv einsetzen wollte (nichts desto trotz, gibt es sie). Warte ich mal die Antwort von der »drbd« Mailingliste ab. Eventuelle werde ich daraus schlauer … ansonsten bleibt nur noch ocfs durch »gfs« zu ersetzen, was in der Komplexität noch ein Stück höher liegt …

Update

Von: Florian Haas (LINBIT Information Technologies GmbH)
An: drbd-user@lists.linbit.com

OCFS2 had a bug that prevented it from working correctly with DRBD. That
filesystem bug was fixed by our own Phil Reisner and is included in kernel
version 2.6.21 and up. Etch is on 2.6.18, SLES 10 is on a patched 2.6.16;
I’m not sure whether they backported Phil’s 2.6.21 fix to that.

DRDB, OCFS2, EVMS, CLVM, GNDB, schlag-mich-tot

Hab ich ein Schlagwort vergessen? Macht nichts. Bin eh schon verwirrt genug. Ich habe bisher mit Clustern so rein garnichts zu tun gehabt. Doch bei Xen würde es sich natürlich anbieten, dies im Kurs mit aufzunehmen.
Also dachte ich mir: »Denny« sagte ich »Bau Dir dochmal einen Xen Cluster und schreibe dann eine Anleitung«. Soweit kein Problem, dachte ich. Gibt ja schon zu genüge (zumeist) englische Varianten davon. Nun habe ich mir im Vmware zwei normale SLES10sp1 Kisten installiert. Darin läuft erfolgreich ein DRDB mit zwei Nodes. Die SLES Kisten sollen nämlich dann den Storage bereitstellen, den dann zwei andere Rechner einbinden, um dort die Xen Images ablegen zu können.

So, jetzt bin ich mir aber im nächsten Schritt nicht sicher. Packe ich da jetzt das OCFS2 drauf? Im ersten Schritt will ich nur dafür sorgen, dass der Speicher redundant bleibt. Im Zweiten kommen dann zwei Debian Rechner, mit Xen 3.2 (wovor es mich schon graust, wenn ich an die ganzen Module denke, die mit rein sollen), die dann das OCFS2 einbinden. Damit könnte ich schonmal einer SLES10 Kiste das Licht ausknipsen, ohne dass dies eine Auswirkung auf laufende Xen Gäste haben sollte. Dann kommt noch heartbeat dazu, der dafür sorgt, dass wen ein Xen Dom0 Rechner ausfällt, die Gäste auf der Anderen wieder gestartet werden. Sehe ich doch richtig so, oder?

Derzeit habe ich zwei Anleitungen, die ich verfolge:

http://xenamo.sourceforge.net/
http://wiki.xensource.com/xenwiki/EVMS-HAwSAN-SLES10

Aber die finde ich ein wenig verwirrend, da nie so recht klar wird, wann ich was von was benötige. ….