Trick 17 mit dem Director

Möchte man die Schnittmenge aus mehreren Importquellen im Icinga Director vereinen, so gibt es dafür einen Lösungsweg der bislang vielen noch nicht bekannt ist.

Beispielhaft dienen folgende zwei SQL-Tabellen als Ausgangslage, testhost03 ist dabei nur in der Tabelle “hosts01” enthalten:

MariaDB [cmdb]> SELECT * FROM cmdb.hosts01;
+----+------------+----------+---------+
| id | hostname   | address  | os      |
+----+------------+----------+---------+
|  1 | testhost01 | 10.0.0.1 | Windows |
|  2 | testhost02 | 10.0.0.2 | Linux   |
|  3 | testhost03 | 10.0.0.3 | Windows |
+----+------------+----------+---------+

MariaDB [cmdb]> SELECT * FROM cmdb.hosts02;
+----+------------+----------+---------+
| id | hostname   | address  | os      |
+----+------------+----------+---------+
|  1 | testhost01 | 10.0.0.1 | Windows |
|  2 | testhost02 | 10.0.0.2 | Linux   |
+----+------------+----------+---------+

Um nun die Daten aus beiden Quellen abzugleichen ohne gleich Objekte im Director zu erzeugen, behilft man sich mit einer Datenliste als Zwischenschritt. Die ID der neu erstellten Datenliste wird später benötigt und kann über die Director-Datenbank herausgefunden werden:

MariaDB [director]> SELECT * FROM director.director_datalist WHERE list_name = "Hosts from 2nd import source";
+----+------------------------------+-------------+
| id | list_name                    | owner       |
+----+------------------------------+-------------+
|  2 | Hosts from 2nd import source | icingaadmin |
+----+------------------------------+-------------+

Wie dem Namen der Liste unschwer zu entnehmen ist sollen dort die Hosts aus der 2ten Importquelle, also von “hosts02”, zwischengespeichert werden.

Mit diesen Informationen kann die entsprechende Sync Rule für die Synchronisation der Hosts aus der 2ten Quelle in die Datenliste erstellt werden. Neben der ID als jeweilige “list_id” (hier “2”) werden die Felder “entry_name” und “entry_value” definiert:

Nach dem Syncvorgang erhält die Datenliste die entsprechenden Einträge. Im Beispiel sind das testhost01 und testhost02. In der Import Source für die erste Datenquelle werden deren Einträge nun anhand des “Map”-Modifiers mit den Einträgen aus der Datenliste abgeglichen:

Damit ergibt sich folgende Vorschau der Import Source:

In der darauf aufbauenden Sync Rule ist es wichtig eine entsprechende Filter expression zu setzen:

Ist sie negiert, wie im vorangegangenen Beispiel, werden die Hosts die in beiden Datenquellen vorkommen erzeugt. Im Beispiel wären das testhost01 und testhost02. Liegt keine Negierung vor (z.B. “map=”), so werden nur die Hosts erzeugt die in der zweiten Datenquelle nicht vorkommen. Also beispielhaft testhost03. Damit der Filter greift, muss der Bezeichner (hier “map”) allerdings auch als Eigenschaft der Sync Rule vorkommen.

Der Icinga Director hält noch wesentlich mehr Funktionen für verschiedenste Anwendungsbereiche bereit. Das vorangegangene Beispiel dient lediglich dazu die Fähigkeiten dieses mächtigen Tools etwas zu veranschaulichen. Bei weiteren Fragen rund um den Director oder auch Icinga 2 stehen wir bei NETWAYS natürlich gerne zur Verfügung.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Incredible Icinga Camp Bangalore

Anfang Mai war es so weit: Für mich ging’s ab nach Indien – genauer gesagt nach Bangalore, das eigentlich seit 2014 Bengaluru heißt und das IT-Zentrum des Landes darstellt. Dort fand im Rahmen der diesjährigen rootconf das erste Icinga Camp überhaupt in Indien statt.

