Automatische Agenten-Updates

Checkmk Manual
Letzte Aktualisierung: 15. Februar 2019

Suche im Handbuch

Checkmk kann seine Agenten auf Linux, Windows und Solaris automatisch aktualisieren. Damit können Sie nicht nur im Falle von neuen Checkmk-Versionen die Agenten leicht aktualisieren, auch eine geänderte Konfiguration der Agenten kann so ausgebracht werden. Dabei können Sie den Vorteil der Agentenbäckerei nutzen, dass Hosts individuelle Konfigurationen bekommen können.

1. Automatische Updates einrichten

Gehen Sie zum Einrichten der Updates nach folgenden Schritten vor: Wählen Sie zunächst das WATO-Modul Monitoring Agents und klicken Sie dort auf den Knopf Automatic Update.

Unter Prerequisites sehen Sie eine Liste von Voraussetzungen, die erfüllt sein müssen, damit die automatischen Updates funktionieren. Diese können Sie einfach der Reihe nach abhaken. Bitte vergessen Sie nicht, dass es für alle Seiten auch eine Onlinehilfe gibt, die alle Punkte genauer erklärt. Ein Klick auf bringt Sie direkt zu der Stelle in WATO, wo die entsprechende Konfiguration vorgenommen werden muss. Im Einzelnen müssen folgende Aspekte konfiguriert werden:

1.1. Signaturschlüssel erstellen

Das System ist so aufgebaut, dass die Agenten per HTTP oder HTTPS von ihrem zentralen Monitoringserver Updates herunterladen. Da Agenten ausführbaren Code enthalten, ist es besonders wichtig, dass Sie sicherstellen, dass die Agenten nicht von einem Angreifer verfälscht werden können. Zu diesem Zweck werden Signaturschlüssel verwendet. Diese bestehen aus einem Paar von öffentlichem und privatem Schlüssel (Public-Key-Verfahren).

Sie können beliebig viele Signaturschlüssel anlegen. Diese werden jeweils mit einer Passphrase geschützt, welche Sie später bei jedem Signieren eingeben müssen. Damit wird verhindert, dass z. B. ein Angreifer, der Zugriff auf eine Datensicherung des Monitoringservers erlangt, Agenten signieren könnte.

Erzeugen Sie hier einen Signaturschlüssel und merken Sie sich die Passphrase. Diese kann später weder geändert noch wiederhergestellt werden. Geht der Schlüssel verloren, so kann dies bedeuten, dass alle Agenten einmal manuell aktualisiert werden müssen!

1.2. Konfiguration des Update-Plugins

Das eigentliche Update wird durch ein Agenten-Plugin mit dem Namen cmk-update-agent ausgeführt. Dieses wird vom Agenten in einem einstellbaren Zyklus aufgerufen (z. B. ein mal pro Stunde). Es fragt dann den Deployment-Server (Ihr zentrales Monitoringsystem) jeweils an, ob ein neues Paket für diesen Host vorliegt und führt dann das Update durch.

Das Plugin muss natürlich im Agenten vorhanden und korrekt konfiguriert sein. Dazu erweitern Sie die Agenten über den Regelsatz Install agent updater (Linux, Windows) um dieses Plugin. Bitte beachten Sie, dass der Regelsatz hier das Prinzip "Erste Regel pro Parameter gewinnt" verwendet. Sie haben dadurch die Möglichkeit grundlegende Einstellungen allgemein zu definieren, so dass diese nicht in den spezielleren Regeln immer wieder neu gesetzt werden müssen. Zusätzlich bietet natürlich auch hier die Onlinehilfe weitere Informationen zu jedem einzelnen Punkt, sobald Sie diesen aktivieren.

Nachfolgend noch ein paar Erläuterungen zu den einzelnen Punkten:

Activation

Diese Einstellung muss aktiviert werden ("Deploy plugin..."), damit das Plugin zum Agenten hinzugefügt wird. Hier kann z. B. die Regelvererbung genutzt werden, um auf oberer WATO-Ordnerebene eine Grundeinstellung zu setzen und diese für einzelne Hosts/Ordner zu überschreiben.

Interval for update check

