Unable to override legacy ruleset after upgrading to Checkmk 2.4

Troubleshooting
1

CMK version: 2.4.0p4
OS version: Debian 12

Hi everyone,
I’m currently updating a customized plugin originally based on the official distribution: cisco_temperature_dom.
Until Checkmk version 2.3, everything worked fine — I was overriding the original file without any issues. Now that I’m migrating to Checkmk 2.4, I’m running into trouble with the parameter ruleset.

What I’ve done:

  • I successfully updated the check plugin itself using the new API v2, and it works correctly.
  • However, the ruleset in the official distribution is still written using the legacy format and is located here:

/omd/versions/2.4.0p4.cee/lib/python3/cmk/gui/plugins/wato/check_parameters/cisco_dom.py

The problem:

  • If I try to override it by placing my updated version in:

~/local/lib/python3/cmk/gui/plugins/wato/cisco_dom.py

it is not picked up at all.

  • If I rewrite the ruleset using the new Ruleset API and place it in:

~/local/lib/python3/cmk_addons/plugins/collection/rulesets/cisco_dom.py

Checkmk still loads the legacy version from the distribution.

  • I can only use my ruleset if I rename it, e.g. cisco_dom_custom, but in that case, I end up with two rulesets in WATO — the original one and mine.

The question:

Is there a correct way in Checkmk 2.4 to fully override a legacy ruleset (written using the old API) with a new version written using the new Ruleset API?

Right now I have a modernized check plugin, but I’m stuck with a ruleset that seems locked into the legacy system, and I can’t override it cleanly without duplicating functionality.

Thanks,
Andrea

2025: The Year in Review
2

my guess, it’s the same issue as I had with my Meraki agent,

The solution was to put a init.py file like this

OMD[cmk]:~$ cat local/lib/python3/cmk/plugins/cisco/__init__.py
#!/usr/bin/env python3

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

in each sub directory under

~/local/lib/python3/cmk/plugins/

Cheers
Thomas

1 Like
3

I just tried to add an empty file in:

~/local/lib/python3/cmk/gui/plugins/wato/check_parameters/cisco_dom.py

#!/usr/bin/env python3
"""
Nothing to see. Override in
~/local/lib/python3/cmk_addons/plugins/cisco_dom/rulesets/...
"""
pass

That removed the old ruleset. And the new ruleset is placed in

~/local/lib/python3/cmk_addons/plugins/cisco_dom/rulesets/ruleset_cisco_dom.py

That seems to work for me, although I haven’t fully tested it yet.


rule_spec_cisco_dom = CheckParameters(
    name="cisco_dom",
   ...
1 Like
4

This solution works perfectly, thank you!

However, it’s still unclear to me why the rulesets provided with the Checkmk 2.4 distribution are still written using the legacy API, while custom plugins are required to use the new ruleset API.

My situation is a good example: by using a ruleset based on the new API, I’m forced to define a parameter structure that’s incompatible with the one used in the original distribution plugin. As a result, I’ll likely have to modify my implementation again when the official ruleset is eventually updated.

1 Like
5

This is a very interesting point, @moritz .

6

The problem here is that most of our external plugins used the very old old legacy structure under “~/local/share/check_mk/web/plugins/wato/” for rulesets.
In your case the build-in plugin uses the only old structure under “~/lib/check_mk/gui/plugins/wato/check_parameters/” respective “~/local/lib/…”.

At the moment we have a strange combination of “old old” rules that don’t work anymore, “old” rules that work but have different structure and current rules with new structure.

1 Like