Apr/092
Nagios checks for Polycom GMS global directory entries
I administrate some Polycom video conferencing endpoints which are managed trough an instance of Polycom Global Management System (GMS). The video endpoints also use the Global Directory Service which is provided by the GMS. Some day I experienced problems where the clients could not recieve the entries of the global addressbook. In some cases this was the result of a problem on the GMS system where the addressbook was suddenly empty for some reason.
To identify the source of the problem faster in future I wanted to track the number of entries provided by the global addressbook. Since we use Nagios as monitoring plattform it was clear to write a new plugin for monitoring the number of addressbook entries. Read how I realized that check…
Feb/091
Nagios: Polycom RMX2000 port usage monitoring
Some days ago I was asked to monitor the usage of a RMX 2000 Real-Time Media Conferencing Platform from Polycom. Basically it is a video- and audio-conferencing bridge to host multi point conference calls. The bridge capacities are defined by the number of ports. You can assign these ports to audio- and video-processing. There is a small graph on the web interface of that bridge to see the current usage of these ports but there is no historical view for the port usage.
After some research I found a development kit on the usb stick with the current firmware release. You can download it at the download page of rmx 2000 on polycom website.
The development kit provides some documents describing the XML API and some tool to spy the xml requests and responses from and to the RMX 2000 bridge.
Using this sdk I created a simple check script in perl for monitoring the bridge port usage with Nagios. The script connects to the bridge, logs in and reads the current port usage. It outputs the current port usage as normal plugin output and as performance data for graphing.
You need to provide a valid user and password to the script to log in to the XML API. The monitoring account needs at least moderator privileges on the RMX 2000.
Hopefully this will help someone.
You can find the check plugin on the plugins page in projects section.
Jan/090
Howto install ndo2fs 0.1.14
I described the concept of ndo2fs in another article before. In this article I’ll show you the steps I made to get a working installation of ndo2fs. These are the preparing steps to use NagVis on basis of ndo2fs.
Note: I recommend ndo2fs for all users who use – or want to use – the ndo only for NagVis purposes. If you don’t need any historical information in your ndo database (e.g. for reporting or SLA analyzing) you should give ndo2fs a try. It’s a lightweight and stable alternative to the NDO on MySQL basis.
Jan/092
Introducing ndo2fs
You never heard of ndo2fs? I’m sure you know ndo2db which is part of the Nagios addon ndoutils. In short ndo2fs is a lightweight alternative to ndo2db. Both of them, ndo2fs and ndo2db, gather information which are present in Nagios core and save them in an ordered way. Ndo2fs receives information from ndomod.o via TCP- or UNIX-socket and stores the data formated in JSON as plain text files in a hierarchical folder structure.
The big benefits to ndo2fs are:
- Ndo2fs is extremely smart. Ndo2fs is a perl script with about 1200 lines of code.
- The needed space for current data is extremely small.
- You don’t need a whole DBMS for storing the data.
- Ndo2fs consumes much less cpu time and memory than ndo2db and the used DBMS together.
Jan/090
My personal story about and with NagVis
I spent some hours brainstorming, writing down my memories and collecting information about the history of NagVis. Finally I have created a page about the whole history of the NagVis project. I call it: My personal story about and with NagVis.
It was a good feeling to read the finished article. I can say: I’m proud to see NagVis where it is.
Thanks to the community and all of you who are or were involved in the NagVis project.
Apr/080
Anmeldung zum Nagios Workshop 2008 gestartet
Heute Morgen hat Michael (Mickey2002) die Anmeldung zum diesjährigen Nagios Workshop freigeschaltet.
In einer Hauruck-Aktion haben wir gestern das Anmelde-Tool zusammengestrickt. Die Anmeldung/Abmeldung ist relativ einfach gehalten. Die Verwaltung läuft komplett über Mails. Die eingegangen und bestätigten Anmeldungen werden im Nagios-Wiki gespeichert.
Auf der Workshop-Seite im Nagios-Wiki finden sich auch alle weiteren Informationen wie Ort, Termin und Themen.
Wie jedes Jahr richtet sich der Workshop an Nagios Administratoren und solche, die es werden möchten. Der Workshop hat einen starken technischen Schwerpunkt und soll eine gesunde Mischung aus Frontal-Vorträgen und Workshops sein. Wer also etwas interessantes zum Thema Nagios zu erzählen hat, oder einfach nur einen Themen-Vorschlag hat, der kann sich gerne im Workshop-Forum melden.
Der Andrang auf die begehrten Plätze wird sicherlich, so wie in den letzten Jahren auch, recht groß sein. Es lohnt sich also sich rechtzeitig um die Anmeldung zu kümmern. Die erste Bilanz zu den Anmeldungen: Nach zwei Stunden bereits 10 angemeldete Teilnehmer.
Im Zusammenhang mit dem Workshop werde ich hier noch einige Einträge verfassen, vielleicht komme ich dann auch dazu ein paar Live-Einträge vom Workshop zu schicken.
Jul/074
Nagios: check_by_ssh auf gewünschte Befehle beschränken
Hallöchen, ich experimentiere seit einiger Zeit mit dem Ausführen von lokalen Plugins durch Nagios auf entfernten Rechnern. Auf Linux-Systemen gefällt mir der Zugriff über SSH am besten. In den meißten Setups findet die Authentifizierung über einen Public-Key statt (Kurze Anleitung zur Einrichtung). Das Problem ist in meinen Augen, dass der Zugriff auf dem Zielsystem nicht geschützt und ausreichend eingeschränkt ist. SSH bietet da glücklicherweise einige Möglichkeiten. Auf dem Zielrechner kann man einen bestimmten Public-Key an einen einzigen Befehl oder an ein Script binden, der beim Login mit diesem Key immer ausgeführt wird. Das ist insofern unflexibel, als das man dem Befehl keine Parameter übergeben kann. Nach einigen Recherchen und Experimenten ist mir aber auch das gelungen.
Auf jedem überwachten System existiert also ein User Nagios. Dem User wird unterhalb seines Home-Verzeichnisses ein Verzeichniss .ssh (Wichtig: chmod 700) und eine Datei authorized_keys (Wichtig: chmod 600) innerhalb des .ssh Verzeichnisses angelegt. Der Inhalt der Datei sieht dann wie folgt aus:
command="/home/nagios/libexec/check_nagios.sh",from="",no-port-forwarding,no-X11-forwarding
Hier binden wir den Public Key an die IP-Adresse des Nagios-Rechners und ein Wrapper-Script. Wenn ein Key an ein Script gebunden wird, ist es egal, was später in dem SSH-Kommando steht, es wird immer nur dieses Script ausgeführt. Das Wrapper Script wird dann unter /home/nagios/libexec abgelegt. Es dient dazu die Parameter, die per SSH kommen zu verarbeiten und entsprechend dann nur erwünschte Checks auszuführen.
#!/bin/bash # directory where the checks-scripts are stored in strCheckDir=/home/nagios/libexec # Parse original SSH command OFS="$IFS" IFS=" " set -- $SSH_ORIGINAL_COMMAND IFS="$OFS" case "$1" in check_load) strOutput=`$strCheckDir/check_load -w $2 -c $3` intReturn=$? ;; *) strOutput="check not allowed! (arg1=$1)" # UNKNOWN return code intReturn=3 ;; esac echo "$strOutput" exit $intReturn
In diesem Script kann man dan steuern welches Script auf dem Server ausgeführt werden darf.
Zum Testen führe ich folgendes Kommando aus:
sudo -u nagios ./check_by_ssh -l nagios -H -C "check_load 6,5,3 10,6,5" -t 10
Die Magie an dem ganzen steckt in folgender Variable: $SSH_ORIGINAL_COMMAND
Wie oben schon erwähnt wird dadurch, dass der Public-Key an ein Kommando gebunden ist nicht der Befehl ausgeführt, den wir SSH per -C mitgeben, sondern nur das Script, was dem Public-Key zugeordnet ist. Der Befehl, der per SSH übertragen wird verschwindet aber nicht im Nirvana, sondern wird in der Umgebungsvariable $SSH_ORIGINAL_COMMAND abgelegt. Diese muss dann nur noch geparst werden und schon kann man dem fest eingetragenem Script Parameter übergeben.
Viel Spaß damit…
Offers
Projects
Misc