Hier legen Sie das Intervall fest, in dem der Agent-Updater den konfigurierten Monitoring-Server nach einem Update anfragt. Solange das gesetzte Intervall nicht abelaufen ist, wird ein zwischengespeicherter Aufruf zurückgegeben, um die Netzwerklast so wenig wie möglich zu belasten. Normalerweise ist es sinnvoll ein Intervall zu nutzen, welches nicht niedriger als 10 Minuten beträgt, da die Gefahr sehr groß ist, dass Ihr Netzwerk sonst sehr stark belastet wird.

DNS name or IP address of update server

Hier geben Sie den DNS-Namen an, unter dem Checkmk-Server erreichbar ist. Wichtig ist hier, dass der zu überwachende Host diesen Namen auflösen kann und er im Checkmk als Host konfiguriert ist. Achten Sie bei dem Einsatz von HTTPS darauf, dass der Name des Zertifikats mit dem des Namen des Checkmk-Servers übereinstimmt, wie der dem Host bekannt ist

Wichtig: Wenn Sie ein verteiltes WATO einsetzen, geben Sie hier den Server an, auf dem die Master-Instanz von Checkmk zu erreichen ist. Siehe auch der Abschnitt zum Deployment in einem verteiltem WATO.

Name of Checkmk site of update server

Hier tragen Sie – bis auf wenige Ausnahmen – den Namen der Instanz ein, auf der Sie gerade diese Regel konfigurieren. Eine Ausnahme von diesem Vorgehen wäre es, wenn die betroffenen Hosts zu einer anderen Checkmk Instanz "umziehen" sollen. In diesem Fall tragen sie hier einmalig eine andere Site ein. Siehe hier auch weiter unten unter Einsatzszenarien.

Protokoll to use for fetching updates

Wenn Sie – wie von uns empfohlen – HTTPS verwenden, müssen Sie gleichzeitig auch ein Root-Zertifikat angeben. Mit diesem kann der Agent-Updater die Zertifikatskette des Checkmk Servers verifizieren, da er auf lokal installierte Root-Zertifikate nicht zugreifen kann.

Wichtig: Je nach Konfiguration des Servers kann es sein, dass HTTPS (inklusive Weiterleitung von HTTP auf HTTPS) erzwungen wird. Wenn in einem solchen Fall trotzdem HTTP konfiguriert ist, versucht der Agent Updater auch tatsächlich eine unverifizierte Verbindung aufzubauen und wird eine Verbindung über HTTPS nicht annehmen. Siehe auch hier weiter unten unter Die Verbindung über SSL/TLS funktioniert nicht.

Proxy-Settings

Diese Regeleinstellung ist optional. Der Agent Updater geht zunächst davon aus, dass auch bei konfigurierten Proxy-Einstellungen auf dem Zielhost eine direkte Verbindung zum Checkmk Server vorliegt und ignoriert alle lokalen Proxy-Einstellungen. Wenn dies das gewünschte Verhalten ist, kann diese Regeleinstellung also weggelassen werden. Andernfalls geben Sie die Proxy-Einstellungen entweder manuell an, oder nutzen die existierenden Environment-Variablen des Hosts.

Executable Format (Linux)

Seit der Version 1.5.0 können Sie optional bestimmen, in welcher Form das Plugin dem Installationspaket für den Agenten hinzugefügt wird. Wie sich die Regel verhält, hängt standardmäßig von dem Zielsystem ab:

  • Linux (deb, rpm, tgz): Für diese Systeme müssen Sie nichts manuell anpassen; der Agent-Updater wird als 64bit-Binary übergeben. Optional können Sie auch ein 32bit-Binary für ältere Systeme oder das alte Python-Skript auswählen. Wichtig: Für das Binary benötigen Sie das Paket glibc mindestens in der Version 2.5. Linux-Distributionen erfüllen diese Anforderungen in der Regel seit 2006.
  • Windows: Auch ist das 64bit-Binary der Standard. Sie können das 32bit-Binary im Bedarfsfall auswählen. Das Skript steht hier nicht zur Verfügung und wird entsprechend ignoriert.
  • Solaris: Hier müssen sie ebenfalls nichts anpassen. Checkmk wird hier das Python-Skript verwenden, auch wenn Sie den Standardwert auf dem 64bit-Binary lassen.
  • Andere Architekturen: Wenn Sie Pakete für anderen Architekturen, wie z. B. arm oder ppc setzen Sie diese Option manuell auf das Python-Skript, da das von Checkmk nicht automatisch abgefangen wird und keine Binaries für diese Plattformen angeboten werden.

