Automatische Agenten-Updates

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.

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.

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.

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.

Diese Regeleinstellung ist ebenfalls optional. Der Agent Updater geht zunächst davon aus, dass auch bei konfigurierten Proxy-Einstellungen auf dem Ziel-Host 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 Umgebungsvariablen des Hosts.

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:

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

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

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:

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.

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:

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:

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:

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

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.

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.

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:

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 – Zertifikat importieren: Sie können den Agent Updater auch mit dem Kommandozeilenargument --trust-cert aufrufen. Dadurch wird das Serverzertifikat abgerufen und importiert. Dies erfolgt ohne Berücksichtigung der Art des Zertifikats: Dem Zertifikat wird ohne weitere Prüfung einer möglichen Kette vertraut – egal, ob es sich um ein selbst signiertes Zertifikat handelt, ein Zertifikat am Ende einer öffentlichen Zertifikatskette oder ein Zertifikat, das mit einer internen CA signiert wurde.

Zertifikat via Kommandozeile – Zertifikat ignorieren: 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.

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.

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:

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:

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.

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.

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.

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:

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:

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.

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:

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.

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.

Wenn der Service Check_MK Agent die Warnung No valid signature found anzeigt, bedeutet das, dass das Agenten-Paket, welches in der Agentenbäckerei für den Host vorgesehen ist, nicht mit einem der akzeptierten Schlüssel signiert wurde.

Im einfachsten Fall genügt es, wenn Sie Ihre Agenten mit Hilfe der Funktion Sign agents in der Agentenbäckerei mit einem der Schüssel signieren, die unter Signature keys the agent will accept angezeigt werden.

Sobald der Agent Updater des betroffenen Hosts sich das nächste mal beim Checkmk-Server gemeldet hat und anschließend das Cache-Intervall des Service abgelaufen ist, wird die Warnung verschwinden.

Falls der Host allerdings keinen einzigen Signaturschlüssel (mehr) kennt, der auf dem Checkmk-Server liegt, müssen Sie das Backen und signieren mit einem unter Signature keys the agent will accept angezeigten Schlüssel wiederholen, den gebackenen Agenten im Anschluss auf den betroffenen Host kopieren und dort neu installieren.

Auf einem betroffenen Host können Sie cmk-update-agent -v bzw. check_mk_agent.exe updater -v ausführen, um weitere Details zu diesem Fehler zu erhalten. In der detaillierten Fehlermeldung werden explizit die Signaturen aus der Konfigurationsdatei des Agent-Updater-Plugins angegeben, die kein akzeptiertes (sprich: konfiguriertes) Gegenstück auf Ihrem Checkmk-Server haben.