Title: Limit length of Hostname
Class: security
Compatible: compat
Component: wato
Date: 1699601325
Edition: cre
Knowledge: undoc
Level: 1
State: unknown
Version: 2.2.0p15
Prior to this Werk it was possible to create Hosts with arbitrary length.
Since Checkmk stores information in files which paths contain the hostname these path could exceed the allowed length leading to various errors to an extend that rendered the usage of parts of the GUI useless.
We found this vulnerability internally.
<b>Affected Versions</b>:
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0
<b>Vulnerability Management</b>:
We have rated the issue with a CVSS Score of 2.7 (Low) with the following CVSS vector:
<tt>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L</tt>.
We assigned CVE-2023-23549 to this vulnerability.
<b>Changes</b>:
This Werk adds a maximum length of 253 characters for the hostname.
Title: audit log: Add options to hide object and object type
Class: feature
Compatible: compat
Component: wato
Date: 1699875661
Edition: cre
Knowledge: undoc
Level: 1
State: unknown
Version: 2.2.0p15
This werk introduces the option to toggle the 'object' and
'object type' columns in the audit log table.
Title: No longer sporadically report stale services which are based on piggyback data
Class: fix
Compatible: compat
Component: checks
Date: 1699980710
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p15
If the check interval of a host was greater than 1 minute, any of its reported piggyback data
was at risk of being ignored by the target host because of being too old.
Title: Prevent LDAP users from disappearing at remote sites
Class: fix
Compatible: compat
Component: multisite
Date: 1699364878
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p15
If a remote site had ldap connectors specified, which where not available at the central site,
the users on the remote site were regularly removed during activate changes.
This error was not always clearly visible, as the ldap users were resynchronised immediately after activate changes.
However, this introduced race conditions, such as users not known to the monitoring core or automatic logouts at the remote site.
Werk 16145 was deleted. The following Werk is no longer relevant.
Title: "Always up" hosts can always notify
Class: fix
Compatible: compat
Component: core
Date: 1699884551
Edition: cee
Knowledge: undoc
Level: 1
State: unknown
Version: 2.2.0p15
Do not postpone notifications for "always up" hosts.
The notification logic would wrongly assume that "always up" hosts may,
in fact, be down and erroneously postpone notifications. This has been
fixed, such hosts are never down.
Title: "Always up" hosts can always notify
Class: fix
Compatible: compat
Component: core
Date: 1699884551
Edition: cee
Knowledge: undoc
Level: 1
State: unknown
Version: 2.2.0p15
Do not postpone notifications for "always up" hosts.
The notification logic would wrongly assume that "always up" hosts may,
in fact, be down and erroneously postpone notifications. This has been
fixed, such hosts are never down.
Title: downtimes: can now delete downtimes from remote sites
Class: fix
Compatible: compat
Component: rest-api
Date: 1699869696
Edition: cre
Knowledge: undoc
Level: 1
State: unknown
Version: 2.2.0p15
As a result a previous change to the downtimes delete endpoint,
we introduced a bug which prevented downtime deletion on
remote sites.
This werk addresses this issue. Downtimes on remote sites are now
deleted as expected.
Title: Enable update as site user due incompatible python versions
Class: fix
Compatible: compat
Component: omd
Date: 1699525492
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p14
This werk is relevant for you in case you've been using <tt>omd -V {version} update</tt> as site user.
Due to the update of the Python version from 3.11.2 to 3.11.5 with 2.2.0p13, we needed to introduce a fix in order to avoid the following issue:
C+:
Traceback (most recent call last):
File "/omd/versions/2.2.0p13.cee/bin/omd", line 60, in <module>
import omdlib.main
File "/omd/versions/2.2.0p13.cee/lib/python3/omdlib/main.py", line 36, in <module>
import random
File "/omd/versions/2.2.0p13.cee/lib/python3.11/random.py", line 49, in <module>
from math import log as _log, exp as _exp, pi as _pi, e as _e, ceil as _ceil
ImportError: /omd/versions/2.2.0p13.cee/lib/python3.11/lib-dynload/math.cpython-311-x86_64-linux-gnu.so: undefined symbol: _PyModule_Add
C-:
However, this fix introduced another issue with the release of 2.2.0p13, that's why we had to withdraw 2.2.0p13 and release 2.2.0p14 which addressed both issues.
Werk 16192 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Licensing: Distributed monitoring overview during update
Class: fix
Compatible: compat
Component: multisite
Date: 1699368840
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p14
When updating a distributed setup from version 2.1, the site status on the Distributed Monitoring page will display the error <tt>"<lambda>() got an unexpected keyword argument 'license_state'"</tt> if the remote site has already been updated to version 2.2, but the central site is still version 2.1.
The site status will now display correctly.
------------------------------------<diff>-------------------------------------------
Title: Licensing: Distributed monitoring overview during update
Class: fix
Compatible: compat
Component: multisite
Date: 1699368840
Edition: cre
Knowledge: doc
Level: 1
Version: 2.2.0p14
- When updating a distributed setup from version 2.1, the site status on the Distributed Monitoring page will display the error <tt>"<lambda>() got an unexpected keyword argument 'license_state'"</tt> if the remote site has already been updated to version 2.2, but the central site is still version 2.1.
? ^ ^
+ When updating a distributed setup from version 2.1, the site status on the Distributed Monitoring page will display the error <tt>"<lambda>() got an unexpected keyword argument 'license_state'"</tt> if the remote site has already been updated to version 2.2, but the central site is still version 2.1.
? ^^^^ ^^^^
The site status will now display correctly.
-
-
Title: host_config: can now move host between nested folders
Class: fix
Compatible: compat
Component: rest-api
Date: 1699258683
Edition: cre
Knowledge: undoc
Level: 1
State: unknown
Version: 2.2.0p15
This werk addresses an issue discovered when moving hosts to folders
that were more than one folder deep. Previously, the possible target
folders for the given host were incorrectly checked. We now have
a fix which will correctly check first if the target folder is
permitted.