Schlagwort-Archive: Nagios

RHEL 6.4, tmpfs und OMD: can’t find /omd/sites/… in /etc/fstab or /etc/mtab

Veröffentlicht am von
12

Wer Open Monitoring Distribution auf RHEL oder CentOS 6.4 einsetzen möchte, hat vermutlich das Problem, dass das Erstellen von Sites nicht wie gewohnt funktioniert:

# omd create test
Adding /omd/sites/test/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/test/tmp...mount: can't find /omd/sites/test/tmp in /etc/fstab or /etc/mtab
ERROR

Auch das Starten der Site funktioniert nicht:

# omd start test
Creating temporary filesystem /omd/sites/test/tmp...mount: can't find /omd/sites/test/tmp in /etc/fstab or /etc/mtab
ERROR
Starting dedicated Apache for site test...OK
Starting rrdcached...OK
Starting npcd...touch: cannot touch `/omd/sites/test/tmp/pnp4nagios/run/npcd.pid': No such file or directory
chown: cannot access `/omd/sites/test/tmp/pnp4nagios/run/npcd.pid': No such file or directory
An Error occured while reading your config on line 197
Message was: "Could not open pidfile '/omd/sites/test/tmp/pnp4nagios/run/npcd.pid': No such file or directory"
OK
/omd/sites/test/etc/rc.d/80-nagios: line 58: /omd/sites/test/tmp/nagios/nagios.cfg: No such file or directory
Nagios configuration file /omd/sites/test/tmp/nagios/nagios.cfg not found. Terminating...
Initializing Crontab...OK

Beim Recherchieren bin ich auf den folgenden Thread in der check_mk-Mailinglist gestoßen: http://comments.gmane.org/gmane.network.nagios.checkmk.german/1694.

Der Fehler wird anscheinend durch ein Update von RHEL / CentOS 6.4 verursacht: https://bugzilla.redhat.com/show_bug.cgi?id=917678.

Das OMD-Skript (/usr/bin/omd) erstellt für den /tmp-Verzeichnisbaum von Sites Ramdisks – in dieser werden dann temporäre Dateien und Pidfiles angelegt. Hierfür werden entsprechende Zeilen in der /etc/fstab des Servers angelegt – mit der Verwendung eines symbolischen Links für den Pfadnamen.

Mit dem letzten 6.4-Update dürfen in der /etc/fstab keine Namen mit symbolischen Links mehr verwendet werden. Ein nachträgliches Anpassen der entsprechenden Zeile in der Textdatei löst das Problem nicht, da beim Ausführen des omd create-Kommandos die Ramdisk auch eingehängt wird – aus diesem Grund stürzt auch das omd start-Kommando mit einem Fehler ab.

Das Problem lässt sich durch Anpassen der Zeile 747 des Skriptes /usr/bin/omd beheben – hier muss einfach ein /opt angefügt werden, damit kein symbolischer Link mehr verwendet wird:

file("/etc/fstab", "a+").write("tmpfs  /opt%s tmpfs noauto,user,mode=755,uid=%s,gid=%s 0 0\n" % \

Ich habe dafür eine Patch-Datei erstellt, mit der man diese Änderung kinderleicht übernehmen kann: omd.patch

# wget http://blog.christian-stankowic.de/wp-content/uploads/2013/03/omd.patch_.txt
# cd /usr/bin
# cp omd omd.initial
# patch < /PATH/omd.patch_.txt

Und schon funktioniert das Anlegen von OMD-Sites wieder:

# omd create test
Adding /omd/sites/test/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/test/tmp...OK
Created new site test with version 0.56.

Auch der Start von Sites läuft nun ohne Probleme durch:

# omd start test
Starting dedicated Apache for site test...OK
Starting rrdcached...OK
Starting npcd...OK
Starting nagios...OK
Initializing Crontab...OK

:)

Debian Wheezy’s send_nsca und nsca 2.7.2

Veröffentlicht am von
Kommentar

Unter Debian Wheezy gibt es erstmal auch ein Paket für den NSCA-Agent (früher gab es nur ein Paket, welches Agent und Dienst vereinte). Das Paket liegt in der Version 2.9.1 vor – in Kombination mit dem NSCA-Server in der Version 2.7.2 ergibt das allerdings leider unschöne Fehlermeldungen im Syslog:

# cat /var/log/messages
...
nsca[30772]: Handling the connection...
nsca[30772]: Dropping packet with invalid CRC32 - possibly due to client using wrong password or crypto algorithm?

