[//]: # (werk v2)
# mk_redis: Autodetect Checkmk instances
key | value
---------- | ---
date | 2024-06-18T07:27:41+00:00
version | 2.3.0p10
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Previously the redis agent plugin configured to autodetect would not detect the Checkmk redis instances.
Now, on hosts running a Checkmk site, these instances can be autodetected as well and monitored as any other redis instance.
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.0p11
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.0p10
? ^
+ version | 2.3.0p11
? ^
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`.
Werk 16746 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# infoblox_service: Add support for NIOS 9.X
key | value
---------- | ---
compatible | no
version | 2.3.0p11
date | 2024-06-18T08:00:25+00:00
level | 1
class | fix
component | checks
edition | cre
With newer infoblox NIOS devices the <code>IB-PLATFORMONE-MIB::IBServiceName</code> have
changed. We use these name as service items. Please run a re-discovery on the
affected hosts.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# infoblox_service: Add support for NIOS 9.X
key | value
---------- | ---
compatible | no
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
date | 2024-06-18T08:00:25+00:00
level | 1
class | fix
component | checks
edition | cre
With newer infoblox NIOS devices the <code>IB-PLATFORMONE-MIB::IBServiceName</code> have
changed. We use these name as service items. Please run a re-discovery on the
affected hosts.
Werk 16526 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# password: the response schema now matches what is returned
key | value
---------- | ---
date | 2024-03-07T09:18:40+00:00
version | 2.3.0p11
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
This werk addresses an issue with the REST-API password endpoint
response. The response schema listed the title and the ident as
fields that should be returned but we were not returning them as
part of the password object. These have now been removed from the
schema.
Also, the members field was returning invalid information and
hence has been removed.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# password: the response schema now matches what is returned
key | value
---------- | ---
date | 2024-03-07T09:18:40+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
This werk addresses an issue with the REST-API password endpoint
response. The response schema listed the title and the ident as
fields that should be returned but we were not returning them as
part of the password object. These have now been removed from the
schema.
Also, the members field was returning invalid information and
hence has been removed.
Werk 17074 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# msexch_database: Use consistent units (ms/s) in rules & graphs
key | value
---------- | ---
date | 2024-06-18T07:20:14+00:00
version | 2.3.0p11
class | fix
edition | cee
component | checks
level | 1
compatible | yes
The msexch_database reported its values in ms in the summary/ruleset but
displayed the same value as seconds in the graph. With this werk, all
units will be reported consistently.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# msexch_database: Use consistent units (ms/s) in rules & graphs
key | value
---------- | ---
date | 2024-06-18T07:20:14+00:00
- version | 2.3.0p7
? ^
+ version | 2.3.0p11
? ^^
class | fix
edition | cee
component | checks
level | 1
compatible | yes
The msexch_database reported its values in ms in the summary/ruleset but
displayed the same value as seconds in the graph. With this werk, all
units will be reported consistently.
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.3.0p11
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.3.0b3
? ^^
+ version | 2.3.0p11
? ^^^
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.
Werk 17016 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# notification_rules: typo in field sort_order_for_bulk_notifications
key | value
---------- | ---
date | 2024-07-03T05:22:21+00:00
version | 2.3.0p11
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
The REST-API endpoints previously had a typo in the field
'sort_order_for_bulk_notifications'. The second t was missing.
This werk now corrects this.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# notification_rules: typo in field sort_order_for_bulk_notifications
key | value
---------- | ---
date | 2024-07-03T05:22:21+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
The REST-API endpoints previously had a typo in the field
'sort_order_for_bulk_notifications'. The second t was missing.
This werk now corrects this.
Werk 16436 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# kube_pod_conditions: Support PodReadyToStartContainers Condition
key | value
---------- | ---
date | 2024-07-01T14:21:43+00:00
version | 2.3.0p11
class | feature
edition | cre
component | checks
level | 1
compatible | yes
As of Kubernetes version 1.28, the PodCondition `PodHasNetwork` was renamed to
`PodReadyToStartContainers`. With this Werk, both naming conventions are supported.
This Werk also tweaks the summary of the check to be more consistent across different
Kubernetes environments.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# kube_pod_conditions: Support PodReadyToStartContainers Condition
key | value
---------- | ---
date | 2024-07-01T14:21:43+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | feature
edition | cre
component | checks
level | 1
compatible | yes
As of Kubernetes version 1.28, the PodCondition `PodHasNetwork` was renamed to
`PodReadyToStartContainers`. With this Werk, both naming conventions are supported.
This Werk also tweaks the summary of the check to be more consistent across different
Kubernetes environments.
Werk 17062 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fix problems on cloning built-in problems dashboard
key | value
---------- | ---
date | 2024-07-04T14:02:37+00:00
version | 2.3.0p11
class | fix
edition | cme
component | multisite
level | 1
compatible | yes
If you cloned the built-in dashboard "problems", the "Topic" section showed
"This element does not exist anymore".
Furthermore, if you edited the "Host statistics" or "Service statistics"
dashlet on the cloned dashboard, an error like "KeyError (size)" occurred.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fix problems on cloning built-in problems dashboard
key | value
---------- | ---
date | 2024-07-04T14:02:37+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cme
component | multisite
level | 1
compatible | yes
If you cloned the built-in dashboard "problems", the "Topic" section showed
"This element does not exist anymore".
Furthermore, if you edited the "Host statistics" or "Service statistics"
dashlet on the cloned dashboard, an error like "KeyError (size)" occurred.
Werk 16533 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Event Console fix regex match in rule text
key | value
---------- | ---
date | 2024-07-01T15:31:04+00:00
version | 2.3.0p11
class | fix
edition | cee
component | ec
level | 1
compatible | yes
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
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Event Console fix regex match in rule text
key | value
---------- | ---
date | 2024-07-01T15:31:04+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cee
component | ec
level | 1
compatible | yes
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