[//]: # (werk v2)
# mk_job: MK_VARDIR defaults not being set in bakery
key | value
---------- | ---
compatible | yes
version | 2.3.0p12
date | 2024-07-26T05:47:27+00:00
level | 1
class | fix
component | checks
edition | cre
Due to a different way to set in `MK_VARDIR` in `mk_job`, default values would not be baked into `mk_job` and
derivates.
This change adds a replacement rule for the way `MK_VARDIR` gets assigned in `mk_job` and also
separates assignment and export in order to avoid known problems with Solaris.
[//]: # (werk v2)
# Agent Updates: host selection ignores configured host labels
key | value
---------- | ---
date | 2024-08-01T13:39:05+00:00
version | 2.3.0p12
class | fix
edition | cee
component | agents
level | 1
compatible | yes
When configuring the global setting *Automatic agent updates/Activate update only on the selected hosts*,
the selection of host labels under *Match host labels* didn't get recognized.
Technical background: The set of host selection parameters used in above rule comes from a generic ruleset
pattern that's used in some more host rulesets in Checkmk.
Eventually, the option to filter for host labels got introduced to the generic ruleset, but we missed to
evaluate it for the determination of allowed hosts for agent updates.
[//]: # (werk v2)
# Support Azure PostgreSQL Flexible Server
key | value
---------- | ---
date | 2024-08-21T14:54:11+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | yes
[Microsoft is retiring the Azure resource](https://learn.microsoft.com/en-us/azure/postgresql/single-server/… "Database for PostgreSQL single server" .
With this Werk, we now support monitoring the recommended Azure resource "Database for PostgreSQL flexible server". In the rule "Microsoft Azure" under "Azure services to monitor", users can now select the new option "Database for PostgreSQL flexible server". Note that the former option "Database for PostgreSQL" was renamed to "Database for PostgreSQL single server" and stays in place. The metrics monitored for flexible servers correspond to those monitored for single servers and the same checks are used.
See the [check plugin catalog](https://checkmk.com/integrations?distributions%5B%5D=check_mk&dist… for more details.
[//]: # (werk v2)
# heartbeat_crm_resources: Check for unmanaged nodes
key | value
---------- | ---
date | 2024-08-08T10:22:23+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | yes
The plugin `heartbeat_crm_resources`, which monitors the resouces of Heartbeat/Pacemaker clusters,
now additionally checks if there are any unmanaged nodes. If this is the case, the plugin goes WARN
by default. The monitoring state is configurable in the corresponding ruleset.
[//]: # (werk v2)
# cpu_utilization: allow total CPU utilization to be set above 101%
key | value
---------- | ---
date | 2024-08-28T06:45:04+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Before this werk, the "High utilization at" level option within the
"Levels over an extended time period on total CPU utilization" target
was limited to a maximum of 101%. However, in environments like containers,
the total CPU utilization can exceed this threshold. This werk therefore removes
the upper limit for the total value.
[//]: # (werk v2)
# KUBE: Addition of support for Kubernetes v1.30
key | value
---------- | ---
date | 2024-08-27T10:39:49+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | yes
With this release of Checkmk, we introduce support for version 1.30 of Kubernetes.
The supported versions are listed below:
Checkmk 2.2: 1.22, 1.23, 1.24, 1.25, 1.26, 1.27
Checkmk 2.3: 1.24, 1.25, 1.26, 1.27, 1.28, 1.29, 1.30
The list of supported versions may not apply to future patch versions. For such cases, a
new werk will be released.
[//]: # (werk v2)
# Synthetic Monitoring: Fix XSS vector in HTML logs displayed in UI
key | value
---------- | ---
date | 2024-08-26T18:51:50+00:00
version | 2.4.0b1
class | security
edition | cee
component | multisite
level | 1
compatible | yes
The user interface offers the option to display the HTML logs of monitored synthetic tests. These
logs are generated on the host where the test is executed and are therefore prone to XSS attacks. A
malicious actor with access to the host could attempt to inject malicious JavaScript code into these
logs before they are transferred to the monitoring server.
As of this werk, the logs are rendered sandboxed, which prevents code injected into the logs from
accessing the surrounding Checkmk site. However, note that an attacker could still attempt to hijack
the log to eg. display a fake login page. Therefore, we additionally display a corresponding
security note when rendering the logs.
An unfortunate side effect of the sandboxing described above is that the "Expand/Collapse all"
buttons in the logs are deactivated. Users can still download the logs and inspect them outside the
Checkmk user interface, as before.
This issue was found during internal review.
*Affected Versions*:
* 2.3.0
*Mitigations*:
Avoid displaying the HTML logs in the user interface.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 2.3 Low (`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N`) and assigned `CVE-2024-38858`.
[//]: # (werk v2)
# Persist known host keys for checks that use SSH
key | value
---------- | ---
date | 2024-08-26T08:56:04+00:00
version | 2.4.0b1
class | security
edition | cre
component | checks
level | 1
compatible | yes
When using the special agent *VNX quotas and filesystems* or the active check *Check SFTP Service* the host keys were not properly checked.
If an attacker would get into a machine-in-the-middle position he could intercept the connection and retrieve information e.g. passwords.
As of this Werk the host key check is properly done.
In order to store known host keys a regular `known_hosts` file is used that is stored in `/omd/sites/$SITENAME/.ssh/known_hosts`.
If a host key changes an error is now raised that requires manual edit of this file.
This issue was found during internal review.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 6.3 Medium CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N and assigned CVE-2024-6572.
[//]: # (werk v2)
# Fix Cisco Meraki missing services
key | value
---------- | ---
date | 2024-08-27T09:38:07+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
In some rare cases, when using the Cisco Meraki Special Agent, certain services such as temperature
sensors or device status may be missing. This happened when no device name was configured for a
particular device.
These devices are now added to the main host on which the Cisco Meraki integration is configured.
If you want to monitor the device as a separate piggyback host, you must configure a name for that
device.
The missing services must be discovered by running a service discovery on the main host.
[//]: # (werk v2)
# Handle years in ntp output
key | value
---------- | ---
date | 2024-08-27T11:12:57+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This werk affects you, in case your last `ntpq` synchronization was indeed more than a year ago.
A potential check crash traceback looks like:
```
File "/omd/sites/SITE/lib/python3/cmk/base/plugins/agent_based/ntp.py", line 67, in _ntp_fmt_time
return int(raw)
ValueError: invalid literal for int() with base 10: '3y'
```
The year case is now handled in the parse function.