MKP installation from the shell and distributed monitoring

CMK version: 2.1.0p24
OS version: SLES 15.1, Ubuntu 22.04

Error message: n/a

Output of “cmk --debug -vvn hostname”: n/a

I usually install checkmk servers with Ansible and do the basic configuration from the shell. I use distributed monitoring with a master and approx. 10 remote sites.

If I install an MKP with the master’s GUI (and only there), it gets replicated to all remote sites. This works great.

But if I install an MKP on the master’s shell with mkp install /path/to/my.mkp then it gets installed on the master but not distributed to the remote sites. How can I do that?

I can also not enforce the replication of the MKP in the GUI. The only workaround is to pdeudo-edit the MKP (edit & save without any changes). Then the GUI shows N pending changes which I can then push to the other sites.

My question is: How can I enforce replication of MKPs from the master to all remote sites from the shell, preferably non-interactive?

(The same applies btw to the DCD configuration: if I manipulate the file ~/etc/check_mk/dcd.d/wato/connections.mk on the master and setup different settings for my remotes, then I cannot enforce replication of the same to the remotes. A “replicate settings” command would be really handy.)

I think you need to enable MKPs in Checkmk 2.1 now.

mkp enable should do the trick.

3 Likes

Thank you for the suggestion but doesn’t help. If I just do mkp install /path/to/my.mkp then it gets installed and automatically enabled. If there were any other versions already installed, they get disabled.

If I then use mkp disable and/or mkp enable to switch between versions, nothing gets pushed to the remote sites.

If I do the same in the master’s GUI it immedately shows N pending changes and when I activate them, they get pushed. But the installation of MKPs at the shell does not trigger any pending changes. Even if I run the REST-API command to activate changes, it returns with

RuntimeError: {'detail': 'Currently there are no changes to activate.',
 'status': 422,
 'title': 'The operation has failed.'}

Ah, now I understand your problem.

Yes, changes on the command line never triggered the “N pending changes” in the web interface. This is something that only the web application tracks.

Yes. That is a pity. :pensive:

That’s because you can edit the config files with any text editor.