Agent lauscht nicht an Port 6556 systemd

[privatscheiss]

Ich habe eine neue Ubuntu installation und wollte diese via Agent an den check_mk Server anbinden.
Aber der Agent horcht nicht auf TCP 6556.

root@ubuntu-data-backup:/tmp# netstat -lpn | grep 6556
root@ubuntu-data-backup:/tmp#

root@ubuntu-data-backup:/tmp# systemctl status check-mk-agent.socket
● check-mk-agent.socket - Local Checkmk agent socket
     Loaded: loaded (/lib/systemd/system/check-mk-agent.socket; enabled; vendor preset: enabled)
     Active: active (listening) since Sun 2022-03-27 19:17:22 CEST; 6s ago
   Triggers: ● check-mk-agent@0.service
     Listen: /run/check-mk-agent.socket (Stream)
   Accepted: 0; Connected: 0;
      Tasks: 0 (limit: 19069)
     Memory: 0B
     CGroup: /system.slice/check-mk-agent.socket

Mär 27 19:17:22 ubuntu-data-backup systemd[1]: Starting Local Checkmk agent socket.
Mär 27 19:17:22 ubuntu-data-backup systemd[1]: Listening on Local Checkmk agent socket.
root@ubuntu-data-backup:/tmp#

root@ubuntu-data-backup:/tmp# telnet 127.0.0.1 6556
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

root@ubuntu-data-backup:/tmp# check_mk_agent | head
<<<check_mk>>>
Version: 2.1.0b1
AgentOS: linux
Hostname: ubuntu-data-backup
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
AgentController: cmk-agent-ctl 0.1.0

kann mir einer helfen den Fehler zu finden.

Danke

[openmindz (Thomas Karatzoglou)]

Hi @privatscheiss

Eventuell ufw aktiv, oder vielleicht apparmor? Bei letzterem bin ich mir nicht sicher
wie das den Agent beeinflussen koennte. Falls ersteres aber laeuft wirst Du wahrscheinlich
den port 6556/tcp oeffnen muessen. Das geht z.B. mit ufw allow 6556/tcp. Hier auch der
offizielle Ubuntu-Wiki Eintrag zu UFW.

Thomas

[privatscheiss]

Port 6556 ist offen. Apparmor läuft nicht.

[lnxshell (Oliver)]

Ich hab leider das gleiche Problem … Grund für keinen Listener:

das xinetd config file (xinetd-service-template.cfg) wird nicht in den xinet.d folder kopiert (/etc/xinet.d/). Somit gibts auch keinen tcp port für den socket service.

Template → /etc/check_mk/xinetd-service-template.cfg

OS: Debian 11, 2.1.x beta 2

lg
Oliver

[andreas-doehler (Andreas)]

@lnxshell

das xinetd config file (xinetd-service-template.cfg) wird nicht in den xinet.d folder kopiert (/etc/xinet.d/). Somit gibts auch keinen tcp port für den socket service.

xinetd hat nix mit SystemD Socket zu tun. Wenn beides vorhanden wäre hätte man auch gleich den Anhaltspunkt wo was kaputt ist.

Bei der Socket Konfiguration sollte überprüft werden ob eine Einschränkung auf IPs gesetzt ist.

@privatscheiss ist das aus gutem Grund eine Test Installation für 2.1.0b1? Wenn würde ich auch mit der aktuellen Beta 2 das nochmal probieren.

[lnxshell (Oliver)]

Spannend - und wer sollte dann den TCP Listener für den lokalen UNIX Socket (/run/check-mk-agent.socket) machen?

cat /usr/lib/systemd/system/check-mk-agent.socket
[Unit]
Description=Local Checkmk agent socket

[Socket]
ListenStream=/run/check-mk-agent.socket
SocketUser=cmk-agent
SocketMode=0240
Accept=true

[Install]
WantedBy=sockets.target

Allerdings auch spannend - die xinetd config startet wirklich das Agent Binary direkt …

   server         = /usr/bin/check_mk_agent

Genauso wie der check-mk-agent-asnyc … nur da taucht leider kein listener auf.

[privatscheiss]

das gleiche Verhalten mit der Beta 3

[andreas-doehler (Andreas)]

@lnxshell

Spannend - und wer sollte dann den TCP Listener für den lokalen UNIX Socket (/run/check-mk-agent.socket) machen?

Der Socket wird im 2.1.0 Agent vom “cmk-agent-ctl-daemon.service” bereit gestellt.

So schaut der netstat aus mit nem laufenden Control Daemon.

tcp        0      0 0.0.0.0:6556            0.0.0.0:*               LISTEN      8765/cmk-agent-ctl

Wird der check-mk-agent.socket gestoppt so verschwindet der Socket nicht aus der netstat Ausgabe, nur der Agent meldet dann einen leeren Agent Output sowie im Log des Control Daemon findet sich eine Zeile wie diese.

cmk-agent-ctl[8765]: WARN [cmk_agent_ctl::modes::pull] 127.0.0.1:37872: Request failed. (Error collecting monitoring data.)

Das alles hier trifft natürlich nur zu wenn SystemD für den Agenten verwendet wird.
Bei Verwendung von xinetd ist wie früher zu verfahren. Einfach alle drei Services aus dem SystemD entfernen und die xinetd Config aktivieren.

[gulaschcowboy (AlexW)]

Hi zusammen,

1. das was @andreas-doehler sagt
2. Bis einschließlich b2 war es so, dass der cmk-agent-ctl NICHT am Socket lauscht, solange er nicht für die TLS Verbindung registriert ist. Das wurde erst mit b3 geändert, gilt aber nur für die erste Installation.
   Nun hast Du 2 Möglichkeiten:
3. Entweder den controller für TLS registrieren (cmk-agent-ctl register -h für die Hilfe)
   oder
4. Das alte Default-Verhalten wiederherstellen: touch /var/lib/cmk-agent/allow-legacy-pull

[lnxshell (Oliver)]

@gulaschcowboy

/var/lib/cmk-agent/allow-legacy-pull

Bingo! Ja das wars … TLS hat nämlich ein Problem (zumindest in meinem Setup, Agent dürfte nur auf CN checken und SAN´s ignorieren) - mit “legacy” gehts dann sofort!

bzw. muss man auch so ehrlich sein und:

This is the name/address at which the agent can reach your central monitoring server via HTTPS or HTTP. Note: If you are using HTTPS then this name must exactly match the common name of the server certificate.

lesen

Vielen Dank für die HIlfe!

lg
Oliver

[privatscheiss]

Das wars dankeschön!