ID: 14896
Title: Fix "Move to other folder" of hosts filtered by alias
Component: Setup
Level: 1
Class: Bug fix
Version: 2.2.0i1
If you filtered for hosts on the "Setup" - "Hosts" page and used the alias as
filter value, the option "Move to other folder" showed the error "Please select
some hosts before doing bulk operations on hosts.", even if you selected the
matched hosts.
ID: 14655
Title: Extension manager: disable upgraded packages
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
When upgrading installed MKPs to a new version, the former version is disabled now.
ID: 13262
Title: Missing failure indicator in IPMI status messages
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
The IPMI sensor check would result in an OK state when confronted with a status
message like this:
"ok (Presence detected, Predictive failure, Power Supply AC lost)"
This change adds more substrings indicating an error and renders a service with
the above string CRIT.
ID: 14958
Title: cmk-update-agent: Fix lockfile handling
Component: agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
This Werk mainly fixes an inconvenience that occured when invoking multiple
instances of the Agent Updater simultaneously.
Since Werk #14732, it's possible for the Agent Updater to wait for running exclusively.
However, before this Werk, a second instance failed to actually open and hold the
respective lockfile (because the first instance deleted it). Hence, it also failed to
delete it in the end.
This resulted in an error message like <tt>No such file or directory:
'/tmp/cmk-update-agent.pid'"</tt>. This didn't result in a crash, but the error was
printed to the logfile and could lead to confusion.
ID: 14957
Title: fileinfo: Crash on negative timespans
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
When monitoring files/filegroups with service monitoring rules <i>Size and age of single files</i>
or <i>Size, age and count of file groups</i> (i.e., all services basing on the <i>fileinfo</i>
agent section, not on the mk_filestats agent plugin), the service evaluation could fail with a crash
report containing the error "Cannot render negative timespan".
This happened very rarely, and if it did, it was temorary (for one check period).
Since the fix consists of a change in the agent section evaluation, you'll have to update agents
to apply it on affected systems.
ID: 14967
Title: Timesyncd check plugin: Include metrics for sync times, change check behavior when NTP server not reachable and future-proofing
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.2.0i1
Since at least systemd v250 <tt>/var/lib/systemd/timesync/clock</tt> should no longer be used to determine the time since the last synchronisation, instead the modification time of <tt>/run/systemd/timesync/synchronized</tt> is now used.
To monitor the reliability of this time, this werk also introduces two new metrics:
LI: Time since last synchronisation: The modification time of <tt>/run/systemd/timesync/synchronized</tt> if available, otherwise <tt>/var/lib/systemd/timesync/clock</tt>.
LI: Time since last NTPMessage: When the last message from the NTP server was received.
To have these metrics available, the Checkmk linux agent needs to be updated, otherwise only the time since last synchronisation based on <tt>/var/lib/systemd/timesync/clock</tt> will be shown.
Since the modification time of <tt>/var/lib/systemd/timesync/clock</tt> can at times be unsuitable to monitor when synchronization occurred (due to limited error handling in earlier systemd version), the default threshold for the allowed duration since last synchronisation has been removed.
If you want to apply thresholds to the time since last synchronisation you now have to enable the rule manually.
The default thresholds for the allowed duration since last NTPMessage have been set to 1h (WARN) and 2h (CRIT).
Additionally, the behavior of the check was changed to go to CRIT when the NTP server could not be reached for synchronisation.
In the course of the werk the rendering of the jitter was also corrected to show a time span instead of a date.
ID: 13436
Title: Fix 500 errors on BI aggregation endpoints
Component: REST API
Level: 1
Class: Bug fix
Version: 2.2.0i1
Deleting a aggregation returned 500 status code "permission mismatch"
Deleting a non existing aggregation returned 500 status code, now returns 404
ID: 13435
Title: Fix 500 errors on BI rule endpoints
Component: REST API
Level: 1
Class: Bug fix
Version: 2.2.0i1
Deleting a rule which is a dependency of another rule returned a 500 status code, now returns 409
Deleting a rule returned a 500 status code "permission mismatch", now returns 204
Deleting a non existing rule returned a 500 status code, now returns 404
ID: 14652
Title: Real-time checks: Simplify encryption setup
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.2.0i1
This Werk is incompatible for users of the <i>real-time check (RTC)</i> feature.
We incompatibly change the way the encryption for RTC is configured.
Since we cannot guarantee a compatible migration in all cases, we play it safe:
All rulesets of the rule <i>"Real-time checks"<i> are extended by a randomly generated secret, used for (and enabling) encryption.
Users have to reconfigure the rules to get the old behavior (or deploy the agents to use the created password).
<b>In detail:</b>
The setup of the RTC encryption had become confusing over time.
We now radically simplify it.
The setup is exclusively done via a new configuration option <i>"Encryption"</i>, added to the ruleset <i>"Real-time checks"</i> (formally known as <i>"Send data for real-time checks"</i>).
LI: The Checkmk agent for Linux encrypts real-time data if and only if the parameter <tt>RTC_SECRET</tt> is set (not empty) in <tt>/etc/check_mk/real_time_checks.cfg</tt>.
LI: The Checkmk site expects encrypted data if and only if a pre-shared secret is configured via the ruleset <i>"Real-time checks"</i>.
LI: If the site expects encrypted data, unencrypted data is discarded (and vice versa).
For users of the Agent Bakery the configuration of the ruleset is sufficient.
The configuration of the agent is taken care of by the bakery.
However, even if you do not use the agent bakery, you still have to set up the rule, such that the site knows which secret to use for decryption.
All other encryption settings (distributed across the rules <i>"Encryption (Linux, Windows)"</i> and <i>"Enable handling of Real-Time Checks"</i>) have no effect on the RTC encryption anymore.
Unfortunately, we can't make this change compatible via automatic configuration update.
Since we do not want to make users send unencrypted data by accident, we populate the encryption setting for <b>all existing rules</b> with a random value.
To make the RTC work again either update the baked agents, or adapt the configured rules to reflect the behavior of the deployed agent.