Falls Sie dennoch auf das alte Python-Skript zurückgreifen müssen, gelten die folgenden Voraussetzungen für das System:

  • Python2 in der Version 2.7.13 oder neuer
  • Die Python-Module requests, requests[socks] und pyOpenSSL

Signature keys the agent will accept

Wählen Sie hier mindestens einen Signaturschlüssel aus, dessen Signatur vom Agenten-Updater akzeptiert werden soll. Optional können Sie auch mehrere Schlüssel angeben. Das kann z. B. der Fall sein, wenn Sie einen alten Schlüssel deaktivieren wollen. Für dieses Vorhaben muss der Agent-Updater eines Hosts zwischenzeitlich beide Schlüssel akzeptieren.

1.3. Agenten backen

Wenn Sie die Regeln für die Paketierung in der Agent-Bakery angepasst haben, werden Sie bemerken, dass der Button Bake agents orange hervorgehoben wird. Die erstellten und angepassten Regeln finden sich nämlich erst dann in den Installationspaketen wieder, wenn Sie diese neu erstellen/backen. Wenn dieser Prozess abgeschlossen ist, werden Sie darüber informiert:

1.4. Agenten signieren

Als nächstes signieren Sie die Agenten mit dem in Schritt 1 erstellten Schlüssel. Dazu benötigen Sie jetzt zum ersten Mal Ihre Passphrase. Nachdem Sie diese erfolgreich eingegeben haben, werden die signierten Agenten mit einem -Symbol gekennzeichnet. Wenn Sie mehrere Schlüssel angelegt haben, geschieht die Signatur mit jedem Schlüssel separat. Wichtig: Einem Agent-Updater auf dem zu überwachenden Hosts genügt es, wenn das neue Paket mit einem der ihm bekannten Schlüssel signiert ist.

Jedes mal, wenn Sie später die Agentenpakete aktualisieren und neu backen, wird die Signierung entfernt und muss neu angelegt werden.

1.5. Agenten registrieren

Registrieren Sie nun im nächsten Schritt die zu überwachenden Hosts am Checkmk-Server. Da ein neuer Host dem Checkmk-Server bisher noch nicht vertraut und dieser auch noch nicht weiß, dass der Host automatisch aktualisiert werden soll, muss der Agent auf dem Host einmalig von Hand installiert werden. Laden Sie dafür im WATO unter Monitoring Agents das für den Host passende Paket herunter. Achten Sie darauf, dass das Paket auch das Agent-Updater-Plugin enthält.

Kopieren Sie nun das Paket auf den Host und installieren Sie es wie gewohnt mit rpm, deb oder msiexec (bzw. per Doppelklick). Das Agent-Updater-Plugin finden Sie nun im Pluyginsverzeichnis des Hosts:

  • Unter unixoiden Systemen im Pfad /var/lib/check_mk_agent/plugins/[konfigiertes Intervall]/
  • Unter Windows unterhalb des Installationspfads des Agenten. Normalerweise unter C:\Program Files (x86)\check_mk\plugins\

Rufen Sie nun den Agent-Updater mit dem Arugment register auf. Unter Windows muss dies in einem Prompt mit Administratorrechten geschehen. Geben Sie dann der Reihe nach die erforderlichen Angaben ein (wenn Sie einen gebackenen Agenten installiert haben, sind nicht alle Einstellungen nötig):

root@linux# cmk-update-agent register -v
+-------------------------------------------------------------------+
|                                                                   |
|  Check_MK Agent Updater v1.5.0p7 - Registration                   |
|                                                                   |
|  Activation of automatic agent updates. Your first step is to     |
|  register this host at your deployment server for agent updates.  |
|  For this step you need an administration account on WATO for     |
|  that server.                                                     |
|                                                                   |
+-------------------------------------------------------------------+
Deployment server to connect to:
mymonitoring.example.intern

Protocol to use for connection [http/https]:
https

(CMK) site on deployment server:
mysite

Our host name in the monitoring:
myhost

WATO user with admin permissions:
cmkadmin

Password:


Going to register agent at deployment server
Successfully registered agent for deployment.
You can now update your agent by running 'cmk-update-agent -v'
Saved your registration settings to /etc/cmk-update-agent.state.

Hint: you can do this in scripts with the command:

./cmk-update-agent register -s moni01.servers.intern -i mysite -H myhost -p http -U cmkadmin -P '***' -v