Bereits bei Gesprächen mit Teilnehmern auf der zweitägigen rootconf zeichnete sich reges Interesse an Icinga und natürlich insbesondere Icinga 2 ab. Nicht zuletzt trug auch Bernd mit seinem Vortrag “State of the open source monitoring landscape” im Premiumslot direkt nach der Begrüßung im Hauptsaal der rootconf einen großen Teil dazu bei.

Am 13. Mai, Samstag dem Tag nach der rootconf, war es nun an der Zeit für das zusammen mit HasGeek veranstaltete Icinga Camp in der Thought Factory der Axis Bank. Obowohl (oder vielleicht auch “weil”) der Samstag in Indien eigentlich ein Arbeitstag ist, hatten es viele Interessierte auf das Camp geschafft. Nach Begrüßung und einer kurzen Einführung in den aktuellen Entwicklungsstand von Icinga durch Bernd übernahm Aditya Raj von Snapdeal, einem sehr großen Onlineshopbetreiber in Indien, und gab einen Einblick wie der Einsatz von Icinga 2 dort mittels SaltStack automatisiert wurde.

Nach einer kurzen Kaffepause verdeutlichte Hariram Hari von Fortidm Technologies die Erwartungshaltung aus Großunternehmenssicht an eine Monitoringlösung wie Icinga, bevor dann Toshaan Bharvani von VanTosh detailliert drauf einging wie Icinga 2 mit Ansible provisioniert werden kann. Es folgte zur Stärkung die Mittagspause und dann war auch meine Vortragspremiere gekommen. Mit vielen Slides zeigte ich die vielen Integrations- bzw. Erweiterungsmöglichkeiten von Icinga 2 mit anderen Tools auf.

Roy Peter von Bluejeans Network referierte über die Einsatzmöglichkeiten der Icinga 2 API und zeigte hier insbesondere die automatische Aufnahme neuer AWS Nodes in das Monitoringsystem. Im anschließenden Vortrag ging Bernd noch genauer auf den Director ein, bevor das Camp durch eine offene Runde mit sehr viel Beteiligung einen würdigen Abschluss fand.

Insgesamt bestätigte das Icinga Camp und v.a. die vielen Wortmeldungen nach den Vorträgen (mal wieder) die Verbreitung und das Potenzial von Icinga auch außerhalb der sonst gewohnten Kundschaft von NETWAYS.

Für mich war Bangalore als sog. “Silicon Valley” von Indien eine Chance die ich gerne wahr genommen habe und persönliches Highlight, an das ich mich sicher lange erinnern werde.

PS: Natürlich sind in gewohnter Manier auch wieder Slides und Bilder des Icinga Camps online verfügbar.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Platz da LConf, der Director kommt!

Lange Zeit war das von NETWAYS entwickelte Tool LConf das Mittel der Wahl wenn ein grafisches Konfigurationsfrontend für Icinga gesucht wurde. Mit Icinga 2 und dem damit einhergehenden geänderten Konfigurationsformat litt jedoch die Kompatibilität, außerdem ist das ursprüngliche Konzept von LConf mit der Zuweisung von Services über Vererbungen eines OpenLDAP-Baumes spätestens mit den vielen Möglichkeiten der Apply Rules von Icinga 2 überholt.

Als eigenes Modul in Icinga Web 2 integriert, ist der Director das einzige Konfigurationstool das eine vollständige Unterstützung für Icinga 2 bietet. Die Kommunikation erfolgt dabei direkt mit der API des Icinga 2 Cores (seit Icinga 2.4). Daher stellt sich also die Frage: Wie lässt sich die Icinga Konfiguration von LConf am Besten auf den Director, respektive von Icinga 1.x auf Icinga 2.x migrieren?

Icinga Web 2 bietet bereits nativ eine Unterstützung für LDAP, diese steht auch den Modulen zur Verfügung. Um LConf nun als Import Source im Director zu verwenden, muss dafür in Web 2 noch eine entsprechende Resource eingerichtet werden.

Host in LConf

