[//]: # (werk v2)
# infoblox_temp: Add support for Nios version > 8.6
key | value
---------- | ---
date | 2024-04-26T06:56:26+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The relevant OIDs have changed for newer Nios versions. The check now differentiates between the different version, meaning the check does not crash anymore when parsing newer sections.
[//]: # (werk v2)
# Fix crash on user page with SAML connector
key | value
---------- | ---
date | 2024-04-29T12:01:22+00:00
version | 2.4.0b1
class | feature
edition | cee
component | wato
level | 1
compatible | yes
When viewing the users page with a user using a SAML connector a crash report
with "Internal error: locked" was shown. This is fixed now.
Werk 16274 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Unusable services for "HPE Proliant Servers: Raid Status"
key | value
--- | ---
compatible | no
version | 2.3.0b1
date | 2023-12-15T10:35:33+00:00
level | 1
class | fix
component | checks
edition | cre
This fixes some unusable services of the "HPE Proliant Servers: Raid Status" plugin.
This werk only affects you if you observe unknown "Logical device <ITEM>" services after the upgrade.
In case you are affected please run a discovery on the affected hosts and fix the monitoring history as described below.
We observed some devices to send `"\x00"` (the null-byte) as their name (`OID .1.3.6.1.4.1.232.3.2.3.1.1.14`).
Not all components delt well with it, leading to unacknowlegable downtimes, non matching rules and the like.
We now replace all null-bytes with `"\\x00"` (the literal containing the four characters backslash, 'x', 'zero', 'zero').
As of Checkmk 2.3, this should in fact no longer be necessary, but as we need a backportable solution, we change the item consistently in all versions.
If this affects you, you might also want to fix the services in the monitoring history by running
```
sed -i 's|\\x00|\\\\x00|' var/check_mk/core/history var/check_mk/core/archive/*
```
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Unusable services for "HPE Proliant Servers: Raid Status"
key | value
--- | ---
compatible | no
version | 2.3.0b1
date | 2023-12-15T10:35:33+00:00
level | 1
class | fix
component | checks
edition | cre
This fixes some unusable services of the "HPE Proliant Servers: Raid Status" plugin.
This werk only affects you if you observe unknown "Logical device <ITEM>" services after the upgrade.
In case you are affected please run a discovery on the affected hosts and fix the monitoring history as described below.
We observed some devices to send `"\x00"` (the null-byte) as their name (`OID .1.3.6.1.4.1.232.3.2.3.1.1.14`).
Not all components delt well with it, leading to unacknowlegable downtimes, non matching rules and the like.
We now replace all null-bytes with `"\\x00"` (the literal containing the four characters backslash, 'x', 'zero', 'zero').
As of Checkmk 2.3, this should in fact no longer be necessary, but as we need a backportable solution, we change the item consistently in all versions.
If this affects you, you might also want to fix the services in the monitoring history by running
```
- sed -i 's|\x00|\\x00|' var/check_mk/core/history var/check_mk/core/archive/*
+ sed -i 's|\\x00|\\\\x00|' var/check_mk/core/history var/check_mk/core/archive/*
? + ++
```
[//]: # (werk v2)
# reports: remove site_id of other customers when rendering reports
key | value
---------- | ---
date | 2024-04-18T07:21:06+00:00
version | 2.4.0b1
class | fix
edition | cme
component | reporting
level | 1
compatible | yes
When you try to create a report and a remote site is not reachable, the
report will include the site_id of said site. This werk addresses this
issue by only showing errors that belong to that customer.
[//]: # (werk v2)
# Notify users on account security changes
key | value
---------- | ---
date | 2024-04-26T12:20:30+00:00
version | 2.4.0b1
class | feature
edition | cre
component | wato
level | 1
compatible | yes
Checkmk will now notify users on security changes to their accounts within Checkmk. By default users will be emailed if this option is configured, otherwise users will be notfied via the internal user messaging system. Notifications within Checkmk cannot be deleted by any user however the display duration of these notifications can be configured. The default of 7 days with a minimum of 15 minutes.