Trick 42 mit dem Director – Jobs in Reihenfolge

Nachdem wir unseren Trick 17 mit dem Director veröffentlichten, schiebe ich Trick 42 direkt hinterher. Wie im Blogpost von Markus beschrieben, sind Schnittmengen aus mehreren Importquellen eine geniale Lösung um beispielsweise Hosts aus mehreren Quellen mit Informationen anzureichern. Konfiguriert man nun eine Vielzahl solcher Importquellen die für die Schnittmenge dienen sollen, bekommt man evtl. im Ablauf gewisse Probleme mit der Reihenfolge.
Zur genauen Erklärung unser Ausgangsszenario:

  • CMDB 1: Quelle für die Basisdaten des Hosts (Name, IP, FQDN, …)
  • CMDB 2: Quelle für den OS-Type (CentOS, OpenSuSE, Debian, …)
  • CMDB 3: Quelle für den Ansprechpartner (Hr. Müller, Hr. Maier, …)

Damit die Hosts aus CMDB 1 angereichert erstellt (Import + Sync) werden können müssen zuerst CMDB 2 und CMDB 3 abgearbeitet werden. Logisch – wenn der OS-Type und der Ansprechpartner des Hosts dem Director nicht bekannt sind wird es mit Hilfe von Trick 17 auch nicht möglich sein den Host aus CMDB 1 mit Daten anzureichern.
Hauptsächlich fällt dieses Problem beim initialen Import + Sync der Daten auf. Je nachdem wie oft sich eure Importquellen ändern kann dies “gar nicht schlimm” (Hr. Müller ist für den Server 3 Jahre zuständig) oder auch “sehr unglücklich” (Ihr importiert die Kontaktdaten einer ständig wechselnden Rufbereitschaft) sein.
Für den Fall das die Reihenfolge der Importquellen wichtig ist gibt es eine denkbar simple Lösung.
Ihr legt für jeden Import und Sync einen Job im Director an…

 

…und notiert euch jeweils die ID des Director Jobs (die Zahl an der letzten Stelle der URL).

Mit Hilfe dieser ID könnt ihr nun die im Director konfigurierten Jobs von der Kommandozeile aus ausführen. Der Job mit der ID 1 (Import Job für CMDB1) kann mit dem Kommando “icingacli director jobs run 1” gestartet werden.
Am Ende bauen wir uns dazu noch ein kleines Skript:

#!/bin/bash
# set paths and vars
ICINGA_CLI=`which icingacli`
JOB_CMD=${ICINGA_CLI}" director jobs run"
# execute jobs
echo "import and sync..."
echo -e "\tcmdb1"
${JOB_CMD} 1
${JOB_CMD} 2
echo -e "\tcmdb2";
${JOB_CMD} 3
${JOB_CMD} 4
echo -e "\tcmdb3";
${JOB_CMD} 5
${JOB_CMD} 6

Und voilà – wir haben die Imports und Syncs in einer Reihenfolge 🙂

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

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
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin 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. Wenn er nicht gerade die Welt bereist, 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
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin 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. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Automate Icinga 2 Agent Configuration for Installer