Bei der Import Source reicht es dann i.d.R. aus die Objektklasse auf lconfHost einzuschränken, denn mehr als nur Hosts zu importieren, macht in den wenigsten Fällen sind. Services sollten aufgrund von CheckCommands aus der Icinga Template Library (= ITL) sowieso neu gemacht und in dem Zuge auch gleich überdacht werden. Durch die Apply Rules liegt der Fokus auf Host Eigenschaften anhand deren später Services zugewiesen werden können. Neben Standardattributen stehen hier auch sog. Custom Attribute oder Custom Variablen (CustomVars) zur Verfügung, mit denen weitere individuelle Informationen wie beispielsweise Betriebssystem, Rolle oder Standort hinterlegt werden können.

Normalerweise ist es bei Hosts ausreichend cn, lconfAddress, lconfAlias und lconfHostCustomvar zu importieren. Da CustomVars in LConf mit Unterstrich vorm Bezeichner und einem Leerzeichen vor dem eigentlichen Wert angegeben werden müssen, sieht das in der Vorschau der Import Source beispielhaft so aus:

[

“_operatingsystem Linux”,

“_role Webserver”,

“_rack Rack01”

]

Diese Syntax kann vom Director nur schwer weiter verarbeitet werden, daher gibt es dort seit kurzem den Modifier “Transform LConf CustomVars to Hash“, mit dem das Ganze wie folgt transformiert wird:

{

operatingsystem: “Linux”,

rack: “Rack01”,

role: “Webserver”

}

Host im Director

Bei der darauf aufbauenden Sync Rule können dann alle CustomVars mit “All custom variables (vars)” automatisch umgesetzt werden, dabei spielt es keine Rolle ob die Hosts eine, keine oder mehrere Custom Attribute definiert haben.

Damit ist es sehr einfach die Hosts aus dem bestehenden LConf-Baum bereits im Produktivbetrieb schon auf die künftige Verwendung mit Icinga 2 vorzubereiten und sie dann mit dem Director einmalig oder regelmäßig zu importieren, sodass zumindest ein paar Andenken an den “geliebten” LConf bleiben…

Wer hier oder auch bei anderen Aufgaben mit Icinga und dem Director noch Unterstützung benötigt, kann aber natürlich auch gerne auf uns zukommen.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Autoprovisionierung mit Foreman

Da kommende Woche die Open Source Monitoring Conference, kurz OSMC, hier in Nürnberg ansteht, laufen die Vorbereitungen dafür natürlich bei uns auf Hochtouren. Für die Workshops, die seit einigen Jahren traditionell vor der eigentlichen Konferenz allerdings zeitgleich stattfinden, reichen unsere eigenen Notebookbestände der Trainings nicht ganz aus. Deswegen greifen wir hier auf Anbieter für Leihnotebooks zurück um unsere Bestände entsprechend aufzustocken.

Es sollte kein Geheimnis sein das wir die von uns angebotenen Softwarelösungen auch intern einsetzen, daher verwenden wir – wie soll’s auch anders sein – Foreman in Kombination mit Puppet zur Provisionierung der Notebooks. Speziell das Discovery Plugin, über das Dirk schon ein einem früheren Blogpost (siehe Metal as a Service mit Foreman) berichtet hatte, leistet hier seinen Beitrag.

Ist das Plugin installiert wird das PXE-Bootmenü auf den zu provisionierenden Clients um einen Eintrag zum Discovery erweitert. Wählt man diesen aus, stellen die zu provisionierenden Systeme automatisch eine Verbindung zum Foreman-Server her. Bei Erfolg sind sie dort dann unter “Discovered hosts” zu finden und können so mit entsprechenden Informationen versehen (z.B. Hostname, Host Group, usw.) werden. Anschließend startet dann die Installation.

bildschirmfoto-2016-11-25-um-08-45-05