Alternativ können Sie die Registrierung auch im nicht-interaktiven Modus durchführen, indem die benötigen Daten per Kommandozeilenoption übergeben werden. Ein Aufruf von cmk-update-agent register --help zeigt hier die setzbaren Optionen an. Erwähnenswert hierbei ist, dass die einmalige Registrierung auch über einen Automation-User erfolgen kann. Dafür wird der User wie gewohnt per --user/-U und das Automation-Secret per --secret/-S übergeben.

Einige Hinweise zur Registrierung:

  • Bei der Registrierung benötigt das Plugin auch den Namen des Hosts, wie er im Monitoring bekannt ist. Dieser ist ja nicht unbedingt mit dem Hostnamen des Rechners identisch. Der Hostname wird dann zusammen mit dem Schlüssel lokal gespeichert.
  • Um HTTPS zu verwenden, muss auf Ihrem Monitoringserver HTTPS eingerichtet sein. HTTP ist hier deutlich einfacher, bietet aber keine Verschlüsselung der Übertragung. Da der Agent theoretisch Passwörter enthalten kann, ist HTTPS der empfohlene Weg. Die Authentizität des Agenten wird aber durch die Signatur unabhängig davon sichergestellt.
  • Der Login als WATO-User ist nur einmal erforderlich. Agent und Server vereinbaren bei der Registrierung einen geheimen Schlüssel, der nur diesem Host bekannt ist. Das Passwort des WATO-Users wird nirgendwo gespeichert.
  • Während der interaktive Modus nur Felder abfragt, die in noch keiner Konfiguration vorhanden sind, lassen sich durch den nicht-interaktiven Modus alle in der Hilfe angezeigten Felder setzen und haben für diesen Aufruf die höchste Priorität. Optionen, die nur in cmk-update-agent.state gespeichtert sind, werden so überschrieben - Optionen aus cmk-update-agent.cfg jedoch nicht. Siehe auch hier weiter unten unter Einsehen der lokalen Konfiguration.

Nach einer erfolgreichen Registrierung wird der Schlüssel beim Agenten in der Datei /etc/cmk-update-agent.state gespeichert. Auf dem Server liegt er dann in ~/var/check_mk/agent_deployment/myhost. Der Schlüssel erlaubt von nun an dem Host, seinen eigenen Agenten ohne Passwort vom Server herunterzuladen. Ein Herunterladen von Agenten anderer Hosts ist nicht möglich (da diese vertrauliche Daten enthalten könnten).

1.6. Master Switch

Als Letztes aktivieren Sie das Ganze durch einen klick auf beim Master Switch. Die Tabelle Prerequisites sollte nun so aussehen:

Ab sofort wird sich nun der Agent einmal innerhalb eines Update-Intervalls melden und nach einer neuen Version des Agenten Ausschau halten. Sobald diese bereitsteht und signiert ist, wird er sie automatisch herunterladen und installieren.

Eine Schritt-für-Schritt-Anleitung bietet auch das Video unter folgendem Link, das auf der Checkmk Konferenz #3 (2017) entstanden ist. Es handelt sich hier nicht um die aktuelle Version - Die prinzipielle Vorgehensweise hat sich jedoch nicht verändert: Die neuen automatischen Agent Updates

2. Begrenzung des Updates auf bestimmte Hosts

Bevor Sie einen neuen Agenten auf eine größere Zahl von Host ausrollen, möchten Sie diesen sicherlich zuerst mit einer kleineren Anzahl von Hosts ausprobieren. Dieser wichtige Schritt verhindert, dass ein möglicher Fehler große Ausmaße annimmt.

Dazu dient der mittlere Kasten auf der Seite Automatic agent updates:

Nachdem Sie hier Bedingungen für die Auswahl von Hosts getroffen haben, können Sie mit dem Feld Test with the host name einzelne Hostnamen eintippen und kontrollieren, ob die Updates für diese Hosts nun aktiviert sind oder nicht. Die Bedingungen werden dabei immer mit und verknüpft.

Gleichzeitig ist natürlich auch der Master Switch eine Möglichkeit, die Updates global abzuschalten.

Wichtig: Auf Hosts, die bisher noch nicht mit automatischen Updates versorgt werden sollen, dürfen natürlich auch nicht das Agent-Updater-Plugin enthalten. Andernfalls wird das Plugin Sie regelmäßig davor warnen, dass der Host bisher noch nicht registriert ist.

