ID: 11401
Title: New Bakery API
Component: agents
Level: 3
Class: New feature
Version: 2.0.0i1
It is now possible to extend Checkmk by writing your own bakery plugins.
That is, you can now deploy your own agent plugins and have them baked into
your agents by the agent bakery.
While this was also possible before by placing the right files at the right
locations, you can now deploy your plugins with the help of a well-documented,
versioned and comprehensive API. A bakery plugin is a Python 3 module that specifies
files that should be deployed to the baked agents, scriptlets that should be
executed on the target system (RPM scriplets, DEB maintainer scripts, Solaris PKG
installation scripts) on package transition, and Windows agent config entries (YAML config)
that should be available for the baked windows agents.
You can add your own bakery plugins by placing them at
<code>~/local/lib/check_mk/base/cee/plugins/bakery/</code>. For instructions and details
on how to use the new API, please refer to the official Checkmk documentation. With Checkmk 2.0,
also the majority of the builtin bakery plugins have been migrated to the new Bakery API, so
having a look at them at <code>~/lib/check_mk/base/cee/plugins/bakery/</code>
can also help to write your own plugins.
If you have deployed your bakery plugins to Checkmk before, using the previous method
of placing a plugin file to <code>~/local/share/check_mk/agents/bakery/</code>, your plugins
will continue to work with Checkmk 2.0, if you convert them to Python 3 syntax. However,
the Agent Bakery will display a deprecation warning on baking agents (visible at the
bake-agents background job details at the GUI, or on the console if baking via command line),
and the support for legacy bakery plugins will be removed in an upcoming version of Checkmk,
so it's worth it to migrate your plugins to the new API early.
ID: 11403
Title: Improved versioning for baked agent packages
Component: agents
Level: 1
Class: New feature
Version: 2.0.0i1
Previously, when updating a baked agent via a package manager, you would eventually
receive a warning about a downgrade of the Checkmk agent. The reason for this was the
baked agent's version string, that was formed of Checkmk version and the agent's configuration
hash , with the latter being quite random and thus confusing the package manager, that expects
an increasing versioning. E.g. a version string could be <tt>1.6.0p18.f123abcd</tt> before bake,
and <tt>1.6.0p18.1234cdef</tt> after bake.
This behavior is now fixed by introducing an internal bake revision, that increases on every
newly baked package (per Checkmk version) and that's only purpose is to guarantee an
increasing version string for the .rpm, .deb and .pkg packages (e.g. <tt>1.6.0p18-1.f123abcd</tt>
before bake, <tt>1.6.0p17-2.1234cdef</tt> after bake). Please note that this revision won't
be visible on the GUI or in the package's filenames, it only affects the package's metadata.
ID: 11373
Title: Made titles of options in host/folder permissions less uncertain
Component: WATO
Level: 1
Class: Bug fix
Version: 2.0.0i1
There have always been additional option when assigning contact groups to
WATO folders or hosts. The effect of this options meanwhile has not always
been absolute transparent depending if the user is in folder or in host
properties. Especially the outcome of option "Always add host contact groups
also to its services" has not been clear.
The titles do now explain better, what a particular option really does. This
is just a clarification of the current, actual behaviour and no change of
the behaviour itself. Therefore there is no need for manual interaction.
ID: 11325
Title: mssql_jobs: new plugin to monitor scheduled jobs on MSSQL Server
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.7.0i1
mssql_jobs is a new plugin that enables the monitoring of scheduled jobs on
Microsoft SQL Server. Each job is listed as a seperate service, for which the
following information is shown:
-job duration
-MSSQL job status
-outcome message
-step name at which the job failed (if applicable)
-last run
-next run
It is possible to set warn/crit levels for the job duration, in case the job or
schedule is inactive, and/or corresponding to the MSSQL job status.
Performance data is tracked in terms of job duration.
ID: 11338
Title: Fix "Fortigate Active Sessions" ruleset duplicates
Component: WATO
Level: 1
Class: Bug fix
Version: 2.0.0i1
In previous versions, there were two WATO rules which had the name
"Fortigate Active Sessions" where one concerned the Cluster
environment. This change renames the Cluster rule to allow a
proper differentitation.
ID: 11117
Title: Drop support for creation of HostLabels via discovery function
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.0.0i1
This werk only affect users who implemented their own plugins *and*
where creating HostLabels using the discovery function.
Plugins trying to create HostLabel instances will fail with a NameError.
The afore mentioned feature is no longer supported.
Creation of host labels can now only be implemented using the
new check API. It is done by passing a `host_label_function`
to the `register.agent_section` function. For details please
refer to the dokumentation.
ID: 11486
Title: LDAP: Fixed updating of attribute "Disabled Notifications"
Component: Multisite
Level: 1
Class: Bug fix
Version: 2.0.0i1
Werk #11481 fixed the usage of the attribute but did not take care, that the
attribute was updated, once it was enabled.
If you set the attribute from "True" to "False" in LDAP, the attribute now will
be updated.
ID: 11511
Title: Host label dependent services are now discovered automatically
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.0.0i1
A service discovery had to be executed twice in order to detect new services
based on host labels. The first execution found new host labels, the second one
found new services based on the previously found host labels.
These two steps are merged into one and services based on host labels are
discovered on-the-fly.
ID: 11510
Title: Discovered host labels are stored for cluster and each node
Component: WATO
Level: 1
Class: New feature
Version: 2.0.0i1
A Chechmk cluster host inherits host labels from its nodes. These labels are
discovered on the nodes. Previously these labels were stored only for the
cluster. Now the host labels are stored for the cluster and each node. This
means that host labels can now be used on clusters and nodes.
ID: 11116
Title: job: Failed jobs are not OK just because a new one is running
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.0.0i1
The job plugin determines its state from the age of the last job
and its exit code.
Previously, a job was considered {OK} regardless of its exit code
whenever a job was running at the time of checking. This way a long
running job could appear to be {OK} most of the time, even if it
was constantly failing.