Der Hintergrund ist, dass send_nsca in der neueren Version eine größere Paketgröße von 4096 Bytes (anstatt 512) hat – damit kann der Server nichts anfangen. Die einfachste Lösung ist es, send_nsca in einer älteren Version zu übersetzen. Idealerweise nimmt man genau die NSCA-Version, die auch auf dem Nagios-/Icinga-Server verwendet wird.

In meinem Fall war das NSCA 2.7.2. Die folgenden Zeilen laden einige Entwicklungswerkzeuge und NSCA herunter. Anschließend wird send_nsca übersetzt und auf die Festplatte kopiert. Zuletzt muss noch die send_nsca-Konfigurationsdatei angepasst werden:

# apt-get install gcc make libmcrypt-dev
# links 'http://sourceforge.net/projects/nagios/files/nsca-2.x/nsca-2.7.2/nsca-2.7.2.tar.gz/download'
# tar xfz nsca-2.7.2.tar.gz
# cd nsca-2.7.2
# ./configure --prefix=/usr
# make send_nsca
# cp src/send_nsca /usr/sbin/send_nsca
# vi /etc/send_nsca.cfg

Und siehe da – schon funktioniert das Ganze wieder:

PASSIVE SERVICE CHECK: somehost;HW: CPU;0;OK - load average: 0.20, 0.18, 0.26

:)

NRPE-Addon für IPCop 2.x

Veröffentlicht am von
Kommentar

Wie ich vor einigen Tage bereits erwähnte, arbeite ich an einem NRPE-Addon für IPCop 2.x. Gestern habe ich es fertiggestellt und auf einer Projektseite veröffentlicht.

Wer seinen IPCop auch gerne mit Nagios überwachen möchte, kann dort einmal vorbeischauen und das Addon herunterladen: http://ipcop.stankowic-development.net

Happy monitoring! :)

Zeit für ein IPCop-Upgrade

Veröffentlicht am von
1

Seit 2008 verwende ich IPCop als lokale Firewall und Gateway nach “Draußen“. Während das System erst auf einem IBM NetVista 8364-EXX lief, zog ich es 2009 auf einen ALIX.2D13 um, um Strom zu sparen.

Seither lief das System unverändert mit IPCop 1.4.21, auch wenn es seit September 2011 mit IPCop 2.0 einen interessanten Nachfolger gab. Einer der Gründe, warum ich kein Upgrade durchgeführt habe, war die VPN-Anbindung.

Bis vor einiger Zeit verwendete ich für VPNs das PPTPD-Plugin für IPCop – dieses gibt es lediglich für Version 1.4.x. PPTP war die einfachste Lösung, einen VPN-Zugang auf mein Netzwerk von meinem Android-Smartphone/-Tablet aus zu ermöglichen. Vor kurzem stieß ich auf eine Lösung, die es mir ermöglicht, meine Androiden mittels OpenVPN an den IPCop zu koppeln. Somit stand einem Upgrade endlich nichts mehr im Wege.

Die meisten meiner verwendeten Addons stehen für den neuen IPCop zur Verfügung, wie ich mithilfe einer Liste im IPCop-Forum herausfinden konnte:

IPCop 1.4.x IPCop 2.0.x
ZERINA OpenVPN direkt integriert
Coptime für 2.0.x verfügbar: [klick mich!]
wlanapd für 2.0.x verfügbar: [klick mich!]
WOL-GUI für 2.0.x verfügbar: [klick mich!]
NRPE nicht verfügbar

Nun konnte ich auch endlich eine herumliegende n-Draft WLAN-Karte einbauen und verwenden. Diese Karte war unter IPCop 1.4.21 leider nicht zur Arbeit zu motivieren.

NRPE steht leider noch nicht als fertiges Addon zur Verfügung, weswegen ich mich dazu entschied, NRPE samt Nagios-Plugins selbst für IPCop zu portieren. Die Übersetzung habe ich bereits erfolgreich durchgeführt – ich bin gerade dabei, das Ganze sauber zu paketieren, damit auch andere etwas davon haben. :)

Das Upgrade gestaltete sich aufgrund eines Bugs in IPCop 2.0.0 und 2.0.3 (die bisher erschienenen Releases mit ISO-Abbild) leider ein wenig schwieriger, als erwartet. Bei den o.g. Versionen wird die erste erkannte serielle Schnittstelle nicht in der inittab vermerkt, was dazu führt, dass das System bootet, man es aber nicht fernsteuern kann. Beim von mir verwendeten ALIX.2D13 ist so mit dem Gerät erstmal nichts anzufangen, da er nicht über VGA verfügt.

