Checkmk
to checkmk.com

In diesem Artikel wird noch nicht die grafische Benutzeroberfläche der Checkmk Version 2.0.0 gezeigt und beschrieben. Wir werden diesen Artikel so schnell wie möglich aktualisieren.

CEE 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

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. Bitte vergessen Sie nicht, dass Sie für jeden diesen 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 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

agent deployment agent updater empty

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. einmal 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 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 (Help > Show inline help) weitere Informationen zu jedem einzelnen Punkt, sobald Sie diesen aktivieren.

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

Aktivierung

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.

Update server information

Optional lassen sich hier bereits zur Konfiguration Daten für die Verbindung des Agent Updaters zum Checkmk-Server angeben. Wird dieser Eintrag nicht konfiguriert, müssen die Informationen später beim Registrieren des Agent Updaters angegeben werden.

Usage

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

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 des Namen des Checkmk-Servers übereinstimmt, wie der dem Host bekannt ist

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

Wenn Sie - wie von uns empfohlen - HTTPS verwenden, müssen Sie sicherstellen, dass dem Agent Updater auch ein CA-Zertifikat 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.

Verschlüsselte Kommunikation für Updates

Hier konfigurierte CA- oder selbstsignierte 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 Updates

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 sehr stark belastet wird, falls Sie sehr viele Checkmk-Agenten haben. Wenn Sie hier nichts einstellen, so gilt ein Defaultwert von 60 Minuten.

Proxy-Einstellungen

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.

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 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: Für Windows wird das Plugin immer als 32bit-Executable ausgeliefert. Diese Regel wird dementsprechend standardmäßig ignoriert. Hinweis: Etwaig vorhandene 64bit-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 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

Signaturschlüssel

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.

Nach dieser letzten Einstellung könnte Ihre Regel wie im folgenden Screenshot aussehen. Speichern Sie alle Ihre Angaben durch einen Klick auf context button save 1px border.

agent deployment agent updater

1.3. Agenten backen

Als nächstes können Sie bereits die so konfigurierten Agenten backen. Navigieren Sie dazu wieder nach Setup > Agents > Windows, Linux, Solaris AIX und klicken Sie dann auf Bake agents. 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:

agent deployment agent baking successful

1.4. Agenten signieren

Als nächstes signieren Sie die Agenten mit dem in Schritt 1.1 erstellten Schlüssel. Klicken Sie dafür auf Sign agents, wählen Sie den gewünschten Schlüssel aus, geben Sie die zum Schlüssel passende Passphrase ein und klicken Sie auf Sign. Alle so signierten Agenten werden dem einem einem entsprechenden Symbol icon signature key gekennzeichnet. Wenn Sie mehrere Schlüssel angelegt haben, signieren Sie mit jedem Schlüssel 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.

Jedes Mal, wenn Sie später die Agentenpakete aktualisieren und neu backen, wird die Signatur 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 unter Setup > Agents > Windows, Linux, Solaris, AIX das für den Host passende icon agents 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). Den Agent-Updater bzw. das Plugin finden Sie nun - abhängig vom Betriebssystem des Hosts - in den folgenden Verzeichnissen:

  • Unter unixoiden Systemen im Pfad /var/lib/check_mk_agent/plugins/[konfiguriertes Intervall]/ (Ein gleichnamiges Skript wird auch unter /usr/bin abgelegt, daher steht cmk-update-agent auch als Kommando zur Verfügung.)

  • Unter Windows: Der Agent-Updater ist in den Windows Agenten integriert. Sie finden diesen in C:\Program Files (x86)\checkmk\service\. 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 einem Prompt mit Administratorrechten geschehen. Geben Sie dann der Reihe nach die erforderlichen Angaben ein. Wenn Sie bisher dieser Anleitung von Beginn an gefolgt sind und einen gebackenen Agenten installiert haben, werden nicht alle der folgenden Einstellungen abgefragt. Diese sind hier nur zu Referenzzwecken angegeben.

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

root@linux# cmk-update-agent register -v
-------------------------------------------------------------------
|                                                                   |
|  Check_MK Agent Updater v2.0.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 an administration account on WATO for     |
|  that server.                                                     |
|                                                                   |
-------------------------------------------------------------------
Deployment server to connect to:
mymonitoring.example.intern

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

Check_MK 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 of host "myserver" 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 mymonitoring.example.intern -i heute -H myserver -p https -U cmkadmin -P * -v

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

