Lock Host Objects in WATO


We running checkmk version 1.6.0p27.
A request from our internal customer is now to lock host objects to avoid accidentally altering or deletion. I know the way to lock a folder or host objects in the rules.mk files but we need a way to do this in WATO GUI and also to limit the lock/unlock to certain contact groups.

I am just wondering if there is one out in the community which had this demand already and may developed a WATO plugin for that purpose.

Any help is much appreciated.




No one an idea???
Maybe a hint where to look in the code to develop a WATO plugin?

Thank you


Hi @mike1098
I understand the need, but it’s all about sense and some governance - don’t give users access to WATO unless they know what they’re doing.
Some features you can use to restore previous versions of your monitoring configuration is link your WATO to a GIT repo. Another approach available is CheckMK backup that you can configure and restore at your needs.
You can also restore WATO configuration from available snapshots - you can configure the amount of them in Global settings.

Hello Ricardo,

Thank you for your replay.
That’s all known possibilities.
We provide monitoring service to our internal sites which are ~300 for the time being. Each site has its own local IT which knows their inventory and they must be able to add/remove their hosts. In some regions in addition a L2 team take care of high critical services local on the site. This L2 team is asking to lock hosts to prevent deletion from local IT because it happened not only once that local IT deleted or otherwise altered the monitoring of this critical services.

I hope I did a better explanation of the demand now.



The only mechanic i know that can be possibly copied is the mechanic from the DCD.
Every host attribute set from the DCD is automatically locked for manual edit.
But i think it is only valid for host attributes and not complete hosts.

For complete hosts i also only know the method mentioned with the locking of complete folders/subfolders from the .mk files.


do you have a example how this looks like?

Yes, in the .wato for folders:

{'attributes': {'contactgroups': {'groups': ['Implementation'],
                                  'recurse_perms': True,
                                  'recurse_use': True,
                                  'use': True,
                                  'use_for_services': True},
                'meta_data': {'created_at': None, 'created_by': None},
                'site': 'xyz',
                'tag_agent': 'no-agent',
                'tag_snmp_ds': 'no-snmp'},
 'lock': False,
 'lock_subfolders': False,
 'num_hosts': 0,
 'title': u'Main directory'}

or in the hosts.mk:

# Created by WATO
# encoding: utf-8
_lock = True
all_hosts += ['x']

You see then the following:


In the host object itself is see the following:

So I assume there is something similar for single host object.
As @andreas-doehler mentioned it looks like its used by DCD to lock attributes only

Any help is much appreciated



I found the following:


But its not working in 1.6. Tried the following:

# Created by WATO
# encoding: utf-8
_lock = False
all_hosts += ['xxx']

host_tags.update({'test': {'piggyback': 'auto-piggyback', 'networking': 'lan', 'agent': 'cmk-agent', 'criticality': 'offline', 'snmp_ds': 'no-snmp', 'ip-v4': 'ip-v4', 'ping': 'ping', 'site': 'xyz', 'tcp': 'tcp', 'address_family': 'ip-v4-only'}})


# Host attributes (needed for WATO)
{'test': {
    'meta_data': {
        'created_at': 1649158402.524705,
        'created_by': u'myself'
    'locked': {
        "locked_by": ("site_id", "dcd", "connection-id"),
        "attributes": [

Yes this is the structure used in 2.0 DCD. In 1.6 there should also be the attributes locked after DCD creation. I don’t know if it looks different there.

In the class ‘class HostAttributeLockedBy’ and ‘HostAttributeLockedAttributes’ of module builtin_attributes.py I changed the attribute ‘editable’ to True and now I see that in the host object:

now these configured attributes are not editable anymore:

One step further :slight_smile: but the host still could be deleted and also normal monitoring user can alter this settings.
Continue re-engineering :grimacing:



1 Like