Prinzipiell soll hier noch einmal angemerkt werden, dass all meine Beiträge zum Thema Icinga Monitoring davon ausgehen, dass man sich die Dokumentation der einzelnen Pakete angeschaut hat. Ich erkläre nicht jede Kleinigkeit – ich gehe auf Probleme ein die mich viel Zeit gekostet haben oder mache Notizen zu Sachen die mir wichtig erscheinen! Meine Tutorials ersparen also auf keinen Fall das Studium der Icinga oder LConf Dokumentation.

Grundsätzliche Überlegungen

Ich würde mit einem Block und einem Stift beginnen und mal aufschreiben was für Hosts überwacht werden sollen, was auf den verschiedenen Hosts geprüft werden soll und wann welche Checks interessant sind. Weiters muss man sich überlegen wer wann welche Benachrichtigungen bekommen soll. Wenn man das hat kann man anfangen LConf zu füttern.

Global oder nicht Global

Man kann Commands, Kontakte etc. global anlegen oder nur für einzelne Hosts. Man sollte sich also auch überlegen was global verteilt werden soll und was nur für bestimmte Hosts, Hostgruppen etc. relevant ist. Im Zweifelsfall kann ja zu Beginn mal alles global gemacht werden.

Commands

Auf Basis der vorher erstellten Liste können nun alle benötigen Commands angelegt werden. Der Wert der Property lconfcommandline ist die der auszuführende Command. Also zum Beispiel $USER1$/check_esxi_hardware.py -H $ARG1$ -V $ARG2$ -U file:/pfad/nach/irgendwo/ud/.$ARG1$ -P file:/pfad/nach/irgendwo/ud/.$ARG1$. Hiermit würden wir dem Command also das check_esxi_hardware.py Script zuweisen.

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

Contacts

Hat man alle Commands angelegt kann man sich an die Contacts machen. Die wichtigsten Properties bei den Commands sind zu Beginn wohl

Die oben angeführten Properties sind für den Host und können, abgewandelt, natürlich auch für die Services vergeben werden (z.B. lconfcontactservicenotificationoptions).

Timeperiods

In den Timeperiods werden alle benötigten Zeiträume definiert. Wenn also ein bestimmter Service nur Montags und Mittwochs zwischen 08:00 und 14:30 Uhr überprüft werden soll, dann muss es dafür eine eigene Timeperiod geben.

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

Templates

Auf Basis der erstellten Liste würde ich als nächstes Vorlagen anlegen. Dazu habe ich mir in meinem LConf Baum einen Zweig Templates angelegt. Hier habe ich dann verschiedene Structural Objects angelegt und dort dann die entsprechenden Commands definiert.

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

Diese Structural Objects verwende ich dann als Aliases in den jeweiligen Hosts. Im Screenshot unten verwende ich also mein Templates des_vserver und des_webserver.

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

Distributed Monitoring

In LConf spielen die sogenannten Descriptions eine wichtige Rolle. In den Descriptions können Parameter für die Verteilung der Konfiguration angegeben werden.

Folgende Descriptions sind für Distributed Monitoring relevant

LCONF->EXPORT->CLUSTER

Hiermit kann festgelegt werden, dass dieser Zweig via SSH an einen Remotehost übertragen wird.

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

Eigentlich sollte es möglich sein, hier einen FQDN anzugeben. Leider hat das bei mir nicht geklappt. Vielleicht kann das ja mal jemand testen und wenn auch er Probleme damit hat, dann wäre dieses Ticket hier der richtige Punkt um zu meckern. Ich umgehe dieses Problem aktuell damit, dass ich für LCONF->EXPORT->CLUSTER eine Wert in der Art KUNDENNAME hinterlege und dann einen Eintrag in /etc/hosts mache:

# hosts entry until Netways fixes the bug with FQDN in LCONF->EXPORT->CLUSTER
kundenname 195.87.228.35

LCONF->EXPORT->MODIFY->HOST

Hiermit kann festgelegt werden was beim Export auf einen externen Host verändert werden soll. Bei Distributed Monitoring sollen ja auf dem Central Server keine aktiven Checks ausgeführt werden. Man konfiguriert den Host also wie folgt:

Also auf dem Central Server (auf dem auch LConf for Icinga läuft) wollen wir keine aktiven Checks, beim Export auf den Distributed Server sollen aber aktive Checks gesetzt werden.

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

LCONF->EXPORT->MODIFY->SERVICE