Ich habe das Problem gelöst, indem ich IPCop auf einem ALIX.1D installiert habe und die CF-Karte anschließend im ALIX.2D13 verbaut habe. Wichtig ist, dass vor dem Reboot nach erfolgter Installation die letzte Zeile in der Datei /etc/inittab wie folgt korrigiert wird:

#7:2345:respawn:/sbin/agetty -I '\033(K' ttyS0 9600 vt102
7:2345:respawn:/sbin/agetty -I '\033(K' ttyS0 38400 vt102

Die Installation der ersten Updates modifizierte die inittab wieder – idealerweise überprüft man diese Datei also nach der Installation von Updates, damit man im Zweifelsfall an das System kommt.

Kurztipp: Cronjob-Debugging

Veröffentlicht am von
Kommentar

Die Tage hatte ich das Problem, dass ein selbst geschriebenes Skript, welches Festplatten-Temperaturen überwacht und an Icinga reportet, als Cronjob nicht funktioniert. Manuell aufgerufen funktionierte es einwandfrei:

# check_hddtemp.sh /dev/sda
OK: /dev/sda has a temperature of 32 degrees celsius (thresholds 40/50)

Per Cronjob meldete mir Icinga leider andere Werte:

CRITICAL: hddtemp had a error - check hard drive name (/dev/sda)!

Um Cronjobs zu debuggen, empfiehlt es sich erstmal, das Log-Level des Cron-Dienstes zu erhöhen. Unter Debian muss dazu die Datei /etc/default/cron editiert werden:

# vi /etc/default/cron
...
# Extra options for cron, see cron(8)
# For example, set a higher log level to audit cron's work
# EXTRA_OPTS="-L 2"
EXTRA_OPTS="-L 2"

Nachdem die Änderungen übernommen wurden, wird der Dienst neu gestartet:

# service cron restart

Im Log sollte man jetzt sehen, wann welche Skripte ausgeführt werden:

# tail -f /var/log/syslog
...
13:00:01 /USR/SBIN/CRON[5047]: (root) CMD (bash /opt/icinga_inventory.sh)
13:00:16 /USR/SBIN/CRON[5045]: (root) END (bash /opt/icinga_inventory.sh)

Das Skript wird also ausgeführt und läuft 15 Sekunden – also schon mal kein abgebrochenes Programm aufgrund fehlender Rechte oder dergleichen.

Cronjobs werden in aller Regel ohne Umgebungsvariablen und leerer PATH-Variable gestartet. Was passiert, wenn das Skript ohne Umgebungsvariablen und leerer PATH-Variable gestartet wird?

# PATH="" ./check_hddtemp.sh /dev/sda
./check_hddtemp.sh: 37: cut: not found
./check_hddtemp.sh: 37: sed: not found

# PATH="/bin:/usr/bin" ./check_hddtemp.sh /dev/sda
OK: /dev/sda has a temperature of 32 degrees celsius (thresholds 40/50)

Schau an – da haben wir doch schon die Problemursache! Jetzt kann man entweder das Skript um absolute Pfade erweitern oder der crontab eine PATH-Variable mitgeben. Absolute Pfade in Skripten sind nicht immer die beste Lösung, wenn das Skript auch auf anderen Rechnern lauffähig sein soll. Hier könnten sich die Pfade ändern, was wieder Modifikationen am Skript bedeuten würde (hier ist das zwar nicht so schlimm, weil Standard-Tools im Skript verwendet werden, geht aber ums Prinzip. :P ). Schöner ist es, das Ganze per PATH-Variable zu steuern:

# crontab -e
...
PATH="/bin:/usr/bin"
...

Und siehe da, seitdem geht das Festplatten-Temperaturmonitoring auch per Cron. :)

Kurzanleitung: Icinga 1.6.x unter Debian Squeeze

Veröffentlicht am von
Kommentar

Wer Icinga unter Debian Squeeze einsetzen will, hat da in aller Regel erstmal zwei Möglichkeiten: entweder er verwendet die veraltete Version aus dem Standard-Repository – oder er kompiliert selbst.

Letzteres ist oftmals aufwändig und kann selbst nach langer Zeit noch ungewollte Effekte ans Tageslicht bringen, wenn man irgendwo einen kleinen Fehler gemacht hat.

