I’m in the process of updating my servers to 2.1 agent.
After reading the warning message The agent controller is operating in an insecure mode I started to read the docs on what should be done. I think the docs aren’t clear on what should be done if ss -tulpn | grep 6556 shows that systemd or xinetd are listening on 6556 instead of cmk-agent-ctl, and what one should do to have cmk-agent-ctl working.
If however systemd , xinetd or inetd are within the parentheses the prerequisites for using the Agent Controller are not met. In such a case, also complete the setup as described in the article Monitor Linux in legacy mode.
This is not clear. What are the prerequisites? I can read only systemd 220, but I have 245 (Ubuntu 20) or 237 (Ubuntu 18) but they both are still using systemd.
Also the legacy article is not helpful and it doesn’t say anything about how to get out of the legacy mode.
manually removed some leftovers rm -r /var/lib/cmk-agent rm -r /var/lib/check_mk_agent
systemctl | grep check still showed two services, system-check_mk.slice (loaded active) and check_mk.socket (failed failed)
so I stopped and disabled them, then did systemctl daemon-reload and systemctl reset-failed
Then I installed the 2.1.0p1-1 agent again.
After that, there are 3 active services in systemd, but ss -tulpn | grep 6556 returns nothing
This left me quite displaced and worried that it’s still too early to use this version in production, I was already thinking how to restore the 2.0 backup, but first I tried to register the agent anyway, after some debugging and 500 errors (the docs don’t say anything about what permissions are required, found out in another thread I need “Write access to all hosts and folders”) the agent got registered, and now the ss -tulpn command returns: users:((“cmk-agent-ctl”,pid=17311,fd=9))
Which is in contrast with what I was told (my machine doesn’t have the requirements to run it)
So I was already happy that I did it, but… apparently it doesn’t work.
now I got
Agent controller not registeredCRIT , Got no information from hostCRIT
cmk-agent-ctl status output:
Version: 2.1.0p1
Agent socket: operational
IP allowlist: any
Connection: HOST:8000/mk
UUID: ***
Local:
Connection type: pull-agent
Certificate issuer: Site 'mk' local CA
Certificate validity: Sun, 05 Jun 2022 07:55:11 +0000 - Fri, 06 Oct 3020 07:55:11 +0000
Remote:
Connection type: pull-agent
Registration state: operational
Host name: HOST
and if I do a telnet on port 6556, the only answer I get is 16
16 means the agent controller already enforces TLS. So, now run the cmk-agent-ctl register subcommand to register with your site. Then do a connection test and everything will be fine.
Thank you for your answer. Unfortunately I already did the cmk-agent-ctl register, and cmk-agent-ctl status says “operational”, but it can’t be read from the connection test:
Also, the register command exits with no output, I don’t know if it’s supposed to print a success message after I say Yes:
Yes, I get them, you can see the output above in the first answer.
Also the agent that is running on the cmk server to monitor itself, it’s running in legacy mode with xinetd, but I get “Host is registered for TLS but not using it” and no data is sent…
should I open another thread in the troubleshooting section?
After updating to 2.1.0p2 it shows the reason:
Request failed with code 401 Unauthorized: You do not have read access to the host […]
so I gave more permissions until the error disappeared, I tried with admin details as well, registration seems successful but on the server I get “agent is not registered”… so weird
if it’s of any help to anyone else, I had similar issues, tried multiple times to purge and reinstall, the only thing that seemed to help for me was install the client that I wanted, then go into /var/lib/cmk-agent, remove the .gz file there, then use the ‘setup’ script in /var/lib/cmk-agent/scripts/super-server with various iterations of purge, depoy, and trigger flags.
not exactly greatly useful info, but I found a ton of threads similar to this, but nothing that was very useful for getting a resolution.
I got the similar problem and after two hours of fighting with this thing I’ve figured out the problem is two conflicting services, both running on port 6556.
The setup script does detect that only one is needed but… I was upgrading from 2.0 agent and I didn’t disable check_mk.socket prior to upgrade and was left with two conflicting systemd units trying to access port 6556. And the 2.0 socket “won”.
I bet the fix here is to disable check_mk.socket before the upgrade. And setup should check this in the first place.
In my case I had to create agent configuration to allow for my server to actually get the node information. The config file is in /var/lib/cmk-agent/cmk-agent-ctl.toml:
Pull port definition is optional – it’s a leftover from me trying to get the agent running on a different port. But allowed_ip is crucial – without this I was getting nothing instead of agent output adding whole layer of confusion to this excruciatingly painful upgrade process. But I guess when this config is missing there’s no ACL and you’ll get the report as usual, on port 6556.
