johe’s Blog

translate to english

So denn, vielleicht ist es dir richtige Zeit mal auf eine Software einzugehen die nun schon etwas länger “in den Regalen steht.” NagiosCenter ist diese.

Details der Software:

• Art: Webfrontend und Client Software
• Lang: PHP, Python (MySQL)
• Gibt eine Übersicht laufender (und nicht laufender) Prozesse verschiedener Nagios Server

Die meisten Nagios User kennen das Nagios Webfrontend.So steht die Frage im Raum warum schreibt man ein neues.

Die Frage ist recht sinnig, eigentlich tut NagiosCenter nichts anderes als Daten dazustellen, die selben Daten wie nagios selbst es tut. Böse Zungen behaupten sogar das Nagios dies Design technisch schöner macht.

Diese Software (also NagiosCenter) wurde aber auch aus einem anderen Grund geschrieben. Es stellte sich das Problem das eine Firma Nagios Überwachung an diversen Standorten betreibt. Einige davon besitzen nur eine DSL leitung mit ständig wechselnder IP Adresse also. Der Weg Nagios so zu konfigurieren das es per nrpe und Co sich über eine solche Lösung verbindet war zwar Möglich barg aber kleinere Probleme, wie timeout z.b..

Aus diesem Grund entstand NagiosCenter.

NagiosCenter kann mit hilfe des in Python geschriebenen Daemons die Daten eines entferneten Nagios abrufen und zentral Darstellen. Hierzu benutzt es einen Daemon der auf dem entferneten System selbst läuft. Dieses hat den Vorteil das der Client auf die Mysql DB zugreifen kann und nicht der Server umständlich sich zum Client verbinden muss. Timeout Probleme werden so z.b. umgangen.

NagiosCenter gibt in seinem Webfrontend dann einen Überblick über die verschiedenen Clients (Collectoren genannt) und zeigt die selben Daten wie Nagios es vor Ort tut. In der vorliegenden Version 1.0RC1 sind dependencys und hostgroups leider noch nicht implementiert. Aber sollte es Nachfrage diesbezüglich geben bin ich mir sicher das dies Nachgereicht wird.

Alles in allem also eine schöne kleine Software. Und die paar Erfolgsgeschichten geben ihr wohl Recht. So ist nun erwiesen das NagiosCenter zumindest in 2 Unternehmen eingesetzt wird und dort jeweils 2 bis 5 Nagiosserver zentralisiert. So macht das Entwickeln doch Spass.

Ich hatte kürzlich das Problem das eine virtuelle Festplatte unter VMWare voll war. Dies ist auch unter VMWare Server eigentlich keine grosse Sache. Also auf die console eingeloggt und los ging es:

 vmware-vdiskmanager -x 64GB /var/opt/vm/vm1/vm1-001-0.vmdk

Ohne meckern oder murren vergrösserte der vdiskmanager dann auch die gewünschte Festplatte. Beim neustart des Systems gab es dann aber eine böse überraschung. Sie lief nämlich nicht mehr.

Der Grund? ganz einfach ich hatte übersehen das es mal einen Snapshot auf dieser Platte gab und habe diesen schlicht weg ignoriert. Also im selben Ordner war auch noch ein vm1-001-0-00000001.vmdk Auf diese Zeigte auch auf diesen Snapshot. Dumm gelaufen

The parent virtual disk has been modified since the child was created (18).

Ich beschreibe nun kurz was man tun sollte, muss leider auch dazu sagen das es bei mir nicht so recht wollte, aber leider habe ich aus dem schon schweren Fehler durch leichtes zutun einen SuperGau gemacht.

Also erstens: KEINE Panic

Da sich jemand die Mühe gemacht eine Art worst-case Liste zu machen schauen wir einfach ob unser Problem in dieser Liste ist wir schauen also auf  http://sanbarrow.com/vmdk/vmdk-when-its-too-late.html nach ob wir unsers Fehler finden. Und ja da ist er auch schon. ALso müssen wir nicht viel tun.

1. Wir betrachten uns die disc und den Snapshot und finden einen Unterschied in der CID des Parent und im CIDParent eintrag. Diesen müssen wir ausgleichen,also schreiben wir in den CIDParent eintrag logisch den CID des Parent

2. Desweiteren sehen wir das die RW der Einträge nicht mehr stimmt, auch hier übertragen wir die RW vom Parent auf das Child

3. Natürlich hat der Parent nun auch mehr Einträge. Da vmware ja (normalerweise) 2GB Files anlegt, wir haben bei einer vergrösserung von 10GB also 5 Files mehr. Diese löschen wir aus der Datei und die -fxxx.vmdk files von der Festplatte

Die Festplatte (snapshot) würde nun wieder ohne murren booten. Ich empfehle vorher noch folgendes

vmware-vdiskmanager -r <snapshot>.vmdk -t 0 new_vmware.vmdk

Somit kopieren wir den Snapshot, im idealfall sollte es nun auch wieder eine Disk ohne Snap sein, den man dann weiter benutzen kann.

In meinem Fall kann ich nur abschliessend sagen: Gut wenn man ein Backup hat

translate to english

SSH kann ja jeder,

so stellte sich die Herausforderung das man zwar mit check_ssh der nagios_plugins auch LSH überprüfen kann, das ganze jedoch zu ungewollten Fehlern führt.

Also habe ich kurzerhand das ganze so editiert das es etwas besser passt.

check_lsh.c

wie auch die check_ssh besitzt dieses Test folgende Form

Usage:check_lsh [-46] [-t <timeout>] [-r <remote version>] [-p <port>] <host>

Rückgabewerte entsprechen Analog:

- OK: Wenn der Rückgabewert “lshd” enthällt

- Warning: Wenn der Rückgabewert hiervon abweicht

- Critical: Wenn es keinen Rückgabewert gibt

Bleibt noch zu erwähnen das der default Port auf 1022 gesetzt wurde. Da wir hier diesen verwenden.

Desweiteren kann das nun über den gcc kompiliert werden, ich habe es aus den nagios_plugins heraus kompiliert in dem ich das configure skript und das Makefile angepasst habe, mittels ersetzen der check_ssh optionen durch check_lsh.

translate to english

Von Zeit zu Zeit kommt es bei uns vor das ein Dateisystem sich einfach verabschiedet und sich auf readonly setzt. Dies ist gerade wenn es sich um das rootfs handelt eine recht heimtükische Sache.Um also diesem effekt auf die Spur zu kommen bedarf es einen kleinen nagios skriptes. Da wie festzustellen war sich die option unter /proc/mounts  ändert wenn dies passiert. (Anmerkung: die Ausgabe von df oder der fstab schafft dies wenn das rootfs betroffen ist nicht mehr.

check_rofs.txt

Usage: check_rofs.sh <mountpoint>

Rückgabewerte:

- OK: Wenn <mountpoint> rw gesetzt

- Critical: Wenn <mountpoint> ro gesetzt

- Warning: Wenn “Test result empty (For any reason)”