I cannot make agents working with the new “registration” feature.
Ubuntu 18.04 with systemd 237
The register command exists without giving any output after:
Do you want to establish this connection? [Y/n]
Y
and the cmk-agent-ctl status says:
Version: 2.1.0p2
Agent socket: operational
IP allowlist: any
Connection: [...]:8000/mk
UUID: b6947f24-[...]
Local:
Connection type: pull-agent
Certificate issuer: Site 'mk' local CA
Certificate validity: Wed, 08 Jun 2022 14:28:28 +0000 - Mon, 09 Oct 3020 14:28:28 +0000
Remote:
Connection type: pull-agent
Registration state: operational
Host name: [...]
But the same was happening in p1 even if there was a permission issue, after updating to p2 I saw that error and fixed it by giving more permissions until the error has disappeared, I tried with admin login as well, but it’s the same…
In my case I had the xinetd services (from the old agents) still running. I had to uninstall xinetd (removing the configuration files first) and then uninstall and reinstall the agent. Since than the connection is established, stable and TLS secured.
thanks, unfortunately I already removed xinetd time ago, replaced with systemd first and now I’m trying with the new agent… I correctly have cmk-agent-ctl listening on 6556:
even if I telnet 127.0.0.1 6556 I get the agent output. Here I cannot remove xinetd, because if I try it says it will remove check-mk-raw-2.1.0p2 and all the dependencies as well.
On the server you can remove xinetd (with check-mk) and immidate reinstall check-mk after that.
Be sure, that you have a good backup, first .
On linux hosts the agent deactivates xinetd configuration automatically, but we saw still xinetd services running which prevent the agent-service from starting.
systemctl
should list the services in “running”
cmk-agent-ctl-daemon.service loaded active running Checkmk agent controller daemon
check-mk-agent-async.service loaded active running Checkmk agent - Asynchronous background tasks
Thank you, unfortunately it didn’t work, after remove + reinstall I still have xinetd, I also spawned a new instance with Ubuntu 22, but I have xinetd installed:
on the clients, I removed xinetd with apt purge xinetd so it’s not running (systemctl | grep xine shows nothing), I have these services running:
check-mk-agent-async.service loaded active running Checkmk agent - Asynchronous background tasks
system-check\x2dmk\x2dagent.slice loaded active active system-check\x2dmk\x2dagent.slice
check-mk-agent.socket loaded active listening Local Checkmk agent socket
cmk-agent-ctl-daemon.service loaded active running Checkmk agent controller daemon
Since I’m still struggling with this issue, I have spawned a brand new server with Ubuntu 22, installed checkmk raw, switched the public IP from the old server to the new one (got hundreds of monitored servers with a firewall rule to allow 6556 to that IP only), configured apache to have SSL, then imported the backup from the old server (with omd backup + omd restore)
Then I installed the agent on the server, and registered, and this part finally worked, the server can monitor itself (even if I don’t understand why cmk-agent-ctl register --hostname 127.0.0.1 gave 404 Not Found: Host 127.0.0.1 does not exist., I had to put the public hostname).
However, all the other hosts doesn’t work, I see the same issue as before…
To recap, the issue is the following:
ss -tulpn says cmk-agent-ctl is listening on 6556
register command is successful (status says Remote: Connection type: pull-agent, Registration state: operational) but the monitoring host doesn’t get any output (no unmonitored services found, 18 vanished services)
If I do cmk-agent-ctl delete-all --enable-insecure-connections it works again but I have the annoying WARN TLS is not activated on monitored host
I think this whole TLS thing should be optional without showing any warning, since there are much simpler ways to secure the connection, like a simple firewall rule: ufw allow from 1.2.3.4 to any port 6556 proto tcpEDIT: I found I can do this in Setup>Services>Service monitoring rules>Checkmk Agent installation auditing>New rule: Checkmk Agent installation auditing
After skipping through this post I feel like you are missing some essential understanding of the feature @fmonts. Please do read our official guide on this thoroughly.
Regarding making the TLS encryption optional: It is.
However we feel it is very important to point users to this feature, as it greatly improves security of the transmitted data. Firewall rules do not replace encryption, because everyone can still read the data in transit.
Of course you could use SSH to call the agent, which in turn would provide equivalent encryption.
And as already pointed out: You can simply disable the warning. However, we do not recommend that.
Have found multiple posts describing this same Service Rule to change the CheckMK Agent Installation Auditing for the TLS Activation and change the status to OK. I’ve tried multiple times and continue to get the WARN status. If I change the value to Critical or Unknown, the status changes on the endpoint but if I change it to OK, it automatically goes to WARN.
I finally got it lol, in cmk-agent-ctl register --hostname XXX I was putting the hostname of the server, now I realized I have to put the hostname of the monitored client
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
.
