Icinga 2, Director und Windows
Diesen Beitrag schrieb ich 6 Jahre und 4 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Nicht erst seit WannaCry ist es von Interesse, den Patch-Stand diverser Windosen im Auge zu behalten… und Ehrensache, hier kommt bei mir Icinga 2 ins Spiel. Von der Installation bis hin zur Integration über den Director – kommt mal mit, so schwierig ist das gar nicht.
Installation unter Windows
Im ersten Schritt, ganz klar, muss Icinga 2 auf dem Host installiert werden; ich habe mich für den aktuellsten 64bit-Installer auf http://packages.icinga.com/windows/ entschieden. Die Installation ist… naja, eine Installation halt ;) Ich musste zuvor packages.icinga.org in Systemsteuerung → Internetoptionen → Vertrauenswürdige Sites freigeben – vielleicht ist da auf euren Systemen auch etwas Zauber nötig, das wisst ihr sicher besser als ich.
Run Icinga 2 Setup Wizard hake ich im letzten Schritt nicht an, stattdessen führe ich das PowerShell-Script aus, das der Director mir bereitstellt – nachdem ich den Host im Director eingerichtet habe, deshalb ist das der nächste Schritt. Wie das geht, wisst ihr sicher alle? Im Reiter „Agent“ findet ihr dann das Windows Kickstart Script, was nichts anderes als ein PowerShell-Script ist. Und ja, als völliger Microsoft-N00b musste ich hier bös googlen, bis ich die Zusammenhänge kapierte. Wie auch immer: dieses Script muss kopiert und auf den Windows-Host transportiert werden. Ich habe hierzu eine Textdatei icinga.txt auf dem Desktop erstellt und den Inhalt hineinkopiert. Im Anschluss daran starte ich die PowerShell (als Administrator!), marschiere in das korrekte Verzeichnis und benenne die Datei von icinga.txt nach icinga.ps1 um. Ausführen kann ich sie jedoch nicht – die auf dem Host gesetzte Richtlinie verhindert das. Abhilfe schaffte für mich, diese Richtlinie kurzfristig per Set-ExecutionPolicy Unrestricted außer Kraft zu setzen, mein Script .\icinga.ps1 auszuführen und die Änderung an der Richtlinie hernach per Set-ExecutionPolicy AllSigned wieder rückgängig zu machen. Unter „Dienste“ setzte ich dann noch Anmelden als auf Lokales Systemkonto, damit die Checks später nicht an irgendwelche Permission-Wände laufen.
Vorbereitung des Masters
Damit der Master die Commands auch kennt, muss die Konfiguration (sofern das nicht schon passiert ist) eingebunden werden; ich habe hierzu die /etc/icinga2/icinga2.conf erweitert und anschließend per service icinga2 restart durchgestartet. Mehr ist auf dem Master auch gar nicht zu tun – der nächste Schritt besteht dann schon darin, die Checks zu konfigurieren.
## file: "/etc/icinga2/icinga2.conf"
...
include
...
Services im Director
Kickstart run
Nun ist es ja so: wenn ihr die Windows-Plugins gerade erst in die Konfiguration aufgenommen, den Director aber schon länger am Start habt – dann kennt er diese neuen Commands nicht. Was benötigt wird: ein erneuter Lauf des Kickstarts, wie er auch bei der ersten Inbetriebnahme des Director ausgeführt wird. Damit der funktioniert, muss zuerst eine entsprechend angepasste Konfigurationsdatei angelegt werden.
## file: "/etc/icingaweb2/modules/director/kickstart.ini"
[config]
endpoint =
; host = 127.0.0.1
; port = 5665
username =
password =
Hernach kann der Kickstart initiiert werden. Läuft alles fehlerfrei, erscheinen im Director anschließend ziemlich viele Pending changes – eben alles, was nun neu importiert wurde. Nach dem Deploy stehen diese neuen Commands dann zur Verfügung und können über den Director genutzt werden.
$ icingacli director kickstart run
Windows Services
Die Services, zum Teil auch mit Datenfeldern, in den Director einzutickern, ist in erster Linie eines: ziemlich öde ;) Also schnappt euch einen frischen Kaffee und etwas gute Musik und legt los. Wichtig ist natürlich, dass die Checks auf dem Endpoint ausgeführt werden, ihr also Run on agent auf yes setzt. Ein Preview meines update-windows liest sich folgendermaßen:
template Service "update-windows" {
check_command = "update-windows"
max_check_attempts = "5"
check_period = "workhours"
check_interval = 1h
retry_interval = 1m
enable_notifications = true
enable_active_checks = true
enable_passive_checks = true
enable_event_handler = true
enable_perfdata = true
volatile = false
zone = "zonename"
command_endpoint = host_name
vars.update_win_crit = "yes"
}
Zuordnung zu Hosts
Der Einfachheit halber habe ich meinem Host-Template Windows Agent via Icinga 2 Core diese Services zugeordnet; auf jedem Host, der dieses Template einbindet, werden automatisch diese Checks ausgeführt. Navigiert hierzu im Director über Hosts ? Templates ? Template auswählen ? Reiter Services und fügt hinzu, was ihr an dieser Stelle sehen möchtet. Klar, es ist eingeschränkter gewohnt, aber es ist okay. Und liefert Information, die man eigentlich unbedingt haben will – wenn ich schon Windosen im Netz ertragen muss, dann will ich wenigstens wissen, was da so drauf abgeht. Eine Einschränkung stellt derzeit Windows 2008 dar, hierzu hab ich mal einen Bug Report aufgemacht.
Berichtet doch mal, wie es geklappt hat!