cd "\Program Files (x86)\checkmk\service"
check_mk_agent.exe updater register -s mymonitoring.example.intern -i mysite -H myhost -p https -U cmkadmin -P cmk -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 Checkmk-Administrator ist nur einmal erforderlich. Agent und Server vereinbaren bei der Registrierung einen geheimen Schlüssel, 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 cmk-update-agent.state gespeichert 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 icon edit beim Master Switch. Die Tabelle Prerequisites sollte nun so aussehen:

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 natürlich auch 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 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:

agent deployment host selection

Nachdem Sie hier Bedingungen für die Auswahl von Hosts getroffen haben, können Sie in dem Feld Test with this 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.

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 auf der Seite Automatic agent updates

agent deployment update status

Diese Übersicht zeigt, wie sich die einzelnen Hosts im Agenten-Update verhalten. Die Onlinehilfe (Help > Show inline help) 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 > Analyze > 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 runtergeladen 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 Check_MK 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 Monitoring-Daten aus. Die Serviceerkennung erzeugt daraus einen neuen Service bei dem Host mit dem Namen Check_MK 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.

agent deployment agent check

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: 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 Zielhost 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 eventuellen 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
Jul 02 13:59:23 klappgrill [cmk-update-agent] WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
Jul 02 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
2020-07-02 17:58:18,321 DEBUG: Starting Check_MK Agent Updater v1.6.0p11
2020-07-02 17:58:18,322 DEBUG: Successfully read /etc/cmk-update-agent.state.
2020-07-02 17:58:18,322 DEBUG: Successfully read /etc/check_mk/cmk-update-agent.cfg.
[...]
2020-07-02 17:58:18,387 INFO: Target state (from deployment server):
2020-07-02 17:58:18,387 INFO:   Agent Available:     True
2020-07-02 17:58:18,387 INFO:   Signatures:          1
2020-07-02 17:58:18,387 INFO:   Target Hash:         081b6bcc6102d94a
2020-07-02 17:58:18,387 INFO: Ignoring signature #1 for certificate: certificate is unknown.
2020-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.

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) 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 dem 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 Monitoringinstanz 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 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 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 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 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 Sites zu verteilen. Voraussetzung dafür ist ein Setup mit zentraler Konfiguration und die Möglichkeit, dass die Central Site von den Remote Sites aus per HTTP/HTTPS erreicht werden können.

5.1. Funktionsweise

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

Anders als im Single-Site-Setup ergibt sich der passende Updateserver für die Hosts nicht ausschließlich aus dem Regelwerk des Agent Updaters, sondern wird dem anfragenden Agent Updater von der kontaktierten Checkmk-Site mitgeteilt. Dabei wird einem Host der Server zugeteilt, von dessen Site 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) Site 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 Sites muss nicht separat aktiviert werden - die jeweilige Remote Site erkennt die Situation automatisch und kommuniziert dementsprechend mit der Central Site sowie dem anfragenden Agent Updater. Sollen sich die Agenten für Updates explizit nur an der Central Site melden, ist dies über einen fest eingestellten Updateserver im Regelwerk des Agent Updaters.

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

Connection to central agent bakery

An dieser Stelle muss die URL angegeben werden, unter der die Central Site von der Remote Site aus erreichbar ist, inklusive Protokoll und check_mk, also z.B. myserver.org/mysite/check_mk. Während die Checkmk-Site 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 Site für die Verifikation der Verbindung automatisch die im Setup zur Verfügung stehenden CA- oder selbstsignierte Zertifikate (Setup > General > Global Settings > Site management > Trusted certificate authorities for SSL). Die Remote Site benötigt zusätzlich einen zuvor angelegten Automation-User, um sich an der Central Site anmelden zu können. Dieser kann hier ebenfalls ausgewählt werden. Wird keiner angegeben, sucht die Remote Site nach einem Automation-User mit dem Namen Automation.

Connection to remote agent bakery

Da die Remote Sites von den jeweils überwachten Hosts aus nicht notwendigerweise über die gleiche URL erreichbar sind, wie von der Central Site 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-Site mitgeteilt. Hier macht die Konfiguration als Site specific Global Setting besonders Sinn. Wird keine URL angegeben, wird angenommen, dass die Remote Sites von der Central Site 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. An dieser Stelle wird noch einmal zentral zusammengetragen, was alles für eine vollständige Absicherung über HTTPS getan werden muss. Sowohl die Verbindung von Remote Site zu Central Site und von Host zu Checkmk-Site (unabhängig davon, ob es sich dabei um ein Single-Site-Setup oder ein verteiltes Setup handelt) können und sollten per TLS abgesichert werden, d.h. über HTTPS erfolgen.