Auch Eigenschaften von Services können mittels Desriptions beim export auf entfernte Server verändert werden. Dies funktioniert analog zu LCONF->EXPORT->MODIFY->HOST

Vererbung von LCONF->EXPORT->MODIFY->HOST und LCONF->EXPORT->MODIFY->SERVICE

Leider werden die Werte von LCONF->EXPORT->MODIFY->HOST und LCONF->EXPORT->MODIFY->SERVICE momentan nicht vererbet. Man kann also nicht beim Structural Object sagen, dass alle HOST und SERVICE Einträge beim Export umgeschrieben werden sollen. Vielleicht wird dieser Bug ja schneller behoben wenn der Ein oder Andere einen Kommentar zu meinem Ticket bei Netways hinterlässt.

Ich hoffe ich konnte hier ein bisschen Licht ins Dunkel bringen. Bei Fragen versuche ich gerne zu helfen …

Zu allererst erstellen wir einen User in Icinga Web. Dazu loggen wir uns unter http://host.domain.tld/icinga-web ein und klicken dann oben links auf Admin und anschließend auf Users. Nach einem Klick auf Add new user können hier die Daten eingegeben werden.

Wichtig sind folgende Werte

• Auth via: auth_key
• Authkey for Api: EIN_KEY_FÜR_DEN_MOBILE_ZUGRIFF
• Permissions: appkit_user

Für den User braucht zwar eigentlich nur einen Auth Key, aber aus irgendeinem Grund verlangt Icinga Web auch nach einem Passwort.

Anschließend können wir Icinga Mobile installieren

cd /usr/src
git clone git://git.icinga.org/icinga-mobile.git
./configure
make install
make install-apache-config
/etc/init.d/apache2 reload

Der Zugriff erfolgt dann über ein Smartphone/Tablet via http://host.domain.tld/icinga-mobile. Bevor man überhaupt irgendwas angezeigt bekommt, muss man die Config anpasssen. Hier muss die URL zu Icinga Web und der vorhin vergebene Auth Key eingegeben werden.

Man darf sich auch nicht verwirren lassen, bei jedem Aufruf von Icinga Web kommt ein Screen mit Informationen zur Version. Auf diesen einfach einmal tippen um zum eigentlich Interface zu kommen.

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

