Agent installation auf SLES15

Hallo zusammen,

wir haben in unserer Umgebung neue SLES15 Maschinen aufgesetzt und wollten dort jetzt
den Check_MK Agent (1.5.0p21) installieren.
Allerdings fehlt ab SLES15 das “xinetd” ja komplett.

Kann uns wer verraten, wie genau man den Agent dort erfolgreich einstellt?
Habe nur den folgenden Post gefunden, der mir allerdings nicht aussagend genug ist:

Gibt es keine Möglichkeit, mit den vorhandenen Settings (von SLES15) den Agenten zum laufen zu bringen?

Danke im voraus
~Kruzgoth

Hallo,
an stelle von xinetd wird systemd benutzt. Die Konfigurationsdateien liefert CMK mit. Sind über die Weboberfläche erreichbar: Monitoring Agents -> Agent files -> Linux Agent - Example configuration using with systemd.

Karl

2 Likes

Hallo Karl,

danke für den Hinweis, dass hilft schon mal weiter. Ich schätze, hier muss man aber dann die Konfigurationsdateien manuell via “Deploy custom files with agent” verteilen, da es dafür keine Regel gibt.
Vielleicht baue ich mir hierfür eine eigene Regel, sofern es nicht anders geht.

Bitte beachten, daß bei dieser Beispiel-Konfiguration die Agentdaten frei zugänglich sind. Ab systemd 235 kann man die IP-Adresse in der Socketunit wie folgt beschränken:

    IPAddressDeny=any
    IPAddressAllow=11.12.13.14

Ich bekomme beim Versuch den Agent zu starten immer den Fehler:

Feb 10 13:29:24 localhost systemd[1]: check-mk-agent.service: Got no socket.
Feb 10 13:29:24 localhost systemd[1]: check-mk-agent.service: Failed to run 'start' task: Invalid argument
Feb 10 13:29:24 localhost systemd[1]: Failed to start Check_MK Agent.
-- Subject: Unit check-mk-agent.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit check-mk-agent.service has failed.
--
-- The result is failed.
Feb 10 13:29:24 localhost systemd[1]: check-mk-agent.service: Failed with result 'resources'.

Kann mir wer sagen, was genau hier falsch ist? Habe 1:1 die Default-Konfig von Check_MK genutzt.
Es sieht so aus, als ob er den Socket nicht bekommt, starte ich den Socket separat, lauscht er auf dem Port 6556, sobald ich aber ein Telnet gegen den Port mache, bricht dieser wieder zusammen.

Also:
-> Port starten -> OK
-> Port starten, danach Service starten -> Fehler
-> Service starten -> Fehler
-> Port starten, telnet -> Connection refused, Port crash
-> Agent lokal ausführen -> OK

Meines Erachtens mußt du nur den Socket starten. Bei mir sehen die Units wie folgt aus:

~  # systemctl cat check_mk.socket
# /etc/systemd/system/check_mk.socket
# systemd socket definition file
[Unit]
Description=Check_MK Agent Socket

[Socket]
ListenStream=6556
Accept=true

[Install]
WantedBy=sockets.target

# /etc/systemd/system/check_mk.socket.d/10-ipacl.conf
[Socket]
IPAddressDeny=any
IPAddressAllow=11.22.33.44

~ # systemctl cat check_mk@.service
# /etc/systemd/system/check_mk@.service
# systemd service definition file
[Unit]
Description=Check_MK

[Service]
ExecStart=/usr/bin/check_mk_agent
Type=forking

User=root
Group=root

Ja, weiß ich das man das “theoretisch” nur so machen muss, aber es klappt nun mal leider nicht.
Wenn ich das einstelle, wie bei dir, bekomme ich nur 2 Fehlermeldungen mehr:

Feb 10 13:08:52 localhost systemd[1]: check-mk-agent.service: Failed with result 'resources'.
Feb 10 13:08:58 localhost systemd[1]: Reloading.
Feb 10 13:08:58 localhost systemd[1]: /etc/systemd/system/check-mk-agent.socket.d/10-ipacl.conf:2: Unknown lvalue 'IPAddressDeny' in section 'Socket'
Feb 10 13:08:58 localhost systemd[1]: /etc/systemd/system/check-mk-agent.socket.d/10-ipacl.conf:3: Unknown lvalue 'IPAddressAllow' in section 'Socket'
Feb 10 13:09:00 localhost systemd[1]: check-mk-agent.service: Got no socket.
Feb 10 13:09:00 localhost  systemd[1]: Failed to start Check_MK.

Also erstmal ist dein systemd zu alt für IPAdress, das müßtest du dann über die Firewall regeln.
Was ist der Output von “systemctl status check_mk.socket” ?

Das irgendwas mit unserem systemd war, hatte wir uns schon gedacht.
Hier die gewünschte Ausgabe, inklusive “check-mk-agent.service”

