[//]: # (werk v2)
# mknotifyd: Log to correct file after logrotate
key | value
---------- | ---
date | 2024-04-25T08:08:50+00:00
version | 2.3.0b7
class | fix
edition | cee
component | notifications
level | 1
compatible | yes
The logrotate cronjob rotated the logfile mknotifyd.log in the right way but
the mknotifyd was not aware of the changed logfile, resulting in logging to the
rotated file. The mknotifyd is now aware of a change of the logfile.
[//]: # (werk v2)
# ldap: allow manually updating locked status of users
key | value
---------- | ---
date | 2024-04-24T08:37:31+00:00
version | 2.3.0b7
class | fix
edition | cre
component | wato
level | 1
compatible | yes
When using the "Authentication Expiration" sync plug-in for LDAP, users can be
stuck in a locked state after too many failed login attempts.
With this werk it is now allowed to edit the "Disable password" option in the UI
(or "disable_login" in the REST API) for users managed by LDAP. Please note that
a sync with the LDAP will restore the original value.
[//]: # (werk v2)
# Custom graphs: Fix crash in case of missing host/service/metric
key | value
---------- | ---
date | 2024-04-24T14:21:32+00:00
version | 2.3.0b7
class | fix
edition | cee
component | metrics
level | 1
compatible | yes
Custom graphs can contain elements whose host or service is non-existant. This happens for example
when a host is removed from the monitoring after one of its metrics has been added to a custom
graph. In such cases, no graph was rendered. Instead, the Checkmk UI displayed the message "Cannot
calculate graph recipes" and showed a traceback.
As of this werk, the UI instead renders no lines for such elements and denotes them with "n/a" in
the graph legend.
[//]: # (werk v2)
# Custom graphs: Fix crash in case of unavailable scalars
key | value
---------- | ---
date | 2024-04-23T10:22:44+00:00
version | 2.3.0b7
class | fix
edition | cee
component | metrics
level | 1
compatible | yes
When adding a scalar to a custom graph, it is possible that no value is available for this scalar.
For example, this is the case when adding the CRIT threshold of a metric for which no thresholds are
configured. In such cases, no graph was rendered. Instead, the Checkmk UI displayed the message
"Cannot calculate graph recipes" and showed a traceback.
This werk restores the correct behavior: No lines are rendered for unavailable scalars and they are
denoted with "n/a" in the graph legend.
[//]: # (werk v2)
# apc_powerswitch: upgrade old discovery parameters
key | value
---------- | ---
date | 2024-04-24T13:48:13+00:00
version | 2.3.0b7
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Old apc_powerswitch discovery parameters are upgraded to the new format
during `omd update`.
[//]: # (werk v2)
# agent_threepar: The agent mistakenly only accepted default values as valid ones
key | value
---------- | ---
date | 2024-04-24T14:01:07+00:00
version | 2.3.0b7
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This fixes a regression in Checkmk 2.3 beta.
The integration to monitor "3PAR Configuration" mistakenly only accepted any
subset of the default values as valid values.
Werk 16805 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# mkp-tool: CLIs 'package' command
key | value
---------- | ---
date | 2024-04-23T11:57:59+00:00
version | 2.3.0b7
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The `mkp package <manifest>` command would fail with "File conflict: /omd/sites/mydevsite/local/... (already existing)" if called in a site context.
Additionally, we no longer write the mkp-tools version into the "version.min_required" field of the manifest template.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# mkp-tool: CLIs 'package' command
key | value
---------- | ---
date | 2024-04-23T11:57:59+00:00
- version | 2.3.0b6
? ^
+ version | 2.3.0b7
? ^
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The `mkp package <manifest>` command would fail with "File conflict: /omd/sites/mydevsite/local/... (already existing)" if called in a site context.
Additionally, we no longer write the mkp-tools version into the "version.min_required" field of the manifest template.
[//]: # (werk v2)
# mkp-tool: CLIs 'package' command
key | value
---------- | ---
date | 2024-04-23T11:57:59+00:00
version | 2.3.0b6
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The `mkp package <manifest>` command would fail with "File conflict: /omd/sites/mydevsite/local/... (already existing)" if called in a site context.
Additionally, we no longer write the mkp-tools version into the "version.min_required" field of the manifest template.
Werk 16692 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# inventory_primekey: do not crash upon empty node ID
key | value
---------- | ---
date | 2024-04-20T10:06:26+00:00
version | 2.3.0b7
class | fix
edition | cre
component | checks
level | 1
compatible | yes
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# inventory_primekey: do not crash upon empty node ID
key | value
---------- | ---
date | 2024-04-20T10:06:26+00:00
- version | 2.3.0b6
? ^
+ version | 2.3.0b7
? ^
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Werk 16780 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# APIDocs: missing ETag response header for 2 endpoints.
key | value
---------- | ---
date | 2024-04-24T14:41:14+00:00
version | 2.3.0b7
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
The following endpoints did not show that they returned an ETag header
as part of their 200 OK response.
* Show all pending changes
* Show password
This werk addresses this issue. Both now show the correct headers in
their responses.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# APIDocs: missing ETag response header for 2 endpoints.
key | value
---------- | ---
date | 2024-04-24T14:41:14+00:00
- version | 2.3.0b6
? ^
+ version | 2.3.0b7
? ^
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
The following endpoints did not show that they returned an ETag header
as part of their 200 OK response.
* Show all pending changes
* Show password
This werk addresses this issue. Both now show the correct headers in
their responses.