Checkmk
to checkmk.com

CEE Die kommerziellen Editionen können ihre 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 (Agent Bakery) nutzen, um Hosts individuell zu konfigurieren.

1. Automatische Updates einrichten

Die automatische Verteilung von Agenten ist standardmäßig global deaktiviert. Bevor Sie sich also um die Konfiguration selbst kümmern, aktivieren Sie die Option Activation of automatic agent updates unter Setup > General > Global settings > Automatic agent updates:

agent deployment activation of automatic agent updates

Gehen Sie zum Einrichten der Updates nach folgenden Schritten vor: Öffnen Sie zuerst Setup > Agents > Windows, Linux, Solaris, AIX und wählen Sie dort Agents > Automatic updates.

agent deployment automatic agent updates

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. Vergessen Sie nicht, dass Sie für jeden dieser Punkte über Help > Show inline help weitere Informationen erhalten können. Ein Klick auf icon edit bringt Sie direkt zu der Einstellung, die Sie konfigurieren müssen. Im Einzelnen müssen die in den folgenden fünf Kapiteln beschriebenen Einstellungen vorgenommen und über den Master switch aktiviert werden.

1.1. Signaturschlüssel erstellen

Das System ist so aufgebaut, dass die Agenten per HTTP oder HTTPS von ihrem zentralen Monitoring-Server 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 Monitoring-Servers erlangt, Agenten signieren kann.

Erzeugen Sie hier einen Signaturschlüssel und merken Sie sich die Passphrase.

Wichtig: Der Signaturschlüssel 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 Agentenplugin mit dem Namen cmk-update-agent ausgeführt. Dieses wird vom Agenten in einem einstellbaren Zyklus aufgerufen (z.B. einmal pro Stunde). Es fragt dann den Deployment-Server (Ihr zentrales Monitoring-System) 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 um dieses Plugin mit dem Regelsatz Agent updater (Linux, Windows, Solaris). Den Regelsatz finden Sie z.B. schnell auf der Seite Automatic agent updates im Menü Related > Agent updater ruleset.

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, sodass diese nicht in den spezielleren Regeln immer wieder neu gesetzt werden müssen. Zusätzlich bietet auch hier die Inline-Hilfe weitere Informationen zu jedem einzelnen Punkt, sobald Sie diesen aktivieren.

agent deployment agent updater empty

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