Mit den Discovery Rules bietet das Discovery Plugin noch eine Möglichkeit den Vorgang etwas zu Vereinfachen bzw. zu Automatisieren. Anhand von bestimmten Kritierien, wie z.B. in unserem Fall das Modell des Notebooks, werden Regeln für die Provisionierung definiert. Wenn sich das Notebook dann via PXE-Boot am Foreman meldet, greifen diese Rules und der Installationsvorgang beginnt ohne weiteres Zutun. U.a. lässt sich in den Discovery Regeln ein Muster für den Hostname anhand von Puppet Facts (beispielsweise eine individuelle ID) sowie die Hostgruppe mit den Informationen für die Installation festgelegen. Außerdem kann man die maximale Anzahl der Hosts für und bei Bedarf eine entsprechende Priorisierung der Regeln einstellen.

Somit bleibt mir eigentlich nur noch den Teilnehmern der diesjährigen OSMC eine erfolgreiche Konferenz zu wünschen! Selbstverständlich bin auch ich wieder vertreten und freue mich über interessante Gespräche – auch zum Thema Foreman.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Vorträge der OSBConf 2016

Nachdem Daniela vor Kurzem ja schon was zu den vorgelagerten Workshops und zum Rahmenprogramm der diesjährigen Open Source Backup Conference in Köln geschrieben hat (siehe: Rauchende Köpfe, knurrende Mägen…), möchte ich noch etwas über die Vorträge dort berichten.

img_0802Nach einer kurzen Begrüßung durch Maik Außendorf von der dass IT ging’s los mit Julius Faubel von der Tandberg Data GmbH. Er referierte über Backup to Tape und stellte anschließend die Produkte der NEOxl, NEOs und der NEOe-Series vor. Gregor Wolf von Red Hat sprach anschließend über die Herausforderungen der Datenexplosion und wie man diese in den Griff bekommen kann.

Die Neuerungen von Bareos 16.2 und deren Roadmap für nächstes Jahr wurde uns von Philipp Storz und Maik Außendorf präsentiert. Neben anderen neuen Features wurde besonders anschaulich auf “Always Incremental” eingegangen, welches besonders bei großen Datenmengen Zeit- und Netzwerkkapazität reduziert.

Vor der ersten Kaffeepause zeigte Erol Ülükmen noch welche besonderen Ansprüche das Clientmanagement mit sich bringt und wie sich das Open Source Clientmanagementsystem Opsi (Open PC Server Integration) mit Bareos integrieren läßt.

Gratien d’haese, der am Tag zuvor auch schon den Workshop zu REAR (Relax-and-Recover) gehalten hatte, erklärte was bei einem Business Continuity Plan zu beachten ist und wie man das darin enthaltene Disaster Recovery mit Bareos und REAR abbilden kann. Einen praktischen und interessanten Einblick wie das Backup bei der Friedrich-Schiller-Universität in Jena mit Bareos durchgeführt wird, gab’s vor der Mittagspause noch von Thomas Otto.

img_0805Gut gestärkt hörte man Jörg Brühe zu, der über Datenbank Backup referierte. Dabei wies er v.a. auf Dringlichkeit und Testmöglichkeiten von Restores hin.

Später stellte Christian Reiß von Symgenius ZFS vor und zeigte wie es mit Bareos zusammenspielt. Das Deployment dafür wurde mit Puppet gelöst, weshalb er auch auf das von ihm geschriebene Bareos-Puppet Modul näher einging.

Tobias Groß präsentierte nach der Kaffeepause am Nachmittag wie sinnvoll ein skalierendes Backup anhand von Bareos Active Clients und Puppet ist, allerdings wurde das dafür benutzte Puppetmodul globalways-bareos leider aktuell noch nicht publiziert. Eine belebte Diskussionsrunde über diverse Themen bildete dann den gelungenen Abschluss der Konferenz, bevor alle Teilnehmer mit einem Lunchpaket im Gepäck den Nachhauseweg antraten.

Die Open Source Backup Conference findet im nächsten Jahr vom 25. bis zum 26. September mit hoffentlich ebenso interessanten Vorträgen sowie einem breiten Publikum wieder in Köln statt, also bis dann!

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.