bild02Icinga 2 wird inzwischen oft mit dem Icinga 2 Web Module Director verwaltet. Verbreitet sind die Möglichkeit aus anderen Datenbanken wie cmdb, Configuration Management Database, Informationen über installierte Hosts automatisch in den Director zu importieren. Bei diesen Importjobs können Filter die Quelldaten automatisch anpassen oder durch DNS-Abfragen ergänzen. Icinga 2 wird dann aus dem Director mit Informationen über Hosts und Checks und deren Anwendung beliefert um Verfügbarkeiten von Datenbanken, Webservern und vielen anderen Diensten regelmäßig zu prüfen. Die Ergebnisse werden dann protokolliert und natürlich bei Ausfall von Diensten sofort alarmiert.
Zum Ausführen dieser Prüfungen werden oft verschiedene Commandbridges wie beispielsweise NRPE oder SSH verwendet. Bei Icinga 2 gibt es heute die Möglichkeit anstatt dieser “Brücken”, “richtige” Agenten einzusetzen die den Vorteil bieten, über aktuelle Protokolle zu arbeiten. Die Kommunikation zwischen Icinga 2 und solchen Icinga-Agenten oder Satelliten erfolgt mit SSL, Secure Socket Layer, verschlüsselt inklusive sicherer Authentisierung. Wichtige Funktion ist hier die gegenseitige Authentisierung aller Kommunikationspartner mit x509 Zertifikaten. Für diese Agenten ist ein dediziertes Setup zur Konfiguration und Erstellen der Zertifikate und Authorisationstickets erforderlich. Das stellt sicher das nur vom Administrator definierten Agenten die Kommunikation gestattet wird und alle anderen Kommunikationsversuche zuverlässig ausgesperrt bleiben.
Icinga führt Checks durch aufrufen der Kommandos in unterschiedlicher Weise aus.
1. Icinga direkt und der check kommuniziert mit dem Ziel
2. Remote via “Brücken” wie NRPE und am Zielsystem wird der Check ausgeführt
3. Verteilt auf Satelliten und Agenten die hier die Checks ausführen
Satelliten und Agenten erfordern eine Konfiguration der Kommunikation und Verteilung von Checks. Zur Konfiguration der Kommunikation ist für alle Kommunikationsendpunkte ein PKI, Public Key Infrastructure, Setup erforderlich. Und zum Management werden Zonen definiert die ein Who is Who im Icingasystem ermöglichen. Darauf bauen dann Einstellungen auf die festlegen wer was prüfen soll. Hier erleichtert der Director diese Verwaltung durch strukturierte Konfiguration von Hosts, Checks und “apply”, Anwendungsregeln in einem modernen GUI, Garphical User Interface. Beliebte Funktionalität ist die intelligente Aufteilung der Konfiguration in sogenannte Templates und Hostdefinitionen. Mit solchen Templates wird von vielen Hosts verwendete Information nur einmal definiert und dann in den Host-Definitionen darauf verwiesen. Und so bietet sich für Agenten ein Template an das die Agenteneinstellung beschreibt. Sind diese Agenten definiert steht die Installation der Agentensoftware und deren Konfiguration an.
Für jeden definierten Agenten kann im Director ein Skriptvorschlag abgerufen werden. Viele Anwender betreiben heute automatisierte Software Verteiler und deren Installer. Solche Installer führen auch Konfigurationskripte aus. Die benötigte Information zur Konfiguration der Agenten ist im Director vorhanden  und PKI Setups als auch Authtentisierungsstickets werden benötigt. Und so bietet sich eine Realisierung als Skript an.
Ein solches Skript sollte
1. Die Hosts mit Agent aus der Directordatenbank auslesen
2. Die Konfigurationsdateien für den Installer erzeugen
Eine solche Skriptingmöglichkeit habe ich in zwei Teilen erstellt.
Im ersten Teil stelle ich ein Skript zum erzeugen dieser Konfigurationsdateien vor. Dieses Skript benötigt vorbereitete Teilskripte für die jeweiligen Betriebssysteme wie zum Beispiel Windows oder Linux und eine Liste die den Hostnamen und die Betriebssystemvariante enthält. Ich stelle hier ein Konfigurationsskript für Linux vor.
Im zweiten Teil beschreibe ich ein Skript zum Auslesen von Hosts mit Agent aus dem Director.
Erstes Skript
Dieses Skript kann auf zwei Arten angewendet werden. Im ersten Fall werden eine oder mehrere Konfigurationsdateien eingelesen und oder direkt aus stdin im zweiten Fall. Das Skript fügt die Hostinformation mit den vorbereiteten Teilskripten zu vollständigen Installerskripten je Host mit Agent zusammen und legt diese in einem Unterverzeichnis ab, bereit für einen Installer.
Ein Beispiel einer Host-liste

# Kommentar
host1.firma.de windows
host2.firma.fr ubuntulinux
# host3.firma.de suselinux

Das Skript gen_agent_scripts

mkdir: created directory ‘gen_agent_scripts.out’
gen_agent_scripts: write file test14.out/Icinga2Agent-host1.firma.de.psm1
gen_agent_scripts: write file test14.out/Icinga2Agent-host2.firma.fr.sh
gen_agent_scripts: 2 config scripts written to gen_agent_scripts.out
execute a script on an agent
‘/etc/icinga2/zones.conf’ -> ‘/etc/icinga2/zones.conf.20161107_040216.bak’
information/base: Writing private key to '/etc/icinga2/pki/host2.fr.key'.
information/base: Writing X509 certificate to '/etc/icinga2/pki/host2.fr.crt'.
information/pki: Writing certificate to file '/etc/icinga2/pki/trusted-master.crt'.
information/cli: Writing signed certificate to file '/etc/icinga2/pki/host2.fr.crt'.
information/cli: Writing CA certificate to file '/etc/icinga2/pki/ca.crt'.

Dieses Skript liest Host-listen ein und erzeugt damit je Agent eine spezifisches Konfigurationsskript, bereit zur automatischen Konfiguration dieser Agenten. Die Optionen des Skripts sind ein oder mehrmals -l und eine oder mehrere Listendateien.
icinga-agent-linux.name.sh
Diese komplettierte Agentskript erzeugt eine Zonenkonfiguration, erweitert die Einstellungen in api.conf und erledigt die PKI Konfiguration.
Die Skripte stehen auf github zum download bereit und viele weitere information zu Icinga 2 hier.