check_messpc.py is  a nagios script written in python to monitor messpc http://www.messpc.de/  via nagios.

It is written to monitor 4 Ports (as we use here) and will be

Warning when > 28 °C

Critical when > 30°C

Community String must be set in source code and you can just do an ./check_messpc.py <hostename>

to use this script, please fill in the CommunityString

you can run the command by python check_apc.py <hostename>

It will return an generated Status string

Ich habe mir eine schöne neue Maschine gebaut. Bzw ein paar teile fehlen halt noch aber ich bin schon recht zufrieden.

• AMD Athlon64 X2 5200+
• zurZeit 1GB DDR2-800 Ram (8GB im Januar
• 40 GB Systemplatte, 400GB IDE Storage (+320GB SATA im Januar)

Der Hauptgrund war, ich wollte Virtualisierung betreiben. Ist ja in aller Munde und scheint ja auch was nettes zu sein.

Also habe ich über das Wochenende ein paar Systeme ausprobiert, und hier ist das Ergebnis.

1. Centos 5.4 der klare Sieger. Zwar kommt er nicht mit dem neusten virt-manager um die ecke, aber er ist stabil. Nach dem Boot hat mein kvm system gerade mal 350 MB Speicher für sich in anspruch genommen. Zwar muss man die Netzwerkkarte von Hand patchen aber das soll ja keiner Herausforderung sein. Alles in allem gut schnell und stabil.
2. Fedora 12, Hm…? Die Packete sind angeblich da, aber ich weiss nicht wo. Der neuste virt-manager sieht klasse aus. Aber was soll ich damit wenn ich den libvirtd nicht installiert bekomme? Naja, alsoda es boot und ram tchnisch sich mit Centos fast gleich hält leider nur Platz2
3. OpenSolaris 2009.06 Um ehrlich zu sein ich mag ja SUN. Aber hey, warum bootest du in 5 minuten? Was tust du so lange? Und warum brauchst du direkt meinen ganzen RAM? Also nach der installation die lange gedauert hat, und nach dem booten das auch eine gefühlte ewigkeit lang war sehe ich das 95% meines Ram voll sind. Da lohnt es sich noch nichteinmal VirtualBOX zu installieren. Ausserdem liegt auf meiner Storageplatte ein wunderschönes LVM mit meinen Daten. Solaris kann damit leider nichts anfangen. Auch kann es kein ext4 mounten (ext2,ext3 soll mittlerweile gehen). Also alle features taugen nichts. Somit der klare Verlierer.

Wem es dann dennoch zu schwer ist, der kann gerne mein CoovaChilli haben (für Ubuntu i386)

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)”