ID: 7812
Title: Rulesets: Multiple tags of a tag group can be ORed
Component: WATO
Level: 2
Class: New feature
Version: 1.7.0i1
It's now possible to configure a list of alternative matching tag IDs of a
single tag group in one rule. The selected tag IDs are ORed. This reduces some
situations where users had to configure multiple rules when a rule should
affect multiple choices of a tag group.
The inverse operation "match all excluding the configured tag IDs" is also possible.
In this step the tag condition input has been changed to be more
compact by default. This should improve the condition dialog usability,
especially for users with a larger number of tag groups.
ID: 7774
Title: Fix installation issue on older debian based distros
Component: Site Management
Level: 2
Class: Bug fix
Version: 1.7.0i1
The werk #7344 introduced compatibility issues with Linux setups that don't
support linux capabilities (for different reasons). One reason may be a kernel
that does not support the capabilities.
We have added a fallback to the Checkmk debian packages that tries to use the
linux capabilities (as described in #7344). Once that fails it falls back to
setting the SETUID bit on the binaries, just like Checkmk did it before.
ID: 7770
Title: Fix "Periodic service discovery" disabling rules breaking config
Component: Core & setup
Level: 2
Class: Bug fix
Version: 1.7.0i1
In 1.6.0b1 a rule in the ruleset "Periodic service discovery" that is
configured with the option "Do not perform service discovery check" resulted
in the following exception when updating the core config (e.g. with cmk -U):
C+:
OMD[testsite]:~$ cmk --debug -Uv
Generating configuration for core (type cmc)...
time period '24X7': 2 time points
Configuration Error: 'NoneType' object has no attribute '__getitem__'
Traceback (most recent call last):
File "/omd/sites/testsite/bin/cmk", line 94, in
exit_status = modes.call(mode_name, mode_args, opts, args)
File "/omd/sites/testsite/lib/python/cmk_base/modes/__init__.py", line 72, in call
return mode.handler_function(*handler_args)
File "/omd/sites/testsite/lib/python/cmk_base/modes/check_mk.py", line 1106, in mode_update
do_update(create_core(options), with_precompile=True)
File "/omd/sites/testsite/lib/python/cmk_base/core_config.py", line 266, in do_update
do_create_config(core, with_agents=with_precompile)
File "/omd/sites/testsite/lib/python/cmk_base/core_config.py", line 219, in do_create_config
create_core_config(core)
File "/omd/sites/testsite/lib/python/cmk_base/core_config.py", line 235, in create_core_config
core.create_config()
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 63, in create_config
_create_config_hook(self._cmc_file)
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 123, in _create_config_hook
hosts_config = _measure_time(cmc_all_hosts)
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 156, in _measure_time
result = func(*args, **kwargs)
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 457, in cmc_all_hosts
cmc_hosts = CMCHosts(config_cache.all_active_hosts(), CMCHostConfig)
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 501, in __init__
self._compute(hostnames, host_class)
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 513, in _compute
host_config = host_class(hostname)
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 966, in __init__
self._compute()
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 984, in _compute
self._cmc_services()
File "/omd/sites/testsite/lib/python/cmk_base/cee/core_cmc.py", line 1259, in _cmc_services
if disc_check_params["check_interval"] \
TypeError: 'NoneType' object has no attribute '__getitem__'
C-:
ID: 7351
Title: Removed "checks" configuration variable
Component: Core & setup
Level: 2
Class: Bug fix
Version: 1.6.0b1
The Checkmk configuration variable <tt>checks</tt> was removed
It was used in hand configured Checkmk configurations in the early days. This
variable was never configurable by WATO. In case you configured Check_MK only
via WATO you will not be affected by this issue.
In case you need to migrate your configuration, you could move the
configuration to the WATO ruleset "Classical Active and Passive Monitoring
Checks".
ID: 7760
Title: Web API: Changed format of rules in get_ruleset/set_ruleset
Component: WATO
Level: 2
Class: Bug fix
Version: 1.6.0b1
The Web API calls <tt>get_ruleset</tt> and <tt>set_ruleset</tt>, that were
added with #4699 in Checkmk 1.5 have been changed in an incompatible way.
If you use these API calls in your scripts, you will have to change these
script to be compatible with Checkmk 1.6 and newer.
The change was caused by the change of the internal rule data structure, which
is described in detail in #7352.
The API calls now work with the internal rule format with the difference that
the <tt>host_folder</tt> condition is removed from the rules returned by
<tt>get_ruleset</tt> and automatically added to the rules that are written with
<tt>set_ruleset</tt>.
ID: 7352
Title: Changed format of rules in rules.mk configuration files
Component: Core & setup
Level: 2
Class: Bug fix
Version: 1.6.0b1
The internal data format of the Checkmk rules configured via WATO on the "Host-
& Service parameters" pages has been changed.
If you only use WATO for configuring Checkmk this change will not be relevant
for you, since the data format will be changed automatically during update to
1.6x.
In case you edit rules.mk (or other .mk) files manually or via script, you will
likely have to change your scripts.
The format changes was needed to make more flexible rule conditions possible.
The new conditions for 1.6 (select multiple choices of a tag group and labels)
have not been added yet. They are nearly ready and will be added in one of the
next beta releases.
The automatic update mentioned before is done using the command
<tt>cmk-update-config</tt> in the site. It's invoked during the <tt>omd
update</tt> execution and currently simply loads all folder, host, tag and
ruleset configuration files, executes the transform logic and saves again, just
like you would do when working in WATO. In case your scripts created an "old
style" WATO configuration file in an 1.6 site you could execute
<tt>cmk-update-config</tt> another time, which would load, convert and save the
configuration file. However, a better approach would be to update your scripts
to write the configuration files in the new format.
In Checkmk a ruleset is represented by a list of rules. In the past these rules
were represented by tuples with different elements (depending on the ruleset type).
The structure of a rule has now been changed to a dictionary.
An example from the sample configuration:
Old ruleset:
F+:rules.mk
host_contactgroups = [
('all',
[],
ALL_HOSTS,
{
'description': u'Put all hosts into the contact group "all"'
}
),
] + host_contactgroups
F-:
New ruleset:
F+:rules.mk
host_contactgroups = [
{
'condition': {
'host_folder': '/' + FOLDER_PATH
},
'value': 'all',
'options': {
'description': u'Put all hosts into the contact group "all"'
}
},
] + host_contactgroups
F-:
This shows the rough structure of the new format. Inside the condition dictionary
you can have multiple optional keys which trigger different host / service filters
in Checkmk.
The following examples of the <tt>condition</tt> dictionary are not covering
all possible combinations, but should give you and idea of the new condition
format. If you want to have a more detailed look, have a look at the tests below
<tt>tests/unit/cmk/utils/rulesets/</tt> or create rules with WATO and have a look
at the resulting rules.mk.
<h2>Explicit host name conditions</h2>
If you want to make a rule match on the hosts named <tt>host1</tt> and <tt>host2</tt>,
you may use a condition like this:
F+:rules.mk
"condition": {
"host_name": ["host1", "host2"]},
}
F-:
<h2>Exclude hosts</h2>
Match all hosts except <tt>HOST1</tt> and <tt>HOST2</tt>:
F+:rules.mk
"condition": {
"host_name": {
"$nor": ["HOST1", "HOST2"]
},
},
F-:
<h2>Regex on host names</h2>
Make a rule match on hosts by using a regular expression:
F+:rules.mk
"condition": {
"host_name": [{
"$regex": "abc[12]" # It's a case sensitive prefix match
},]
},
F-:
<h2>Match using host tags</h2>
Match all hosts that are <tt>test</tt> systems connected via <tt>wan</tt>
F+:rules.mk
"condition": {
"host_tags": {
"criticality": "test",
"networking": "wan",
},
}
F-:
<h2>Combine different conditions<h2>
Match test hosts that start with <tt>abc</tt>:
F+:rules.mk
"condition": {
"host_name": [{"$regex": "abc"}],
"host_tags": {
"criticality": "test",
},
}
F-:
<h2>Service rulesets: Match on the description</h2>
Same syntax as <tt>host_name</tt> condition, e.g. match all services starting with <tt>CPU</tt>:
F+:rules.mk
"condition": {
"service_description": [{"$regex": "CPU"}],
}
F-:
ID: 7353
Title: Changed format of host tags in hosts.mk configuration files
Component: Core & setup
Level: 2
Class: Bug fix
Version: 1.6.0b1
The internal data format of the Checkmk host and cluster definitions,
normally configured via WATO "Hosts" pages has been changed.
If you only use WATO for configuring Checkmk this change will not be relevant
for you, since the data format will be changed automatically during update to
1.6x. Have a look at #7352 for further information on the update mechanism.
In case you edit hosts.mk (or other .mk) files manually or via script to define
the <tt>all_hosts</tt> or <tt>clusters</tt> configuration options, you will
likely have to change your scripts or at least the configuration files.
A host definition with it's tags in the old format looks like this:
F+:hosts.mk
all_hosts += [
"my-host|cmk-agent|prod|lan|piggyback|no-snmp",
]
F-:
The first element is the host name and the tags of the host are listed in the
same string, separated via pipe characters. There is no information about the
tag group the configured tag is related with.
The new structure looks like this:
F+:hosts.mk:
all_hosts += [
"my-host",
]
host_tags["heute"] = {
"agent": "cmk-agent",
"criticality": "prod",
"networking": "lan",
"piggyback": "piggyback",
"snmp_ds": "no-snmp",
}
F-:
In the <tt>host_tags</tt> dictionary the keys are the tag groups (as defined in WATO)
and the values are the tags configured for each group.
ID: 7763
Title: Introduce labels as host and service properties
Component: Core & setup
Level: 2
Class: New feature
Version: 1.6.0b1
In addition to existing mechanisms like host tags and host custom attributes
that can be used to define custom host properties we have now added the labels.
The labels are similar to the host tags, but not work exactly in the same way.
A major difference is, that tags are based on a predefined collection of
tags (tag groups, tag ids) in Check_MK. Labels are more flexible and can
be created ad-hoc.
The explicit labels attribute is inherited from folders to hosts. Each
object may add a set of labels on it's own to the effective labels.
A label has the format <tt>key:value</tt>. For example <tt>os:windows</tt>.
Each host can have only one value per key. In case folders and hosts
define a value for the same key, the value next to the host will win.
The rulesets "Host labels" and "Service labels" can be used to assign labels to
hosts and services in addition to the labels configured using the host
attribute. Thes ruleset make it possible to assign lables to hosts and services
based on tags and other host / service conditions.
Labels can be created dynamically during runtime. Host labels can be discovered
using the HW/SW inventory. To realize this a new HW/SW inventory plugin has been
added that works on a generic "<<<labels>>>" section (see #7336).
The first agents that produce this section are the Kubernetes, AWS and Azure
special agents. They creates the label sections for all kind of objects that
are monitored by Checkmk. This makes Checkmk automatically import the labels
configured in the target systems.
Depending on the source of a label it is now colorized in different ways to
make the origin of the label transparent to the user.
The effective labels of hosts and service sare currently visible on WATO
"Parameters of X" page, mainly for diagnose.
The labels are available on the HW/SW inventory page and can be used as painter,
sorter and filter in the status views and reports. The painters have been added
to the host and service detail views.
The labels can currently not be used in rule conditions. This will be added in
one of the next beta releases.
ID: 6971
Title: Bump shipped Python from 2.7.15 to 2.7.16.
Component: Other Components
Level: 2
Class: New feature
Version: 1.6.0i1
Python 2.7.16 contains quite a few bug fixes compared to 2.7.15 plus some
performance, library and syntax improvements.
ID: 7156
Title: Dropping support for Ubuntu 17.10
Component: Linux Distributions
Level: 3
Class: New feature
Version: 1.6.0i1
Ubuntu 17.10 is End of Life. Therefore we stop supporting this Distro.