Zum Glück ist die aktuellste Icinga-Version im Debian Squeeze-Backports Repository vertreten – eine Installation ist einfach über apt-get möglich.

 

Zuerst muss das Backports-Repository in die Paketquellen aufgenommen werden (/etc/apt/sources.list):

 

deb http://backports.debian.org/debian-backports squeeze-backports main

 

Nach dem Neueinlesen der Paketquellen kann Icinga aus dem Backports-Repository bezogen werden:

 

# apt-get update
# apt-get install -t backports icinga

 

Im Lauf der Installation wird Apache2 in der Regel automatisch installiert und konfiguriert, sodass binnen weniger Minute ein vorkonfiguriertes Icinga-Grundsystem benutzt werden kann.

Happy Monitoring! :)

Entfernten Router ohne Portfreigabe und Ping in Nagios auf Verfügbarkeit überprüfen

Veröffentlicht am von
Kommentar

Hosts lassen sichmit einem Trick auch dann auf Verfügbarkeit überprüfen, wenn sie keine offenen Dienste anbieten. Ich verwende den folgenden Trick beispielsweise um mitzubekommen, wenn in meiner alten Heimat das Internet ausfällt. Da ich dort keinen Server hinter der Firewall im Router hängen habe, gehe ich also direkt an den Router. Dieser benötigt dringend die Dyndns-Funktion, damit er nach jedem Reconnect seine IP auf einen Hostname mappt.

Wenn dies gegeben ist, schaut man mit einem NMAP-Scan einfach mal, welche Ports der Router zur Verfügung stellt – hierbei werden auf nicht offene Ports angezeigt:

 

# nmap -PN HOSTNAME-DES-ROUTERS

Starting Nmap 5.00 ( http://nmap.org ) at 2012-01-26 22:14 CET
Interesting ports on hostname-des-routers (ip-adresse-des-routers):
Not shown: 999 filtered ports
PORT     STATE  SERVICE
5060/tcp closed sip

Nmap done: 1 IP address (1 host up) scanned in 76.13 seconds

 

In diesem Fall ist der Router über den Port 5060 (VoIP) erreichbar (typisch für aktuelle Router mit VoIP-Funktionalität) – ein Verbindungsversuch wird abgewiesen:

 

# telnet HOSTNAME-DES-ROUTERS 5060
Trying xx.yy.zz.iii...
telnet: Unable to connect to remote host: Connection refused

 

Wenn der Router nicht zur Verfügung steht, kommt es hier zum Timeout anstatt zur Ablehnung der Anfrage – diesen Effekt kann man sich zunutze machen und herauszufinden, ob der Router am Netz hängt. Es wird also einfach ein Host für den Router in Nagios definiert. Normalerweise überprüft Nagios definierte Hosts erstmal anhand der hinterlegten IP und PING auf Verfügbarkeit – da dies hier ja nicht möglich ist, wird ein dediziertes Check-Kommando und ein höherer Überprüfungsintervall definiert. Als Folge hiervon wird der Host z.B. alle 30 Minuten überprüft und als Online markiert, wenn die Verbindungsanfrage abgewiesen wird.

 

Zunächst einmal wird das Kommando definiert:

 

# nano commands.cfg
...
define command{
        command_name    check-host-alive-by-voip-refused
        command_line    $USER1$/check_tcp -H $HOSTADDRESS$ -p 5060 -r ok
}

…dannach folgt der Host mit oben genannter Anpassung:

 

# nano router-blah.cfg
define host{
        use linux-server
        host_name router-blah
        alias blah
        address HOSTNAME-DES-ROUTERS
        check_command check-host-alive-by-voip-refused
        check_interval 30
        max_check_attempts 2
        }

 

Die Zuordnung check_interval 30 steht hier für eine Überprüfung im Abstand von 30 Minuten. Ich persönlich würde hier nicht den Standard-Wert von 5 Minuten übernehmen – ich kann mir vorstellen, dass der ISP hier vielleicht einen Angriff vermutet und Gegenschritte unternimmt (wenn einer der Admins wirklich mal auf die Leitung schauen sollte :P ).

Nach einem erneuten Einlesen der Nagios-Konfiguration sollte das Ganze ohne Probleme funktionieren:

 

# service nagios reload

 

Router-Überwachung in Nagios

Router-Überwachung in Nagios

 

Mal schauen, wie lange es dauert, bis der ISP mir Stress macht. :D