3. Diagnose

Zur Diagnose, ob alle Updates wie gewollt funktionieren, gibt es etliche Informationsquellen:

3.1. Statistik auf der Seite Automatic agent updates

Diese Übersicht zeigt, wie sich die einzelnen Hosts im Agenten-Update verhalten. Die Onlinehilfe gibt weitere Erklärungen. Ein Klick auf bringt Sie zu einer detaillierten Liste der einzelnen Hosts. Zu der Gesamtliste aller registrierten Hosts gelangen Sie auch über die Ansicht Monitoring Agents ➳ Automatic updates ➳ Update status. Dort können Sie dann gezielt nach einzelnen Hosts suchen.

In dieser Liste finden Sie auch dokumentiert, wie der Hash eines des Agenten anfängt, der für einen Host vorgesehen ist (Target Agent), welcher zuletzt vom Host runtergeladen wurde (Downloaded Agent) und welcher aktuell auf dem Host installiert ist (Installed Agent). So können sie jederzeit nachvollziehen, ob die Vorgabe eingehalten wurden oder wo sich der Prozess gerade befindet. Zu beachten ist hierbei, dass die Statusinformationen weiter links direkt bei der Kommunikation zwischen Agent Bakery und Agent Updater entstehen, während die Felder Update Check und Update Check Output von dem Agent-Updater-Plugin bei der Abfrage des Agenten des Hosts kommen und durch die Zwischengespeicherung (definiert durch das Abfrageintervall) ggf. zu einem anderen Zeitpunkt aktualisiert werden.

3.2. Der neue Check Checkmk Agent bei jedem betroffenen Host

Wenn Sie auf einem Agenten das Update-Plugin installiert haben, gibt dieser regelmäßig den aktuellen Status des Updates in Form von Monitoringdaten aus. Die Serviceerkennung erzeugt daraus einen neuen Service bei dem Host mit dem Namen Checkmk Agent. Dieser spiegelt den aktuellen Zustand des Updates wieder. Sie können sich so in Form von Monitoring-Alarmen über ein Problem mit den Updates benachrichtigen lassen.

Der Zustand dieses Checks ist als Schlimmstes auf WARN begrenzt.

3.3. Einsehen der lokalen Konfiguration

Das Verhalten des Agent Updaters wird maßgeblich durch die beiden Dateien cmk-update-agent.cfg und cmk-update-agent.state bestimmt. Dabei gilt immer, dass gesetzte Werte aus der .cfg-Datei über die .state-Datei gewinnen. Zeigt der Agent-Updater unerwartetes Verhalten, lohnt sich manchmal ein Blick in die Konfiguration. Dafür gibt es auch eine praktische Funktion, wenn Sie den Agent-Updater direkt in der Kommandozeile aufrufen:

root@linux# cmk-update-agent show-config
Showing current configuration...

