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.