Aktivierung (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 Ordnerebene eine Grundeinstellung zu setzen und diese für einzelne Hosts und Ordner zu überschreiben.

Aktualisiere Server Informationen (Update server information)

Optional lassen sich hier bereits zur Konfiguration Daten für die Verbindung des Agent Updaters zum Checkmk-Server angeben. Werden die zugehörigen Einträge nicht konfiguriert, müssen die Informationen später beim Registrieren des Agent Updaters angegeben werden.

Verwendung (Usage)

Bei einem verteilten Monitoring mit zentraler Konfiguration erhält der Agent Updater standardmäßig seinen zuständigen Update-Server von der Checkmk-Instanz, zu der er sich verbindet. Mit dieser Option lässt sich konfigurieren, dass der hier eingegebene Update-Server dauerhaft verwendet und der automatische Update-Server ignoriert wird.

DNS-Name oder IP-Adresse des Update-Servers (DNS name or IP address of update server)

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

Name der Checkmk-Instanz des Update-Servers (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 Instanz ein. Siehe hier auch weiter unten unter Einsatzszenarien. Bei einem verteilten Setup mit zentraler Konfiguration kann die Instanz, an der Sie sich registrieren wollen, ebenfalls von der zentralen Instanz, auf der diese Regel konfiguriert wird, abweichen.

Protokoll zum Holen von Updates (Protocol to use for fetching updates)

Wenn Sie - wie von uns empfohlen - HTTPS verwenden, müssen Sie sicherstellen, dass dem Agent Updater auch ein CA-Zertifikat (CA = Certification Authority) zur Verfügung steht, mit dem die Verbindung verifiziert wird.

Wichtig: Je nach Konfiguration des Servers kann es sein, dass HTTPS (inklusive Weiterleitung von HTTP auf HTTPS) erzwungen wird. In einem solchen Fall ist eine Konfiguration dieser Regel auf HTTP wirkungslos.

Zertifikate für HTTPS-Verifizierung (Certificates for HTTPS verification)

Hier konfigurierte CA- oder selbst signierte Zertifikate stehen dem Agent Updater für die Verifikation von HTTPS-Verbindungen zur Verfügung. Alternativ hierzu können dem Agent Updater bei einem verteilten Setup mit zentraler Konfiguration auch Zertifikate von der Checkmk-Instanz zur Verfügung gestellt werden oder diese per Kommandozeilenparameter direkt bei der Verbindung importiert werden.

Wichtig: Ist die Zertifikatskette des Servers mit einer öffentlichen CA signiert, kann die Verbindung im Normalfall ohne importierte Zertifikate verifiziert werden. Sobald dem Agent Updater aber importierte Zertifikate aus einer der genannten Quellen zur Verfügung stehen, werden alle anderen CA-Zertifikatsstellen ignoriert! Bei Problemen mit der Konfiguration von HTTPS, konsultieren Sie bitte das unten folgende FAQ.

Intervall für den Update-Check (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 abgelaufen ist, wird ein zwischengespeicherter Aufruf zurückgegeben, um das Netzwerk so wenig wie möglich zu belasten. Normalerweise ist es sinnvoll, ein Intervall zu nutzen, welches mindestens 10 Minuten oder mehr beträgt, da sonst die Gefahr besteht, dass Ihr Netzwerk unnötig belastet wird, falls Sie sehr viele Checkmk-Agenten haben. Wenn Sie hier nichts einstellen, gilt ein Defaultwert von 1 Stunde.

Proxy-Einstellungen (Proxy settings)

Diese Regeleinstellung ist ebenfalls 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.

Ausführbares Format (Linux) (Executable format (Linux))

Sie können 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 64-Bit-Binary übergeben. Optional können Sie auch ein 32-Bit-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: Für Windows wird das Plugin immer als 32-Bit-Executable ausgeliefert. Diese Regel wird dementsprechend standardmäßig ignoriert. Hinweis: Etwaig vorhandene 64-Bit-Binaries stammen aus älteren Versionen von Checkmk und entsprechen nicht mehr dem aktuellen Standard.

  • Solaris: Hier müssen Sie ebenfalls nichts anpassen. Checkmk wird hier das Python-Skript verwenden, auch wenn Sie den Standardwert auf dem 64-Bit-Binary lassen.

  • Andere Architekturen: Wenn Sie Pakete für andere Architekturen, wie beispielsweise arm oder ppc, verwenden möchten, setzen Sie diese Option manuell auf Python. Dies ist notwendig, da diese Architekturen von Checkmk nicht automatisch abgefangen werden und keine Binaries dafür angeboten werden.

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

  • Python3 in der Version 3.4 oder neuer

  • Die Python-Module requests, PySocks und pyOpenSSL

Signaturen, die der Agent akzeptieren soll (Signature keys the agent will accept)

Wählen Sie hier mindestens einen Signaturschlüssel aus, dessen Signatur vom Agent 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.

Nach dieser letzten Anpassung könnte Ihre Regel wie im folgenden Screenshot aussehen. Speichern Sie alle Ihre Angaben durch einen Klick auf icon save Save.

agent deployment agent updater

1.3. Agenten backen und signieren

Als Nächstes können Sie bereits die so konfigurierten Agenten in einem Schritt backen und signieren. Die erstellten und angepassten Regeln finden sich nämlich erst dann in den Installationspaketen wieder, wenn Sie diese neu erstellen/backen. Navigieren Sie dazu wieder nach Setup > Agents > Windows, Linux, Solaris AIX und klicken Sie dann auf Bake and sign agents. Sie müssen nun die Passphrase des gewünschten Schlüssels eingeben. Nach dem Klick auf Bake and sign startet der Backvorgang als Hintergrundprozess. Wenn dieser Prozess abgeschlossen ist, werden Sie darüber informiert:

agent deployment agent baking successful

Alle so signierten Agenten werden mit einem entsprechenden Symbol icon signature key gekennzeichnet. Wenn Sie mehrere Schlüssel angelegt haben, signieren Sie mit den weiteren Schlüsseln separat.

Wichtig: Einem Agent Updater auf dem zu überwachenden Host genügt es, wenn das neue Paket mit einem der ihm bekannten Schlüssel signiert ist.

1.4. Agenten registrieren

Registrieren Sie im nächsten Schritt die Hosts, für die Sie den Agent Updater einrichten wollen, 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 zunächst unter Setup > Agents > Windows, Linux, Solaris, AIX das für den Host passende Paket aus der Agentenbäckerei herunter. Achten Sie darauf, dass das Paket auch wirklich das Agent-Updater-Plugin enthält.

Agenten unter Linux registrieren

Kopieren Sie nun das Agentenpaket auf den zugehörigen Host und installieren Sie es mit rpm bzw. dpkg (Paketinstallation unter Linux.)

Nach der Installation finden Sie das Agent-Updater-Plugin im Verzeichnis /usr/lib/check_mk_agent/plugins/3600/cmk-update-agent. Das Unterverzeichnis 3600 steht dabei für das Intervall für den Update-Check in Sekunden (hier für den Standardwert von einer Stunde). Ein gleichnamiges Skript wird auch unter /usr/bin/ abgelegt, daher steht cmk-update-agent auch als Kommando zur Verfügung.

Rufen Sie nun den Agent Updater mit dem Argument register auf. Geben Sie dann der Reihe nach die erforderlichen Angaben ein.

Mit dem folgenden Kommando registrieren Sie den Agent Updater von einem Linux-Host aus:

root@linux# cmk-update-agent register -v
-------------------------------------------------------------------
|                                                                   |
|  Check_MK Agent Updater v2.1.0 - 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 a user with the permission                |
|  "Register all hosts" on that Checkmk site.                       |
|                                                                   |
-------------------------------------------------------------------
Our host name in the monitoring:
myhost

User with registration permissions:
cmkadmin

Password:

Going to register agent at deployment server
Successfully registered agent of host "myhost" 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 myserver.example.com -i mysite -H myhost -p https -U cmkadmin -P * -v

Alternativ können Sie die Registrierung auch im nicht-interaktiven Modus durchführen, indem die benötigten Daten per Kommandozeilenoptionen übergeben werden. Ein Aufruf von cmk-update-agent register --help zeigt die setzbaren Optionen an.

Agenten unter Windows registrieren

Kopieren Sie nun das Agentenpaket auf den zugehörigen Host und installieren Sie es mit msiexec (Paketinstallation unter Windows.)

Nach der Installation ist der Agent Updater in den Windows-Agenten C:\Program Files (x86)\checkmk\service\check_mk_agent.exe integriert. Dem Updater selbst können Sie dann immer mit check_mk_agent.exe updater Befehle erteilen.

Rufen Sie nun den Agent Updater mit dem Argument register auf. Unter Windows muss dies in einer Eingabeaufforderung mit Administratorrechten geschehen. Geben Sie dann der Reihe nach die erforderlichen Angaben ein.

Da der Agent Updater für Windows-Hosts direkt durch den Agenten selbst ausgeführt wird, sieht der Befehl für die Registrierung so aus:

C:\WINDOWS\system32> "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" updater register
Using previous settings from C:\ProgramData\checkmk\agent\config\cmk-update-agent.state.
Our host name in the monitoring:
mywindowshost

User with registration permissions:
cmkadmin

Password:

Successfully registered agent of host "mywindowshost" for deployment.

Alternativ können Sie die Registrierung auch im nicht-interaktiven Modus durchführen, indem die benötigten Daten per Kommandozeilenoptionen übergeben werden. Der komplette Befehl zur Registrierung sieht wie folgt aus:

C:\WINDOWS\system32> "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" ^
updater register -s myserver.example.com -i mysite -H mywindowshost -p https -U cmkadmin -P mycmkadminpassword -v

Einmalige Registrierung und generelle Hinweise

Die einmalige Registrierung kann auch über einen Automationsbenutzer erfolgen. Dafür wird auf der Kommandozeile der Benutzer per -U/--user und das Automationspasswort per -S/--secret ü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 nicht unbedingt mit dem Host-Namen des Rechners identisch. Der Host-Name wird dann zusammen mit dem Schlüssel lokal gespeichert.

  • Um HTTPS zu verwenden, muss auf Ihrem Monitoring-Server HTTPS eingerichtet sein. HTTP ist hier deutlich einfacher, bietet aber keine Verschlüsselung der Übertragung. Da der Agent in Skripten und Konfigurationsdateien 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 Checkmk-Administrator ist nur einmal erforderlich. Agent und Server vereinbaren bei der Registrierung einen geheimen Schlüssel (Host Secret), der nur diesem Host bekannt ist. Das Passwort des Checkmk-Administrators 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 der Datei cmk-update-agent.state gespeichert sind, werden so überschrieben — Optionen aus cmk-update-agent.cfg jedoch nicht. Mehr Details dazu gibt es weiter unten unter Einsehen der lokalen Konfiguration.

Nach einer erfolgreichen Registrierung wird das Host Secret beim Agenten in der Datei /etc/cmk-update-agent.state gespeichert. Auf dem Server liegt er dann in ~/var/check_mk/agent_deployment/myhost. Das Host Secret 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.5. Master switch

Nun sollten alle Bedingungen erfüllt sein. Falls noch nicht passiert, aktivieren Sie das Ganze durch einen Klick auf icon edit beim Master switch. Die Tabelle Prerequisites sieht dann so aus:

agent deployment prerequisites fulfilled

Ab sofort wird sich nun der Agent jeweils zum Ende des konfigurierten 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.

Gleichzeitig ist der Master switch eine Möglichkeit, die Updates global abzuschalten.

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 Hosts ausrollen, möchten Sie ihn 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:

agent deployment host selection

Die Bedingungen werden dabei immer mit einer Konjunktion (logisches UND) verknüpft: Nur Hosts, die alle ausgewählten Bedingungen erfüllen, erhalten das Update. Nachdem Sie hier Bedingungen für die Auswahl von Hosts festgelegt haben, können Sie in dem Feld Test hostname before activation einzelne Host-Namen eintippen und kontrollieren, ob die Updates für diese Hosts nun aktiviert sind oder nicht.

Wichtig: Auf Hosts, die bisher noch nicht mit automatischen Updates versorgt werden sollen, darf das installierte Paket 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 zur Agentenverteilung

agent deployment update status

Diese Übersicht zeigt, wie sich die einzelnen Hosts im Agenten-Update verhalten. Die Inline-Hilfe gibt weitere Erklärungen. Ein Klick auf icon view 20 bringt Sie zu einer detaillierten Liste der einzelnen Hosts. Zu der Gesamtliste aller registrierten Hosts gelangen Sie auch über die Ansicht Monitor > System > Agent update status. Dort können Sie dann gezielt nach einzelnen Hosts suchen.

agent deployment status view

In dieser Liste finden Sie auch dokumentiert, wie der Hash eines Agenten anfängt, der für einen Host vorgesehen ist (Target Agent), welcher zuletzt vom Host heruntergeladen wurde (Downloaded Agent) und welcher aktuell auf dem Host installiert ist (Installed Agent). So können Sie jederzeit nachvollziehen, ob die Vorgaben eingehalten wurden oder wo sich der Prozess gerade befindet. Zu beachten ist hierbei, dass die Statusinformationen weiter links direkt bei der Kommunikation zwischen Agentenbäckerei 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 Zwischenspeicherung (definiert durch das Abfrageintervall) ggf. zu einem anderen Zeitpunkt aktualisiert werden.

3.2. Der Service Check_MK Agent

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

agent deployment agent check

Unter anderem signalisiert der Zustand des Services, wie der Status des Signaturschlüssels beurteilt wird. Folgende Zustände sind möglich:

  • WARN: Das Zertifikat des Signaturschlüssels ist korrupt, nicht mehr gültig oder wird in den nächsten 90 Tagen ungültig.

  • CRIT: Es gibt kein gültiges Zertifikat für den Signaturschlüssel oder das Zertifikat verliert innerhalb der nächsten 30 Tage seine Gültigkeit.

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):
server: myserver
site: mysite
protocol: http
certificates: []
ignore_update_url: False
interval: 3600
proxy: None
signature_keys: ['-----BEGIN CERTIFICATE-----\n [...] \n-----END CERTIFICATE-----\n']
use_proxy_env: False

Configuration from state file (/etc/cmk-update-agent.state):
last_error: None
host_secret: zqscykkqfdkpwnwenqfibdksqvuamblstbtmpasbhnlbubmncgmrqxvakasittxw
host_name: myhost
user: cmkadmin
last_check: 1660750511.8183599
pending_hash: None
installed_aghash: 94b60c8ef40c4900
last_update: 1660750584.8527653

3.4. Log-Meldungen

Im Falle eines Problems finden Sie auch auf dem zu überwachenden Host Log-Daten über die Updates. Unter Linux loggt cmk-update-agent wichtige Informationen wie Warnings und Errors nach syslog:

/var/log/syslog
Jul 02 13:59:23 myhost [cmk-update-agent] WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
Jul 02 13:59:23 myhost [cmk-update-agent] ERROR: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.

Eine detailliertere Log-Datei cmk-update-agent.log inklusive Debug-Ausgaben und eventuellen Tracebacks finden Sie unter Linux und unter Windows:

/var/lib/check_mk_agent/cmk-update-agent.log
2021-07-02 17:58:18,321 DEBUG: Starting Check_MK Agent Updater v2.0.0p9
2021-07-02 17:58:18,322 DEBUG: Successfully read /etc/cmk-update-agent.state.
2021-07-02 17:58:18,322 DEBUG: Successfully read /etc/check_mk/cmk-update-agent.cfg.
pass:q[[...]]
2021-07-02 17:58:18,387 INFO: Target state (from deployment server):
2021-07-02 17:58:18,387 INFO:   Agent Available:     True
2021-07-02 17:58:18,387 INFO:   Signatures:          1
2021-07-02 17:58:18,387 INFO:   Target Hash:         081b6bcc6102d94a
2021-07-02 17:58:18,387 INFO: Ignoring signature #1 for certificate: certificate is unknown.
2021-07-02 17:58:18,388 DEBUG: Caught Exception:
Traceback (most recent call last):
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1733, in main
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 714, in run
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1372, in _run_mode
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1071, in _do_update_as_command
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1150, in _do_update_agent
  File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1221, in _check_signatures
Exception: No valid signature found.

Sie können aber auch auf beiden Systemen per Kommandozeilenoption --logfile LOGFILE einen alternativen Pfad für die Log-Datei angeben.

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 Agent updater (Linux, Windows, Solaris) 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 aktiviert werden kann. Die Registrierung bleibt aber erhalten und muss nicht erneuert werden.

4.2. Umzug auf eine neue Monitoring-Instanz

Möchten Sie bei einem Single-Site-Setup 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 folgenden 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 automatisch vergeben wurde.

  • Die Signatur, mit der die Agenten signiert werden.

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

  1. Nehmen Sie alle Hosts, deren 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.

  2. Exportieren Sie die Signaturschlüssel, die die auf den Hosts installierten Agenten akzeptieren. Die Signaturschlüssel lassen sich unter Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Signature keys ex- und importieren.

  3. Importieren Sie diese Signaturschlüssel aus Schritt 2 auf der neuen Monitoring-Instanz.

  4. Konfigurieren Sie die Agent-Updater-Regel auf der neuen Monitoring-Instanz entsprechend der Anleitung und signieren Sie die gebackenen Agenten mit dem/den importieren Signaturschlüssel(n).

  5. Konfigurieren Sie zuletzt in der Agent-Updater-Regel auf der alten Instanz die Felder für den Update-Server 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 wird 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:

  1. 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.

  2. Registrieren Sie den Host am Checkmk-Server mit dem Aufruf von cmk-update-agent register. Hier bietet es sich 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 anzeigen lassen.

  3. 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 Agenten-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 Agentenbäckerei auf dem Checkmk-Server ein passendes Agenten-Paket für den Zielhost bereitliegt.

5. Agenten-Updates im verteilten Monitoring

Seit Checkmk 2.0.0 ist es möglich, gebackene Agenten auch über Remote-Instanzen zu verteilen. Voraussetzung dafür ist ein Setup mit zentraler Konfiguration und die Möglichkeit, dass die Zentralinstanz von den Remote-Instanzen aus per HTTP/HTTPS erreicht werden kann.

Ein solches verteiltes Monitoring kann — vor allem temporär — auch mit verschiedenen Checkmk-Versionen betrieben werden. Dadurch ist es möglich, größere Systeme sukzessive auf eine neue Checkmk-Version umzustellen. Beachten Sie dann jedoch unbedingt die Hinweise zu versionsgemischten Monitoring-Umgebungen im verteilten Monitoring.

5.1. Funktionsweise

Technisch ist das Feature so umgesetzt, dass Update-Anfragen an eine Remote-Instanz an die Zentralinstanz weitergeleitet werden — die gesamte Konfiguration sowie das Backen der Agenten findet also ausschließlich auf der Zentralinstanz statt. Agenten-Pakete, die bereits einmal an einer Remote-Instanz angefragt wurden, werden dort zwischengespeichert (so lange sie gültig sind), so dass die Pakete nicht erneut von der Zentralinstanz heruntergeladen werden müssen. Zudem werden die angefragten Daten bereits auf der Remote-Instanz auf Konsistenz überprüft, so dass unnötige Verbindungen zur Zentralinstanz vermieden werden.

Anders als im Single-Site-Setup ergibt sich der passende Update-Server für die Hosts nicht ausschließlich aus dem Regelwerk des Agent Updaters, sondern wird dem anfragenden Agent Updater von der kontaktierten Checkmk-Instanz mitgeteilt. Dabei wird einem Host der Server zugeteilt, von dessen Instanz aus er überwacht wird. Die Angabe eines Checkmk-Servers wird daher nur noch für die einmalige Registrierung gebraucht, die theoretisch an jeder (vom Host aus erreichbaren) Instanz im gesamten verteilten Monitoring-Setup stattfinden kann. Sollte die Verbindung zum automatisch ermittelten Server fehlschlagen, wird der zuvor gespeicherte Server (aus der Regel-Konfiguration oder zuvor erfolgter manueller Eingabe bei der Registrierung) als Fallback verwendet.

5.2. Konfiguration

Das Verteilen der Agentenpakete über Remote-Instanzen muss nicht separat aktiviert werden - die jeweilige Remote-Instanz erkennt die Situation automatisch und kommuniziert dementsprechend mit der Zentralinstanz sowie dem anfragenden Agent Updater. Sollen sich die Agenten für Updates explizit nur an der Zentralinstanz melden, erfolgt dies über einen fest eingestellten Update-Server im Regelwerk des Agent Updaters.

Damit die Agenten-Updates im verteilten Monitoring tatsächlich funktionieren, müssen jedoch auf der Zentralinstanz noch einige Einstellungen vorgenommen werden, die sich alle in Setup > General > Global settings > Automatic agent updates befinden. Unterscheiden sich die Einstellungen je Remote-Instanz, können diese über Setup > General > Distributed monitoring > icon site globals (Site specific global settings) realisiert werden.

Connection to central agent bakery

An dieser Stelle muss die URL angegeben werden, unter der die Zentralinstanz von der Remote-Instanz aus erreichbar ist, inklusive Protokoll und check_mk, also z.B. https://myserver.org/mysite/check_mk. Während die Checkmk-Instanz versucht, alle anderen fehlenden Einstellungen selbst herauszufinden, ist die Angabe dieser URL nicht optional, da diese Verbindungsrichtung bei einer zentralen Konfiguration sonst nicht zustande kommt. Handelt es sich beim Protokoll um HTTPS, verwendet die Remote-Instanz für die Verifikation der Verbindung automatisch die im Setup zur Verfügung stehenden CA- oder selbst signierten Zertifikate (Setup > General > Global settings > Site management > Trusted certificate authorities for SSL). Die Remote-Instanz benötigt zusätzlich einen zuvor angelegten Automationsbenutzer, um sich an der Zentralinstanz anmelden zu können. Dieser kann hier ebenfalls ausgewählt werden. Wird keiner angegeben, sucht die Remote-Instanz nach einem Automationsbenutzer mit dem Namen Automation.

Connection to remote agent bakery

Da die Remote-Instanzen von den jeweils überwachten Hosts aus nicht notwendigerweise über die gleiche URL erreichbar sind wie von der Zentralinstanz aus, kann hier eine URL für diesen Zweck konfiguriert werden. Diese wird dem Host (bzw. dem anfragenden Agent Updater) dann automatisch bei einem Kontakt zu einer Checkmk-Instanz mitgeteilt. Hier macht die Konfiguration als Site specific global setting besonders Sinn. Wird keine URL angegeben, wird angenommen, dass die Remote-Instanzen von der Zentralinstanz und von den überwachten Hosts aus unter der identischen URL erreichbar sind. Handelt es sich um eine HTTPS-Verbindung, kann dem Host ebenfalls automatisch das passende Zertifikat zur Verfügung gestellt werden. Da hierfür aber leider nicht der zentrale CA-Store verwendet werden kann, lassen sich an dieser Stelle entsprechende Zertifikate angeben. Alternativ können die Zertifikate auch bereits im Agent Updater Regelwerk angegeben werden.

6. HTTPS-Handling

An verschiedenen Stellen dieses Artikels ist von einer Absicherung der jeweiligen Verbindungen über HTTPS die Rede. Hier wird noch einmal zentral zusammengetragen, was alles für eine vollständige Absicherung über HTTPS getan werden muss. Sowohl die Verbindung von Remote- zu Zentralinstanz als auch von Host zu Checkmk-Instanz kann und sollte per TLS abgesichert werden, d.h. über HTTPS erfolgen. Dies ist unabhängig davon, ob es sich dabei um ein Setup mit einer einzelnen Instanz oder ein verteiltes Setup handelt.

6.1. HTTPS verwenden

Um eine Checkmk-Instanz per HTTPS ansprechen zu können, muss zunächst einmal der Monitoring-Server auch für HTTPS konfiguriert sein. Dies kann z.B. über eine geeignete Konfiguration des System-Apache oder besonders einfach durch die HTTPS-Einstellungen der Checkmk-Appliance erreicht werden.

Ob ein Checkmk-Server dann per HTTP oder HTTPS angesprochen wird, entscheidet sich anhand der jeweils konfigurierten URL. Beginnt diese mit https://, wird der Server über das HTTPS-Protokoll über Port 443 angesprochen. Das gilt ebenso für das Protokoll, welches Sie mit der Einstellung Update server information konfiguriert haben. Prinzipiell können Sie auf Apache-Seite die Weiterleitung von HTTP nach HTTPS erzwingen und dafür (zunächst) einzelne Pfade ausnehmen. Details der Konfiguration entnehmen Sie der Apache-Dokumentation der Module mod_rewrite und mod_redirect.

6.2. Zertifikate bereitstellen

Damit eine HTTPS-Verbindung zustande kommen kann, muss die Zertifikatskette oder das selbst signierte Zertifikat (je nachdem, wie der Server konfiguriert ist) des kontaktierten Servers verifiziert werden können. Die Bereitstellung von geeigneten CA- oder selbst signierten Zertifikaten macht dies möglich und kann auf verschiedene Weisen realisiert werden.

Verbindung von Host zu Checkmk-Server

Der Agent Updater versucht grundsätzlich HTTPS-Verbindungen zu verifizieren und bricht diese ab, wenn die Verifizierung nicht möglich ist. Zertifikate zur Verifikation stehen dem Agent Updater aus den folgenden Quellen zur Verfügung:

Agent Updater: In Standardeinstellungen bringt der Agent Updater eine Python Laufzeitumgebung inclusive benötigter Module mit. Enthalten ist auch das Zertifikats-Bundle des Certifi-Moduls. Dieses wiederum basiert auf der Zertifikatssammlung des Mozilla-Projekts. So ist sichergestellt, dass öffentliche CAs dem Agent Updater zeitnah bekannt gemacht werden, selbst wenn Betriebssystemupdates ausstehen.

Zertifikate via Agentenbäckerei: Im Certifi-Modul enthaltene Zertifikate werden ignoriert, sobald ein oder mehrere Zertifikate über einen der folgenden Mechanismen importiert wurden. Zertifikate aus den folgenden Quellen werden lokal auf dem Host gespeichert und nur vom Agent Updater verwendet:

  1. Über die Einstellung Certificates for HTTPS verification können Zertifikate mit in das Agentenpaket eingebacken werden und stehen dem Agent Updater ab Installation (oder Update) zur Verfügung.

  2. Bei der Konfiguration der Verbindung zur Remote-Instanz über Setup > General > Global settings > Automatic agent updates > Connection to remote agent bakery können Sie Zertifikate angeben, mit denen die HTTPS-Verbindung zur jeweiligen Remote-Instanz verifiziert werden kann. Dies ist insbesondere dann sinnvoll, wenn zur Konfigurationszeit noch nicht klar ist, welcher Host welcher Instanz zugeteilt wird. Auch lässt sich mit dieser Importmöglichkeit die Anzahl der zu backenden Agenten reduzieren, da die richtigen Zertifikate für die jeweiligen Update-Server nicht Host-spezifisch konfiguriert werden müssen.

Certificate Store: Nur wenn der Agent Updater so konfiguriert ist, dass er statt der mitgelieferten Python Laufzeitumgebung das System-Python nutzt und im System-Python kein Certifi-Modul konfiguriert ist, nutzt er möglicherweise den Certificate Store des Betriebssystems. Da hier viele Faktoren wie Installationsparameter oder die Umgebungsvariable _PIP_STANDALONE_CERT mit hineinspielen, wird diese Konstellation von uns nicht offiziell unterstützt.

Zertifikat via Kommandozeile: Der Agent Updater lässt sich mit dem Kommandozeilenargument --trust-cert aufrufen. Dadurch wird versucht, ein CA- oder selbst signiertes Zertifikat vom Server abzurufen und dieses zu importieren. Dies funktioniert nur, wenn entweder ein selbst signiertes Zertifikat eingesetzt wird oder wenn die komplette Zertifikatskette inklusive CA-Root-Zertifikat auf dem Server hinterlegt wurde. Letzteres ist für eine gültige Zertifikatskette im Allgemeinen nicht gefordert und daher meist nicht der Fall. Achtung: Wird ein Zertifikat auf diese Weise importiert, muss der Anwender die Authentizität des Servers selbst sicherstellen, da das Zertifikat aus keiner separaten Quelle stammt.

Und wenn gar nichts mehr hilft:

Falls dem Agent Updater gar kein gültiges Zertifikat zur Verfügung steht, kann die Zertifikats-Validierung durch das Kommandozeilenargument --insecure für einen Aufruf umgangen werden. Dies kann sinnvoll sein, wenn das gültige Zertifikat bereits darauf wartet, bei der nächsten Verbindung vom Server abgerufen zu werden, der Agent Updater aber eben durch dieses fehlende Zertifikat „ausgesperrt“ ist. Achtung: Die Prüfung des Zertifikates wird hierdurch tatsächlich für diesen Aufruf komplett deaktiviert. Die Kommunikation findet dennoch verschlüsselt statt – dementsprechend ist der Einsatz dieses Arguments „besser als nichts“.

Verbindung von Remote-Instanz zu Zentralinstanz

Einfacher gestaltet sich die Verteilung der Zertifikate bei der Verbindung von der Remote- zur Zentralinstanz, da hier das Setup gar nicht verlassen wird. Die Remote-Instanz kann sich aus dem Checkmk eigenen Certificate Store unter Global settings > Site management > Trusted certificate authorities for SSL bedienen. Es reicht also, das Zertifikat bzw. die Zertifikate über die Zentralinstanz zu importieren, ggf. auch über Site specific global settings, falls die Zentralinstanz unter verschiedenen URLs erreichbar ist.

Vorgehen beim Austausch eines Zertifikats

Wenn Sie mit einer eigenen Zertifizierungsinfrastruktur arbeiten, verwenden Sie im Idealfall ein sehr lange gültiges Root-Zertifikat, mit dessen zugehörigem Schlüssel regelmäßig Intermediate-Zertifikate erstellt werden. Diese werden dann wiederum zum Signieren der Server-Zertifikate verwendet. In diesem Fall rollen Sie Intermediate-Zertifikate als Zertifikatskette (Certificate Chain) auf dem Checkmk-Server aus. Den Hosts, die automatische Agenten-Updates erhalten, muss nun lediglich das Root-Zertifikat bekannt gemacht werden.

Sind Sie unsicher, ob ein neues Server-Zertifikat ein neues Root-Zertifikat erfordert, verwenden Sie den folgenden Befehl. Mit ihm ermitteln Sie den Identifier des Root Keys, mit dem ein Server-Zertifikat signiert wurde:

root@linux# openssl x509 -noout -text -in cert.pem | grep -A1 'X509v3 Authority Key'
            X509v3 Authority Key Identifier:
                14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

Ist der angezeigte Identifier beim alten und neuen Zertifikat identisch, sind keine weiteren Maßnahmen erforderlich. Hosts, die diesem Root-Zertifikat vertrauen, können auch bei Änderungen der Zertifikatskette weiter Updates beziehen – sofern die Kette korrekt im System-Apache hinterlegt wurde.

Wurde bislang ein selbst signiertes Zertifikat oder ein kurzlebiges Root-Zertifikat einer internen CA verwendet oder wurde der bisherige Root-Schlüssel einer Ihrer internen CAs kompromittiert, ist beim Austausch wie folgt vorzugehen:

  1. Fügen Sie das neue Zertifikat über den Parameter Certificates for HTTPS verification (in der Regel Agent updater (Linux, Windows, Solaris)) hinzu.

  2. Backen Sie die Agentenpakete neu und führen Sie ein Update aller Hosts im Monitoring durch. Stellen Sie sicher, dass dieses Update für alle Hosts durchlaufen wurde, bevor Sie fortfahren.

  3. Tauschen Sie nun das Serverzertifikat aus.

  4. Testen Sie mit wenigen Hosts, bei denen bei Fehlschlag eine manuelle Neuinstallation des Agents leicht durchführbar ist, ob ein weiteres Update über das neue Zertifikat möglich ist.

  5. Konnte der letzte Schritt erfolgreich durchgeführt werden, können (das Zertifikat läuft ab) oder müssen (der Schlüssel wurde kompromittiert) Sie das alte Zertifikat entfernen und ein erneutes Agentenupdate durchführen.

7. Fehlerbehebung

7.1. Typische Fehler und ihre Ursachen

Bereits behobene Fehler im Service Checkmk Agent

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

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 der Deinstallation weiterhin auf dem Host, damit die Registrierungsinformationen nicht verloren gehen. 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.

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

Auf der Seite Monitor > System > 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.

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, Solaris) 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. Welches 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 Ausschnitt gezeigt und gekürzte Stellen mit [...] 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 -text -noout -in 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 Aussteller (Issuer) und der Gegenstand (Subject) identisch sind und die option CA:TRUE enthalten ist. Zusätzlich muss die Kette der Aussteller, welche einen Gegenstand beglaubigen, bis zu dem letzten Eintrag konsistent sein. Sie benötigen also auch alle Zwischenzertifikate, wenn der Aussteller des letzten kein CA sein sollte.

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 anpasst, um die Programme zu beschleunigen. Das Agent-Updater-Plugin wird aber mit dem Programm PyInstaller paketiert, dessen Pakete 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 den 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

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 zu beheben, können Sie entweder das Flag entfernen, oder — weil Sie das Flag bewusst gesetzt haben und benötigen — auf dem Checkmk-Server im Setup eine Regel unter Agents > Windows, Linux, Solaris, AIX > Agents > Agent 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.

RPM-Installation schlägt auf RedHat/CentOS fehl

Es ist vereinzelt aufgetreten — insbesondere auf RedHat/CentOS-Systemen — dass der vom automatischen Update ausgelöste Aufruf von rpm wiederholt fehlschlägt, während ein manueller Aufruf von cmk-update-agent erfolgreich durchläuft. Die Ursache lag in diesen Fällen in einer SELinux-Policy, die einen fehlerfreien Aufruf verhindert hat, wenn rpm von einem Kindprozess von xinetd aufgerufen wurde. Sie können dem Problem z.B. durch Analyse von SELinux-Logs auf den Grund gehen und ggf. die Policy mithilfe des Tools audit2allow entsprechend anpassen.

8. Dateien und Verzeichnisse

8.1. Pfade auf dem Checkmk-Server

Pfad Bedeutung

~/var/check_mk/agents/

Enthält die gebackenen Agenten, geordnet zuerst in Unterverzeichnissen nach Betriebssystemen (z.B. linux_rpm) und darunter nach Hosts per Soft-Link.

~/var/check_mk/agent_deployment/

Enthält Dateien mit den Namen der registrierten Hosts. Eine solche Datei enthält den Zeitpunkt der letzten Registrierung und das Host Secret.

8.2. Pfade auf dem überwachten Linux-/Unix-Host

Pfad Bedeutung

/usr/lib/check_mk_agent/plugins/3600/cmk-update-agent

Das Agent-Updater-Plugin als Binärdatei oder Skript, abhängig von der Konfiguration als ausführbares Format. Das Unterverzeichnis 3600 steht dabei für das Intervall für den Update-Check in Sekunden (hier für den Standardwert von einer Stunde).

/usr/bin/cmk-update-agent

Skript zum Aufruf des Agent-Updater-Plugins und zur Registrierung des Agenten mit dem Kommando cmk-update-agent register

/etc/check_mk/cmk-update-agent.cfg

Konfigurationsdatei des Agent-Updater-Plugins, die die Einstellungen der Regel Agent updater (Linux, Windows, Solaris) enthält. Editieren Sie diese Datei nicht, denn Sie wird bei der Installation und beim Update geschrieben.

/etc/cmk-update-agent.state

Datei mit Registrierungsinformationen inklusive des Host Secrets

/var/lib/check_mk_agent/cmk-update-agent.log

Ausführliche Log-Datei mit DEBUG-Meldungen

8.3. Pfade auf dem überwachten Windows-Host

Pfad Bedeutung

C:\ProgramData\checkmk\agent\plugins\cmk_update_agent.checkmk.py

Das Agent-Updater-Plugin als Python-Datei

C:\Program Files (x86)\checkmk\service\check_mk_agent.exe

Agentenprogramm zur Registrierung des Agenten mit dem Kommando check_mk_agent.exe updater register

C:\ProgramData\checkmk\agent\config\cmk-update-agent.cfg

Konfigurationsdatei des Agent-Updater-Plugins

C:\ProgramData\checkmk\agent\config\cmk-update-agent.state

Datei mit Registrierungsinformationen inklusive des Host Secrets

C:\ProgramData\checkmk\agent\log\cmk-update-agent.log

Ausführliche Log-Datei mit DEBUG-Meldungen

C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.yml

Von der Agentenbäckerei erstellte Konfigurationsdatei, die u.a. das Intervall für den Update-Check definiert.

Auf dieser Seite