localhost :/usr/lib/systemd/system # systemctl status check-mk-agent.*
● check-mk-agent.service - Check_MK Agent
   Loaded: loaded (/usr/lib/systemd/system/check-mk-agent.service; enabled; vendor preset: disabled)
   Active: failed (Result: resources) since Mon 2020-02-10 09:21:42 CET; 5h 0min ago
 Main PID: 6770 (code=exited, status=0/SUCCESS)

Feb 10 13:58:24 localhost systemd[1]: Failed to start Check_MK Agent.
Feb 10 13:58:24 localhost systemd[1]: check-mk-agent.service: Failed with result 'resources'.
Feb 10 13:58:55 localhost systemd[1]: check-mk-agent.service: Got no socket.
Feb 10 13:58:55 localhost systemd[1]: check-mk-agent.service: Failed to run 'start' task: Invalid argument
Feb 10 13:58:55 localhost systemd[1]: Failed to start Check_MK Agent.
Feb 10 13:58:55 localhost systemd[1]: check-mk-agent.service: Failed with result 'resources'.
Feb 10 14:00:48 localhost systemd[1]: check-mk-agent.service: Got no socket.
Feb 10 14:00:48 localhost systemd[1]: check-mk-agent.service: Failed to run 'start' task: Invalid argument
Feb 10 14:00:48 localhost systemd[1]: Failed to start Check_MK Agent.
Feb 10 14:00:48 localhost systemd[1]: check-mk-agent.service: Failed with result 'resources'.

● check-mk-agent.socket - Check_MK Agent Socket
   Loaded: loaded (/usr/lib/systemd/system/check-mk-agent.socket; enabled; vendor preset: disabled)
   Active: active (listening) since Mon 2020-02-10 14:07:04 CET; 14min ago
   Listen: 0.0.0.0:6556 (Stream)
 Accepted: 10; Connected: 0

Feb 10 14:07:04 localhost systemd[1]: Listening on Check_MK Agent Socket.

Es scheint zudem, als ob das “systemctl”, bzw. halt systemd, hier die Probleme hat, den “service” mit dem “socket” zu verbinden.
Ich komme auf die Idee, da wir den Socket separat problemlos starten können und dieser auch läuft, bis zu dem moment, wo ein Anfrage auf dem Port 6556 rein kommt. Dann bricht der Socket zusammen, weil kein Service dahinter steht (verständlich).
Sofern man allerdings versucht den Service zu starten, meckert er immer rum, er hätte keinen Sockel gefunden. Also so, als ob die sich gegenseitig nicht sehen.

Die Unit für den Service ist falsch … die Unitdatei müßte check-mk-agent@.service heißen.

Wie die Unit ist falsch? Heißt dass, dass die “service”-Datei “check-mk-agent@.service” heißen muss
oder wo muss ich das eintragen? Weil, dass ändert rein gar nichts am Problem, wenn ich die Datei umbenenne, abgesehen davon dass ich Sie dann auch mit “systemctl status check-mk-agent@.service” ansprechen muss

EDIT:
Im Gegenteil sogar. Ich bekomme nur mehr Probleme durch deine Ratschläge bisher =(
Failed to get properties: Unit name check-mk-agent@.service is neither a valid invocation ID nor unit name

Nochmal zum Protokoll für alle, so sehen meine beiden “check-mk-agent.service” und “check-mk-agent.socket” Dateiinhalte aus:

# systemd service definition file
[Unit]
Description=Check_MK Agent

[Service]
ExecStart=/usr/bin/check_mk_agent
KillMode=process

User=root
Group=root

StandardInput=socket

# systemd socket definition file
[Unit]
Description=Check_MK Agent Socket

[Socket]
ListenStream=0.0.0.0:6556
Accept=yes

[Install]
WantedBy=sockets.target

Für Services, die von Sockets gestartet werden benötigst du Unit Template Dateien. Darum “check-mk-agent@.service” und deshalb auch die Fehlermeldung wenn du “systemctl status check-mk-agent@.service” aufrufst.

1 Like

Könnte ich dich um genauere Hinweise bitten. Ich weiß nicht, was du mir damit sagen möchtest.
Ein Beispiel wäre nett :slight_smile:

Weil wie gesagt, egal wie ich die Hinweise umsetze, es kommen nur mehr Fehler raus :slight_smile:
also nett wäre ein kompletter Stand von funktionierenden Dateien unter einem neuen SLES15.

Solution EDIT:
Ich weiß nicht warum, aber der Kollege hat jetzt den Service umgeändert auf “@.service” und die Fehlermeldung ignoriert. Jetzt läuft nur der socket, aber es klappt.
Dieses “check_mk@.service” wirft also nur Fehler und macht nichts, funktioniert aber in Verbindung mit dem “check_mk.socket”. Ich bin verwirrt, aber es klappt. Also danke.

Geht eigentlich ganz einfach. Du installierst das check-mk-agent RPM von deiner check_mk Instanz (WATO / Monitoring Agents). Dann xinetd deaktivieren und den Socket starten:

systemctl disable xinetd
systemctl stop xinetd
systemctl enable check_mk.socket
systemctl start check_mk.socket

Deine existierende Dateien bitte vorher entfernen.