Loading...
the ultimate flickr Wordpress plugin (http://tufwp.hirnschmalz.at)

Im nächsten Teil des Tutorials gehe ich ein bisschen näher auf LConf und Distributed Monitoring ein.

Nachdem ich letzten Eintrag erklärt habe wie man sprechende Namen für temporäre Bilddaten vergeben kann ist die Lösung schon ganz nah.

Der Trick ist, dass man im GIFBUILDER Objekt als erstes ein TEXT Objekt erstellt und diesem einen bestimmten Wert gibt. Somit kann sichergestellt werden, dass alle Dateien die mit diesem GIFBUILDER Objekt erstellt werden mit diesem Text beginnen.

Jetzt kann man einen Cronjob einrichten der in bestimmten Abständen diese Files löscht.

Wenn unser Typoscript Code so aussieht

image = IMAGE
image.file = GIFBUILDER
image.file {
  XY = 600,600
  backColor.data = GP:desFontViewer|bcol

  1 = TEXT
  1.text = hsSpecialImage
  1.offset = -100,-100

         :
         :
         :

können wir sagen, dass alle Bilder die von diesem GIFBUILDER Objekt erstellt werden mit hsSpecialImage beginnen. Somit können wir in unserem Cronjob festlegen, dass wir alle Files die so beginnen löschen.

Ist doch ziemlich cool – oder?

Standardmäßig erstellt GIFBUILDER Dateien mit Namen in der Art

89a949abb6.png

Mit folgender Zeile Typoscript kann das geändert werden

config.meaningfulTempFilePrefix = 50

Damit wird festgelegt, dass temporäre Bilddaten einen Namen mit 50 Zeichen erhalten sollen und dieser Name sprechend sein soll. Anschließend sehen die Dateinamen folgendermaßen aus

hsBild_einBisschenText_wieGehtDas__fae0f2fd6c.png

In der Typoscript Reference wird auch erklärt wie dieser Name zustande kommt:

If > 0 TYPO3 will try to create a meaningful prefix of the given length for the temporary image files.
This works with GIFBUILDER files (using content from the GIFBUILDER TEXT objects as a base for the prefix), menus (using the title of the menu item) and scaled images (using the original filename base).

Als erstes installieren wir ein paar Pakete die wir später unter Umständen benötigen

aptitude install linux-headers-2.6-amd64 build-essential

Sollte jemand einen anderen Kernel als den 2.6er verwenden muss die Version dementsprechend angepasst werden. Wer nicht weiß welchen Kernel er installiert hat kann das mittels

uname -a

herausfinden. Er sollte dann eine Ausgabe in der Art

Linux RECHNERNAME 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux

bekommen.

Nun muss im vSphere Client unter VM im Unterpunkt Gast die Option VMware Tools installieren/aktualisieren ausgewählt werden

Anschließend steht in Gastsystem eine CD mit den aktuellen VMware Tools zur Verfügung. Nun können wir uns also daran machen diese zu installieren

mount /media/cdrom
cd /usr/src
cp /media/cdrom/VMwareTools-8.6.0-446312.tar.gz ./
umount /media/cdrom
tar zxf VMwareTools-8.6.0-446312.tar.gz
cd vmware-tools-distrib/
./vmware-install.pl

Zuerst besorgen wir uns mal ein paar Pakete die wir brauchen

aptitude install git automake autoconf build-essential libtool pkg-config

Dann können wir uns den aktuellen Sourcecode aus dem GIT-Repository holen

cd /usr/src
git clone git://netatalk.git.sourceforge.net/gitroot/netatalk/netatalk
cd netatalk
./bootstrap

Und schlussendlich noch ein paar notwendige Debianpakete laden und netatalk kompilieren und installieren

aptitude install libgcrypt11-dev libssl-dev libavahi-core-dev libavahi-client-dev avahi-daemon  libslp-dev slpd libdb-dev libwrap0-dev libcrack2-dev libpam0g-dev
./configure --enable-debian --enable-srvloc --enable-ddp --with-cracklib
make && make install

Hat doch gar nicht weh getan – oder :)

Das war gar nicht so schwer

ar x name_des_pakets.deb
tar zxf data.tar.gz

Wenn doch nur alles so einfach wäre …

Voraussetzung dieses Unterfangen ist eine gejailbreakte ATV2. Das klingt jetzt komplizierter als es ist. Alles was man dazu benötigt ist

• ein Rechner mit iTunes
• eine Apple TV 2
• ein Micro USB Kabel
• die Software Seas0npass von Firecore
• und natürlich eine Dreambox mit Enigma2 Webinterface

Danach muss man nicht mehr tun als Seas0npass zu starten und den Anweisungen zu folgen. Die einzige Stolperfalle die es hier gibt: lasst die ATV2 für weitere fünf Minuten an eurem Rechner angeschlossen wenn Seas0npass sagt, dass die ATV2 getrennt werden kann. Tut ihr dass nicht, kann es passieren, dass der Jailbreak fehlschlägt.

Anschließend kann die Apple TV 2 wieder an den Fernseher angeschlossen werden. Man kommt nun via SSH auf die ATV2 (root/alpine) und kann sich nitoTV installieren

cd /usr/src
apt-get install wget
wget http://dl.dropbox.com/u/16129573/com.nito.deb
dpkg -i com.nito.deb
apt-get update
apt-get install com.nito.nitotv
killall Lowtide

Nun kann über das nitoTV Menü auf dem Bildschirm XBMC installiert werden. Jetzt haben wir alle Grundpakete installiert. Was jetzt noch fehlt ist ein XBMC AddOn mit dem wir auf das Enigma2 Webinterface der Dreambox zugreifen können. Dieses wird freundlicherweise von NiBuDev zur Verfügung gestellt.

Das Zip-File herunterladen und auf die ATV2 in das Verzeichnis /Applications/XBMC.frappliance/XBMCData/XBMCHome/addons /private/var/mobile/Library/Preferences/XBMC/addons kopieren.

vim installieren und die Konfigurationsdatei bearbeiten (IP-Adresse der Dreambox eintragen)

apt-get install vim
cd plugin.video.nibuxbmcenigma2/
vim resources/settings.xml

Nach einem Neustart von XBMC kann unter Videos / Video Add-ons / NiBuDev Enigma2 Viewer auf die Bouquets der Dreambox zugegriffen werden.

Ein Aufwand von ca. einer halben Stunde der sich lohnt!

Ich gehe in diesem Tutorial prinzipiell davon aus, dass die Verwaltungstools auf dem Central Server installiert werden. Sollte das bei jemandem nicht so sein, muss die Installation dementsprechend angepasst werden.

Icinga Web

Als erstes holen wir uns die aktuellen Sourcen und kompilieren Icinga Web. ICINGA_WEB_MYSQL_PASSWORT ist das Passwort welches Icinga Web für den DB-Zugriff verwenden soll und ICINGA_MYSQL_PASSWORT ist jenes Passwort, das wir im ersten Teil dieses Tutorials bei der Grundinstallation festgelegt haben.

cd /usr/src
git clone git://git.icinga.org/icinga-web.git
cd icinga-web/
./configure --prefix=/usr/local/icinga-web --with-web-user=www-data --with-web-group=www-data --with-web-path=/icinga-web --with-web-apache-path=/etc/apache2/conf.d --with-db-type=mysql --with-db-host=localhost --with-db-port=3306 --with-db-name=icinga_web --with-db-user=icinga_web --with-db-pass=ICINGA_WEB_MYSQL_PASSWORT --with-icinga-api=/usr/local/icinga/share/icinga-api --with-api-db-user=icinga --with-api-db-pass=ICINGA_MYSQL_PASSWORT
make install
make install-apache-config
make install-done
echo "memory_limit = 256M" > /etc/php5/apache2/conf.d/memory_limit.ini
make testdeps

Liefert make testdeps Fehler zurück so müssen diese zum jetztigen Zeitpunkt behoben werden.

Anschließend muss noch die Apache-Konfiguration mittels

/etc/init.d/apache2 reload

neu geladen werden.

Im nächsten Schritt erstellen wir die Datenbank die Icinga Web benötigt.

mysql -u root -p
CREATE DATABASE icinga_web;
GRANT USAGE ON *.* TO 'icinga_web'@'localhost' IDENTIFIED BY 'ICINGA_WEB_MYSQL_PASSWORT' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX ON icinga_web.* TO 'icinga_web'@'localhost';
FLUSH PRIVILEGES;
quit
make db-initialize

Zum Schluss noch die Rewrite Enginge für Apache aktivieren

a2enmod rewrite
/etc/init.d/apache2 restart

Und schon kann man sich mit den Defaultlogindaten (root/password) auf http://www.mein-icinga-center-server.tld/icinga-web/ anmelden.

LConf

LConf bietet die Möglichkeit die Icinga-Konfiguration in einem LDAP-Verzeichnis zu speichern. Nach Änderungen kann aus dem LDAP-Zweig die entsprechende Konfiguration exportiert werden.

Zuerst ein paar Vorbereitungsarbeiten

aptitude install slapd ldap-utils php5-ldap libnet-ldap-perl
rm -rf /etc/ldap/slapd.d/
dpkg-reconfigure slapd

Nun können wir LConf herunterladen und installieren

cd /usr/src
git clone git://git.netways.org/lconf.git
cd lconf
./install.sh

Bei der Installation können eigentlich immer die Standardwerte bestätigt werden. Nur der LDAP rootdn muss angepasst werden!

Jetzt können wir das notwendige Schema erstellen

cd /usr/src
echo "include /etc/ldap/schema/core.schema" > netways_lconf_convert.conf
echo "include /etc/ldap/schema/netways.schema" >> netways_lconf_convert.conf
mkdir /usr/src/ldif_output
slaptest -f netways_lconf_convert.conf -F /usr/src/ldif_output

Anschließend muss die /usr/src/ldif_output/cn=config/cn=schema/cn={1}netways.ldif angepasst werden. Ganz oben folgende Zeilen einfügen

dn: cn=netways,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: netways

und ganz unten müssen die letzten sieben Zeilen gelöscht werden

structuralObjectClass: olcSchemaConfig
entryUUID: d630f970-2e08-1030-9a62-3766fadb1a42
creatorsName: cn=config
createTimestamp: 20110618151024Z
entryCSN: 20110618151024.514100Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20110618151024Z

Nachdem das alles gemacht ist sollte es eigentlich keine Probleme beim Import des Schemas geben

ldapadd -Y EXTERNAL -H ldapi:/// -f /usr/src/ldif_output/cn\=config/cn\=schema/cn\=\{1\}netways.ldif
/etc/init.d/slapd restart

ldapadd -x -D "cn=admin,dc=DEINE_LDAP_BASE_DSN" -W -f /usr/src/lconf/source/base.ldif

LConf for Icinga

LConf for Icinga ist ein AddOn für Icinga Web. Nach der Installation kann die Konfiguration in Icinga Web verändert und exportiert werden.

Auch hier beginnt wieder alles mit den aktuellen Sourcen

cd /usr/src
git clone git://git.netways.org/lconf-icinga-mod.git
cd lconf-icinga-mod

Es müssen noch die Logindaten für die Icinga Web Datenbank publik gemacht werden

vim db.ini

und dann kann installiert werden

./install.sh

Nach der Installation muss man sich am Icinga Web anmelden und links oben auf Admin und dann auf Users klicken. Jetzt kann man mit einem Doppelklick auf den entsprechenden Benutzer dessen Eigenschaften bearbeiten.

Damit LConf für Icinga angezeigt wird, muss unter Principials auf den grünen Kreis mit dem Plus geklickt werden. Es müssen folgende Credentials hinzugefügt werden:

• lconf.admin
• lconf.user

Nach dem man sich aus- und anschließend wieder eingeloggt hat, findet man oben neben dem Admin Button der Knopf für die LConf Administration.

Damit der Export der Konfiguration aus dem Webinterface funktioniert sind noch ein paar kleine Anpassungen notwendig

chmod 640 /etc/sudoers && echo "www-data ALL=(icinga) NOPASSWD: ALL" >> /etc/sudoers && chmod 440 /etc/sudoers
/etc/init.d/sudo restart
mkdir /usr/local/icinga/lconf.tmp
chown icinga:icinga /usr/local/icinga/lconf.tmp/

Noch eine letzte Anpassung in der access.xml

vim /usr/local/icinga-web/app/modules/Api/config/access.xml

						<ae:parameter name="x">
                                <ae:parameter name="files">
                                        		:
                                        		:
                                        		:
                                        		:
                                        <ae:parameter name="lconf_export">sudo -u icinga /usr/local/LConf/lconf_deploy.sh</ae:parameter>
                                </ae:parameter>
                        </ae:parameter>

Momentan gibt es einen kleinen Bug in der lconf_deploy.sh. Um diesen zu korrigieren bitte einfach im Redmine von NETWAYS nachschauen.

Anschließend müssen in /usr/local/icinga/etc/icinga.cfg alle cfg_dir (außer cfg_dir=/usr/local/icinga/etc/modules)bzw. cfg_file auskommentiert werden. Zusätzlich muss das Verzeichnis angegeben werden in welches LConf die Konfiguration schreibt:

cfg_dir=/usr/local/icinga/etc/lconf

So liebe Leute: nun habt ihr eine ordentliche Grundinstallation auf der aufgebaut werden kann. Wer noch Fragen oder Probleme hat kann gerne hier posten und ich werde versuchen zu helfen.

Hinweis

Es gibt im Moment ein paar Probleme beim Export der Konfiguration auf die Distributed Server. Sobald diese gelöst sind werde ich auf meiner Webseite eine entsprechende Anleitung online stellen.
Nach einiger Recherche und Kontakt mit Netways (vielen Dank an dieser Stelle) habe ich es schlussendlich doch noch geschafft Distributed Monitoring mittels LConf zu konfigurieren. Hier ein paar Hinweise dazu.

Ein paar kurze Worte zu Icinga Mobile gibt’s im vierten Teil des Tutorials zu lesen.

Gestern haben wir uns noch die Warner Brother Studios angeschaut. Wirklich verrückt mit welchen Tricks dort gearbeitet wird. Wir haben die Drehorte von ‘The Big Bang Theory’, ‘The Mentalist’ und auch den ‘Gilmore Girls’ gesehen. Interessant waren auch die Gebäude in denen die Verwaltungsbüros untergebracht sind. Die sind alle so gestaltet, dass man sie in Filmen verwenden kann. Eins sieht aus wie ein Motel, ein anderes sieht aus wie ein Flughafenterminal und wieder andere Büros sind in ganz normalen Häusern untergebracht.

Danach ging’s dann in die Downtown von Los Angeles wo wir das Rathaus und die Walt Disney Concert Hall gesehen haben.

Danach haben wir uns außerhalb von L.A. die Watts Towers angeschaut. Dort hat der Künstler Sam Rodia in 33 Jahren Handarbeit (ohne technische Hilfsmittel) aus Beton und Müll riesige Türme gebaut. Die Gegend ist zwar nicht unbedingt die Schönste, aber das Kunstwerk war die kleine Reise wert.

Den Abschluss bildete ein Besuch von Venice Beach. Das ‘LLoret de Mar von Amerika’ wie Michi meint. Hier schmeckt es nach viel verbrenntem Gras und es gibt allerlei Krimskrams am Strand zu kaufen.