6.1. HTTPS verwenden

Um eine Checkmk-Instanz per HTTPS anprechen zu können, muss zunächst einmal der Monitoringserver auch für HTTPS konfiguriert sein. Dies kann z.B. über eine geeignete Konfiguration des System-Apaches 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 auch dementsprechend über das HTTPS-Protokoll und über den Port 443 angesprochen. Das gilt natürlich ebenso im Falle des explizit angegebenen Protokolls, wenn es sich beim kontaktierten Server um den aus der Agent Updater Konfiguration Update Server Information handelt.

6.2. Zertifikate bereitstellen

Damit eine HTTPS-Verbindung zustande kommen kann, muss die Zertifikatskette oder das selbstsignierte Zertifikat (je nachdem, wie der Server konfiguriert ist) des kontaktierten Servers verifiziert werden können, was durch die Bereitstellung von geeigneten CA- oder selbstsignierten Zertifikaten ermöglicht wird. Dies kann folgendermaßen realisiert werden:

Verbindung von Host zu Checkmk-Server

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

Handelt es sich beim HTTPS-Setup des Servers um eine Zertifikatskette, die mit einer öffentlichen CA (Certification Authority) wie z.B. Let‘s Encrypt signiert wurde, kann diese wahrscheinlich ohne weitere Konfiguration verifiziert werden, da der Agent Updater hierfür auf einen eigenen Certification Store zugreifen kann. Dieses Konzept hat jedoch seine Schwächen, denn dieser Store kann immer nur höchstens so aktuell wie die eingesetzte Software sein; sehr neue CAs oder kürzlich zurückgerufene CAs können oft nicht berücksichtigt weden. Daher wird der interne CA-Store ignoriert, sobald ein oder mehrere Zertifikate über eine der folgenden Mechanismen importiert wurden. Zertifikate aus den folgenden drei Quellen werden lokal auf dem Host gespeichert und bilden einen eigenen Certification Store:

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

Bei der Konfiguration der Verbindung zur Remote Site über Setup > General > Global Setting > Automatic Agent Updates > Connection to remote agent bakery lassen sich Zertifikate angeben, die dem Agent Updater bei der Verbindung übergeben werden und mit denen die HTTPS-Verbindung zur jeweiligen Remote-Site verifiziert werden kann. Dies ist insbesondere sinnvoll, wenn zur Konfigurationszeit noch nicht klar ist, welcher Host welcher Site zugeteilt ist. Auch lässt sich mit dieser Import-Möglichkeit die Anzahl der zu backenden Agenten reduzieren, da die richtigen Zertifikate für die jeweiligen Updateserver nicht Host-spezifisch konfiguriert werden müssen.

Der Agent Updater lässt sich mit dem Kommandozeilenargument --trust-cert aufrufen. Dadurch wird versucht, ein CA- oder selbstsigniertes Zertifikat vom Server abzurufen und dieses zu importieren. Dies funktioniert leider nur, wenn entweder ein selbstsigniertes Zertifikat eingesetzt wird (Da es sich hierbei bereits um das Serverzertifikat handelt) oder wenn das CA-Zertifikat auf dem Server hinterlegt ist, d.h. sich am Ende der Zertifikatskette befindet. Letzteres ist für eine gültige Zertifikatskette im Allgemeinen nicht gefordert und daher leider oft 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 HTTPS-Verifikation durch das Kommandozeilenargument --insecure für einen Aufruf umgangen werden. Dies kann sinnvoll sein, wenn das gültige Zertifikat nur 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 HTTPS-Verifikation wird hierdurch tatsächlich komplett deaktiviert. Die Kommunikation findet dennoch verschlüsselt statt – dementsprechend ist der Einsatz dieses Arguments „besser als nichts“.

Verbindung von Remote Site zu Central Site

Einfacher gestaltet sich die Verteilung der Zertifikate bei der Verbindung von der Remote Site zur Central Site, da hier gewissermaßen die WATO-Welt gar nicht verlassen wird. Die Remote Site kann sich daher aus dem WATO-internen Certification Store unter Global Settings > Site Management > Trusted certificate authorities for SSL bedienen. Es reicht also, das oder die Zertifikate über die Central Site zu importieren, ggf. auch über Site specific Global Settings, falls die Central Site unter verschiedenen URLs erreichbar ist.

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

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

Auf der Seite Monitor > Analyze > 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) 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 […​] 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 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.

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

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 mit Hilfe des Tools audit2allow entsprechend anpassen.

Auf dieser Seite