Configuration from config file (/etc/check_mk/cmk-update-agent.cfg):
signature_keys: ['-----BEGIN CERTIFICATE-----\ncertificate\n'-----END CERTIFICATE-----\n']
protocol: http
interval: 86400
site: mysite

server: 10.0.0.42
certificates: []

Configuration from state file (/etc/cmk-update-agent.state):
installed_aghash: a91310934c83ce696
last_error: 404 Client Error: Not Found for url: http://mymonitoring/myothersite/check_mk/deploy_agent.py
host_name: myhost
last_check: 1550232737.28
last_update: 1550232737.37
host_secret: lvhfstjgmblmutzrplkspwifmmfperlditvcqmrxglgzbeaeplibcthawgzsggou
user: automation

3.4. Logmeldungen auf dem Zielhosts selbst

Im Falle eines Problems finden Sie auch auf dem zu überwachenden Host Logdaten über die Updates. Unter Linux loggt cmk-update-agent wichtige Informationen wie Warnings und Errors nach syslog. Ein detaillierteres Log inklusive Debug-Ausgaben und eventuelle Tracebacks findet sich unter /var/lib/check_mk_agent/cmk-update-agent.log. Unter Windows wird ebenfalls ein detailliertes Log in die Datei log/cmk-update-agent.log geschrieben. Sie können aber auch beiden Systemen per Kommandozeilenoption --logfile LOGFILE einen alternativen Pfad für ein Debug-Log angeben.

/var/log/syslog
Oct 22 13:59:23 klappgrill [cmk-update-agent] WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
Oct 22 13:59:23 klappgrill [cmk-update-agent] ERROR: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.
/var/lib/check_mk_agent/cmk-update-agent.log
2018-10-22 13:59:23,408 DEBUG: Starting Check_MK Agent Updater v1.5.0p7
2018-10-22 13:59:23,409 DEBUG: No state file found yet. New state data will be saved to /etc/cmk-update-agent.state
2018-10-22 13:59:23,409 WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
2018-10-22 13:59:23,410 DEBUG: Starting manual update mode.
2018-10-22 13:59:23,410 DEBUG: Caught Exception:
Traceback (most recent call last):
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1890, in main
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 686, in run
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1095, in _run_mode
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1142, in _do_update_as_command
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1207, in _do_update_agent
Exception: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.
2018-10-22 13:59:23,410 ERROR: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.

4. Einsatzszenarien

4.1. Automatische Updates für einen Host abschalten

Soll ein Host aus den automatischen Updates entfernt werden, so passen Sie über den Regelsatz Install agent updater (Linux, Windows) dessen Einstellung so an, dass das Update-Plugin dort deaktiviert ist. Beim nächsten regelmäßigen Update entfernt der Agent seinen Updater dann selbst!

Es versteht sich von selbst, dass das Update dann nur durch die manuelle Installation eines neuen Agentenpakets erneut aktivert werden kann! Die Registrierung bleibt aber erhalten und muss nicht erneuert werden.

4.2. Umzug auf eine neue Monitoring-Instanz

Möchten Sie auf eine neue Checkmk-Instanz umziehen, ohne dabei die am Server registrierten Hosts zu verlieren, so ist dabei zu beachten, dass für einen erfolgreichen Agent-Update-Vorgang die folgenen Informationen auf Server und Host übereinstimmen müssen:

  • Der Name, unter dem der Host überwacht wird und registriert ist
  • Das Host Secret, das bei der Registrierung vergeben wurde.
  • Die Signatur, mit dem die Agenten signiert werden

Um dies zu erreichen, gehen Sie folgendermaßen vor:

  • Nehmen Sie alle Hosts, dessen Registrierungsinformationen portiert werden sollen, zunächst in der neuen Instanz ins Monitoring auf. Achten Sie darauf, dass die Hosts in der neuen Instanz unter demselben Namen überwacht werden. Kopieren Sie danach den Ordner ~/var/check_mk/agent_deployment von der alten zur neuen Monitoring-Instanz.
  • Exportieren Sie den oder die Signaturschlüssel, den die auf den Hosts installierten Agenten akzeptieren, zur neuen Monitoring-Instanz. Die Signaturschlüssel lassen sich unter Monitoring Agents ➳ Signature keys ex- und importieren.
  • Konfigurieren Sie die Agent-Updater Regel auf der neuen Monitoringinstanz entsprechend der Anleitung und signieren Sie die gebackenen Agenten mit dem/den importieren Signaturschlüssel(n).
  • Konfigurieren Sie zuletzt in der Agent-Updater Regel auf der alten Instanz die Felder für den Updateserver und den Namen der Checkmk-Instanz entsprechend Ihrer neuen Monitoring-Instanz und backen Sie die Agenten neu. Achtung: Bitte prüfen Sie an dieser Stelle, ob sie alles richtig angegeben haben bevor Sie die Agenten neu backen.

Sobald die nächsten automatischen Updates auf den Hosts durchlaufen, wird die alte Monitoring-Instanz ausgesperrt. Die zu überwachenden Hosts werden sich zukünftig nur noch bei dem neuen Checkmk-Server melden. Nach dem zweiten automatischen Update wurde dementsprechend der Agent vom neuen Checkmk-Server installiert.

4.3. Der Agent Updater als automatischer Installer

Achtung: Hierbei handelt es sich um keine offizielle Funktion des Agent Updaters. Die Anleitung richtet sich daher vor allem an erfahrenere Nutzer. Der offizielle Weg, den Checkmk Agent auf einem Host zu installieren, ist das Herunterladen und Ausführen des zum System passenden Agenten-Pakets. Es ist jedoch auch möglich, den Checkmk Agent initial vom Agent Updater installieren zu lassen, denn dieser funktioniert auch als eigenständiges Programm.

Gehen Sie dafür folgendermaßen vor:

  • Kopieren Sie das cmk-update-agent Binary oder das cmk_update_agent.py Skript (beides zu finden unter ~/share/check_mk/agents/plugins auf dem Checkmk-Server) auf den zu überwachenden Host.
  • Registrieren Sie den Host am Checkmk-Server mit dem Aufruf von cmk-update-agent register. Hier bietet sich es an, die benötigten Registrierungsinformationen per Kommandozeile direkt zu übergeben. Vor allem, wenn Sie ein Installationsskript verwenden wollen. Die entsprechenden Optionen können Sie sich beim Aufruf von cmk-update-agent register --help angezeigen lassen.
  • Anschließend installieren Sie den Agenten mit allen Konfigurationsdetails für den zu überwachenden Host durch einen abschließenden Aufruf des Agent-Updater-Plugins. Da jedoch keine lokale Konfiguration (der Agent Updater zeigt auch eine entsprechende Warnung an) und somit auch keine Signatur für das herunterzuladende Agent-Paket vorliegt, rufen Sie den Updater einmalig mit cmk-update-agent --skip-signatures auf, um dem heruntergeladenen Paket explizit zu vertrauen. Voraussetzung für die Installation per Agent-Updater ist natürlich, dass von der Agent Bakery auf dem Checkmk-Server ein passendes Agenten-Paket für den Zielhost bereitliegt.

5. Agenten-Updates im verteilten Monitoring

Wenn Sie ein verteiltes Monitoring mit mehreren Instanzen betreiben, so erfolgt das Bereitstellen der Updates ausschließlich durch den zentralen Server. Eine Verteilung der Agenten auf Slave-Server ist in der aktuellen Implementierung (noch) nicht vorgesehen.

6. Typische Fehler und ihre Ursachen

6.1. Bereits behobene Fehler im Service Checkmk Agent

Der Agent Updater wird nur einmal innerhalb des Update-Intervals wirklich ausgeführt. Ein Fehler wird also solange angezeigt, Sie das Plugin entweder manuell aufrufen, oder das nächste Intervall ansteht.

6.2. Registrierung schlägt nach einer manuellen Neuinstallation des Checkmk-Agenten fehl

Der Agent Updater legt sich (unter Linux/Unix unter /etc, unter Windows im config-Ordner) selbständig die Statusdatei cmk-update-agent.state an. Diese verbleibt nach Deinstallation weiterhin auf dem Host, damit die Registrierungsinformationen nicht verlorengehen. Eine neue Installation findet diese Datei ebenfalls wieder und verwendet diese. Wenn dieser Effekt unerwünscht ist, löschen Sie die Datei cmk-update-agent.state nach einer Deinstallation einfach manuell.

6.3. Update Status für Hosts, bei denen gar keine automatischen Updates aktiv sind

Auf der Seite Agent Update Status werden alle Hosts angezeigt, die sich im Monitoring befinden und für die gleichzeitig eine Statusdatei auf dem Checkmk-Server existiert. Dabei ist es ganz unerheblich, ob sich der Host tatsächlich für automatische Updates beim Checkmk Server meldet. Wird hier ein unerwarteter Host angezeigt, lohnt sich ein Blick in den Ordner /omd/sites/mysite/var/check_mk/agent_deployment, da sich hier wahrscheinlich eine alte oder versehentlich erzeugte Registrierung befindet.

6.4. Die Verbindung über SSL/TLS funktioniert nicht

Der Agent-Updater ist so konzipiert, dass er explizit nur den Zertifikaten vertraut, die in der Regel in Agent updater (Linux, Windows) bei der HTTPS-Konfiguration angegeben sind. Insbesondere werden lokal installierte Zertifikate ignoriert. So kann es auch vorkommen, dass der Checkmk-Server über den Browser erreichbar ist, während der Agent-Updater keine Verbindung (aufgrund einer falschen Konfiguration) aufbauen kann.

Bei der HTTPS-Konfiguration der Agent Updater Regel muss ein Root-Zertifikat angegeben werden, mit dem die Verbindung zum Checkmk-Server verifiziert werden kann. Mit anderen Worten: Die Zertifikatskette, die im Server-Zertifikat des Checkmk-Servers hinterlegt ist, muss durch das hier angegebene Zertifikat verifiziert werden können. Oft wird hier stattdessen das Server-Zertifikat angegeben. Dieses jedoch für diesen Zweck nicht geeignet ist.

Schauen Sie sich einmal die Zertifikatskette des Checkmk-Servers mit dem Tool OpenSSL an. Aufgrund der Länge wird nur ein Ausschnit gezeigt und gekürzte Stellen [...] markiert:

root@linux# openssl s_client -connect mymonitoring.example.net:443
[...]
subject=/CN=mymonitoring.example.net
issuer=/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3832 bytes and written 302 bytes
Verification: OK
---
[...]

Für den letzten Eintrag – in unserem Fall subject=/CN=mymonitoring.example.net – benötigen Sie ein gültiges Root-Zertifikat. Dieses muss nicht, wie in diesem Beispiel, unbedingt der Aussteller des Zertifikats sein. In der Regel handelt es sich um eine Kette von Ausstellern.

Schauen Sie sich anschließend das eingesetzte Zertifikat an. Auch hier wird aufgrund der Länge wie oben gekürzt:

root@linux# openssl x509 -in -text -noout myca.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 38 (0x26)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
        Validity
            Not Before: Jul  9 12:11:00 1999 GMT
            Not After : Jul  9 23:59:00 2019 GMT
        Subject: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
        [...]
        X509v3 extensions:
            [...]
            X509v3 Basic Constraints:
                CA:TRUE, pathlen:5
            [...]

Das oberste Zertifikat – zu sehen in dem obigen Ausschnitt – darf keine Abhängigkeit zu einem anderen Zertifikat haben. Das können Sie daran erkennen, dass der Ausstellende (Issuer) und der Gegenstand (Subject) identisch sind und die option CA:TRUE enthalten ist. Zusätzlich muss die Kette der Ausstellenden, welche einen Gegenstand geblaubigen, bis zu dem letzten Eintrag konsistent sein. Sie benötigen also auch alle Zwischenzertifikate, wenn der Aussteller des letzten kein CA sein sollte.

Einen ausführlichen Einblick in die gesamte Thematik bietet auch das folgende Video, das auf der Checkmk Konferenz #4 (2018) entstanden ist: SSL und Zertifikate

6.5. Fehlermeldung: Cannot open self cmk-update-agent or archive cmk-update-agent.pkg

Auf einigen Linux-Systemen ist das Programm Prelink installiert und ein cronjob aktiviert, der regelmäßig alle Binärdateien auf dem System untersucht und gegebenenfalls angepasst, um die Programme zu beschleunigen. Das Agent-Updater-Plugin wird aber mit dem Programm PyInstaller paketiert, welche zu solchen Maßnahmen nicht kompatibel sind und dadurch kaputt gemacht werden. Checkmk hat daher bei deb-/rpm-Paketen eine Blacklist-eintrag hinterlegt, welcher unter /etc/prelink.conf.d abgelegt wird und – falls prelink vorhanden ist – einen Eintrag in der vorhandenen Datei /etc/prelink.conf setzt. Da dieses Problem nur schwer zu fassen ist, kann es dennoch – insbesondere bei einer nachträglichen Einrichtung von prelink – dazu kommen, dass diese Maßnahmen nicht greifen.

Setzen Sie daher bei einer nachträglichen Installation von prelink die Eintrag selbst und fügen Sie die folgende Zeile der Datei mit folgendem Kommando hinzu:

root@linux# echo "-c /etc/prelink.conf.d/cmk-update-agent.conf" >> /etc/prelink.conf

6.6. Fehlermeldung cmk-update-agent: error while loading shared libraries: libz.so.1: failed to map segment from shared object

Diese Fehlermeldung tritt auf, wenn das /tmp-Verzeichnis mit dem Flag noexec in das System eingehängt wurde. Um dieses Problem können Sie entweder das Flag entfernen, oder – weil Sie das Flag bewusst gesetzt haben und benötigen – auf dem Checkmk-Server im WATO eine Regel unter Monitoring Agents ➳ Rules ➳ Installation paths for agent files (Linux, UNIX) anlegen. Dort können Sie das tmp-Verzeichnis in der option Directory for storage of temporary data (set TMPDIR environment variable) selbst definieren. Das Agent-Updater-Plugin wird dann zukünftig temporäre Dateien in das definierte Verzeichnis schreiben. Das klappt sogar, wenn Sie das Plugin manuell mit dem Helferskript in /usr/bin/cmk-update-agent aufrufen.