[//]: # (werk v2)
# Reduce risk of hanging processes
key | value
---------- | ---
date | 2024-07-03T11:30:56+00:00
version | 2.3.0p9
class | fix
edition | cce
component | multisite
level | 1
compatible | yes
Currently files required for the licensing of Checkmk are locked for reading and writing. If a process does not release its acquired file lock for any reason, subsequent processes will continue to what for that lock, causing to the entire site to freeze.
This locking mechanism has now been removed to reduce the risk of this happening.
[//]: # (werk v2)
# Fix missing CSRF token issues
key | value
---------- | ---
date | 2024-07-03T09:07:10+00:00
version | 2.3.0p9
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI.
This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to:
* "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs)
* "Show analysis" and "Show bulks" in Setup > Events > Notifications
* Reordering notification rules via drag-and-drop in the same view
* "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents")
* "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead)
This Werk fixes the issues by adding the token.
Werk 16589 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Monitor Redfish compatible management boards / BMCs via optional MKP
key | value
---------- | ---
date | 2024-03-06T16:44:06+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | yes
You can now monitor _Redfish_ compatible management boards / BMCs with Checkmk.
To do so, please enable the natively shipped MKP redfish in _Setup --> Extension packages_ (in commercial editions of Checkmk) or via the command line tool `mkp` (in Checkmk Raw).
This will enable a new datasource program under _Setup --> Other integrations --> Redfish Compatible Management Controller_.
This is an experimental integration created and supported by the Checkmk community (Andreas Döhler/Yogibaer75), which has already been tested in many environments.
However, due to the diverse nature of server hardware, we plan to integrate it entirely for Checkmk 2.4.0, once we have gathered further feedback.
You can find the latest versions of the extensions in [Andreas' GitHub repository](https://github.com/Yogibaer75/Check_MK-Things/tree/master/check…. There you can also raise issues or raise pull requests until the plug-ins will be mainlined into Checkmk.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Monitor Redfish compatible management boards / BMCs via optional MKP
key | value
---------- | ---
date | 2024-03-06T16:44:06+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | yes
You can now monitor _Redfish_ compatible management boards / BMCs with Checkmk.
To do so, please enable the natively shipped MKP redfish in _Setup --> Extension packages_ (in commercial editions of Checkmk) or via the command line tool `mkp` (in Checkmk Raw).
This will enable a new datasource program under _Setup --> Other integrations --> Redfish Compatible Management Controller_.
- This is an experimental integration created by the Checkmk community (Andreas Döhler from Bechtle), which has already been tested in many environments.
? ^^ ^^^^^^^^^^
+ This is an experimental integration created and supported by the Checkmk community (Andreas Döhler/Yogibaer75), which has already been tested in many environments.
? ++++++++++++++ ^^^^^^^^ ^^
However, due to the diverse nature of server hardware, we plan to integrate it entirely for Checkmk 2.4.0, once we have gathered further feedback.
+ You can find the latest versions of the extensions in [Andreas' GitHub repository](https://github.com/Yogibaer75/Check_MK-Things/tree/master/check…. There you can also raise issues or raise pull requests until the plug-ins will be mainlined into Checkmk.
+
[//]: # (werk v2)
# Fix missing CSRF token issues
key | value
---------- | ---
date | 2024-07-03T09:07:10+00:00
version | 2.4.0b1
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI.
This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to:
* "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs)
* "Show analysis" and "Show bulks" in Setup > Events > Notifications
* Reordering notification rules via drag-and-drop in the same view
* "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents")
* "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead)
This Werk fixes the issues by adding the token.
Werk 16431 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: omd restore: Fix RuntimeError: Failed to determine site version
Class: fix
Compatible: compat
Component: omd
Date: 1718107423
Edition: cre
Level: 1
Version: 2.2.0p29
Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the
command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail:
C+:
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar
old_site.replacements(),
^^^^^^^^^^^^^^^^^^^^^^^
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements
raise RuntimeError("Failed to determine site version")
C-:
The failure only occured, if the user provided a site name, which differed from the original name,
and the original site did no longer exist. This crash also affected the `Migrate existing Site`
function of the appliance.
If you are affected by this crash, but are unable to update, then you can start be restoring the
site without a new name. The site can then be renamed with `omd mv`.
------------------------------------<diff>-------------------------------------------
Title: omd restore: Fix RuntimeError: Failed to determine site version
Class: fix
Compatible: compat
Component: omd
Date: 1718107423
Edition: cre
Level: 1
Version: 2.2.0p29
- Due to a regression introduced by Werk <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the
? -----
+ Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the
command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail:
C+:
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar
old_site.replacements(),
^^^^^^^^^^^^^^^^^^^^^^^
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements
raise RuntimeError("Failed to determine site version")
C-:
The failure only occured, if the user provided a site name, which differed from the original name,
and the original site did no longer exist. This crash also affected the `Migrate existing Site`
function of the appliance.
If you are affected by this crash, but are unable to update, then you can start be restoring the
site without a new name. The site can then be renamed with `omd mv`.
Title: Event Console fix regex match in rule text
Class: fix
Compatible: compat
Component: ec
Date: 1719847864
Edition: cee
Level: 1
Version: 2.2.0p30
Event console method compile_matching_value had a typo
which caused a valid regex to not match, because it was sent as a string
SUP-19224
Werk 16863 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: proxmox: Fix log parsing crash for Proxmox versions 3.2.4 and newer
Class: fix
Compatible: compat
Component: checks
Date: 1719585241
Edition: cre
Level: 1
Version: 2.2.0p30
The backup log format changed in Proxmox version 3.2.4 which resulted in a crash
in the Proxmox special agent.
The special agent can now handle both old and the new format of backup log messages.
------------------------------------<diff>-------------------------------------------
Title: proxmox: Fix log parsing crash for Proxmox versions 3.2.4 and newer
Class: fix
Compatible: compat
Component: checks
Date: 1719585241
Edition: cre
Level: 1
- Version: 2.2.0p29
? ^^
+ Version: 2.2.0p30
? ^^
The backup log format changed in Proxmox version 3.2.4 which resulted in a crash
in the Proxmox special agent.
The special agent can now handle both old and the new format of backup log messages.
Werk 16431 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# omd restore: Fix RuntimeError: Failed to determine site version
key | value
---------- | ---
compatible | yes
version | 2.3.0p9
date | 2024-06-11T12:03:43+00:00
level | 1
class | fix
component | omd
edition | cre
Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the
command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail:
```
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar
old_site.replacements(),
^^^^^^^^^^^^^^^^^^^^^^^
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements
raise RuntimeError("Failed to determine site version")
```
The failure only occured, if the user provided a site name, which differed from the original name,
and the original site did no longer exist. This crash also affected the `Migrate existing Site`
function of the appliance.
If you are affected by this crash, but are unable to update, then you can start be restoring the
site without a new name. The site can then be renamed with `omd mv`.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# omd restore: Fix RuntimeError: Failed to determine site version
key | value
---------- | ---
compatible | yes
version | 2.3.0p9
date | 2024-06-11T12:03:43+00:00
level | 1
class | fix
component | omd
edition | cre
- Due to a regression introduced by Werk <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the
? -----
+ Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the
command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail:
```
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar
old_site.replacements(),
^^^^^^^^^^^^^^^^^^^^^^^
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements
raise RuntimeError("Failed to determine site version")
```
The failure only occured, if the user provided a site name, which differed from the original name,
and the original site did no longer exist. This crash also affected the `Migrate existing Site`
function of the appliance.
If you are affected by this crash, but are unable to update, then you can start be restoring the
site without a new name. The site can then be renamed with `omd mv`.
[//]: # (werk v2)
# parent_scan: resolve failing parent scan background job
key | value
---------- | ---
date | 2024-07-02T12:39:27+00:00
version | 2.3.0p9
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
The REST API endpoint to initiate the parent scan background job
returned a 204 status code, which theoretically is correct. However,
the started background job failed immediately due to an invalid Python
syntax concerning the involving requested hosts. This werk fixes the issue.
[//]: # (werk v2)
# snmp: Fix error in SNMP context serialization introduced with werk 16862
key | value
---------- | ---
date | 2024-07-03T07:48:10+00:00
version | 2.3.0p9
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Werk 16862, which solved one SNMP context serialization bug, introduced another one.
When using SNMP contexts, the change activation crashes in 2.3.0p8.
After this Werk, SNMP contexts should work without errors.