[//]: # (werk v2)
# netapp_ontap_environment: show unit of measurement in summary
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-02-01T13:34:16+00:00
level | 1
class | fix
component | checks
edition | cre
The service summary now displays the units of measurement of the monitored value.
Werk 16295 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: postfix_mailq_status: Rework discovery
Class: fix
Compatible: compat
Component: checks
Date: 1700560692
Edition: cre
Level: 1
Version: 2.3.0b1
With this werk the postfix status service is not discovered if Postfix is not running.
The default mail queue is now discovered as "Postfix Status default".
------------------------------------<diff>-------------------------------------------
Title: postfix_mailq_status: Rework discovery
Class: fix
- Compatible: incomp
? --
+ Compatible: compat
? ++
Component: checks
Date: 1700560692
Edition: cre
Level: 1
Version: 2.3.0b1
With this werk the postfix status service is not discovered if Postfix is not running.
The default mail queue is now discovered as "Postfix Status default".
- In order to make the check plugin work you have to perform a re-discovery on the affected hosts.
- Otherwise, the service "Postfix Status" (dicovered before this change) will stop working.
-
[//]: # (werk v2)
# postfix_mailq: Rename "Postfix Queue" to "Postfix Queue default"
key | value
---------- | ---
date | 2024-02-01T08:44:18+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This affects users monitoring hosts that run one single postfix instance.
For new installations, the service "Postfix Queue" will be renamed to "Postfix Queue default".
In general, Checkmk is able to monitor multiple postfix instances running on the monitored host.
This will change the name in the common case where users are not running multiple postfix instances, but only the "default" one.
If you want to switch to the new service description after an upgrade, you can do so using the setting "Use new service descriptions".
Be aware that you will lose the historic data in case you do that.
Werk 15694 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Remove mod_auth_mellon
Class: feature
Compatible: incomp
Component: omd
Date: 1693380015
Edition: cre
Knowledge: undoc
Level: 1
Version: 2.3.0b1
With Checkmk 2.2, announced by Werk #14977, the usage of mod_auth_mellon was deprecated. This release now removes mod_auth_mellon.
If you still have mod_auth_mellon in your apache config, the apache service will not be able to start.
Errors are logged to <tt>var/log/apache2/error_log</tt>.
If you want to continue to use SAML you can do it in the Enterprise Edition via <i>Setup -> Users -> SAML connections</i>.
------------------------------------<diff>-------------------------------------------
Title: Remove mod_auth_mellon
Class: feature
Compatible: incomp
Component: omd
Date: 1693380015
Edition: cre
Knowledge: undoc
Level: 1
Version: 2.3.0b1
With Checkmk 2.2, announced by Werk #14977, the usage of mod_auth_mellon was deprecated. This release now removes mod_auth_mellon.
If you still have mod_auth_mellon in your apache config, the apache service will not be able to start.
- Errors are logged to <tt>var/lib/apache2/error_log</tt>.
? ^^
+ Errors are logged to <tt>var/log/apache2/error_log</tt>.
? ^^
If you want to continue to use SAML you can do it in the Enterprise Edition via <i>Setup -> Users -> SAML connections</i>.
[//]: # (werk v2)
# notification_rule: cancel previous notifications now working with custom plugin scripts
key | value
---------- | ---
date | 2024-01-31T15:15:29+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
When creating or updating notification rules, the option to "cancel_previous_notifications"
was previously not available when the plugin name selected was a custom plugin script.
This werk addresses this issue and now allows for custom plugin scripts when setting the
option to cancel.
[//]: # (werk v2)
# netapp_ontap_psu: fix discovery ruleset
key | value
---------- | ---
date | 2024-01-31T13:08:07+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | no
This problem affected users who wanted to discover the 'summary' mode of PSU service: it was not possible to configure the appropriate discovery rule. This werk fixes this behaviour.
A rediscovery is required for the change to take effect.
[//]: # (werk v2)
# agent_bakery: mk_postgres.py: restore required keys
key | value
---------- | ---
date | 2024-02-01T06:19:27+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
[Werk #15645](https://checkmk.com/werk/15645) made the Inputs of "Instance
settings" of the Agent rule "PostgreSQL database and sessions (Linux, Windows)"
optional by accident. If you did not specify all keys, baking agents failed with
a `KeyError` on the automation call.
[//]: # (werk v2)
# authentication: remove user profile dir when unknown user and failed to login
key | value
---------- | ---
date | 2024-01-26T15:59:51+00:00
version | 2.3.0b1
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Previously, failed login attempts with an unknown user would create a
user profile directory. This is no longer the case. The profile
directory is now only created for valid users.
[//]: # (werk v2)
# tag_group: change the identification field from 'ident' to 'id'
key | value
---------- | ---
date | 2024-01-29T13:13:54+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
Before this Werk, when creating a tag group, the **ident** field was used to provide its identification as well as that of the tags associated to the group, however the information was returned in the **id** field. This Werk unifies the names and now the **ident** fields are renamed to **id**. Users should adapt their scripts accordingly.
For comptatibility reasons CheckMK 2.2.0 and 2.3.0 will support both **id** and **ident**, but **ident** will be removed on the next version.
The following example shows the changes that need to be applied to the payload to use this endpoint:
Original payload:
```json
{
"ident": "test_group",
"title": "Test group",
"help_text": "My test groupd",
"tags": [
{"ident": "test", "title": "Test Tag"}
]
}
```
Updated payload:
```json
{
"id": "test_group",
"title": "Test group",
"help_text": "My test groupd",
"tags": [
{"id": "test", "title": "Test Tag"}
]
}
```
Werk 16384 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# notification rule: allow for non builtin service levels
key | value
---------- | ---
date | 2024-01-17T11:19:06+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
```
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver", "to_level": "gold"}
}
}
```
New schema
```
{"match_service_levels: {
"state": "enabled",
"value": {"from_level": 10, "to_level": 20}
}
}
```
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# notification rule: allow for non builtin service levels
key | value
---------- | ---
date | 2024-01-17T11:19:06+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
```
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver", "to_level": "gold"}
}
}
```
New schema
```
{"match_service_levels: {
"state": "enabled",
- "value": {"from_level" 10, "to_level": 20}
+ "value": {"from_level": 10, "to_level": 20}
? +
}
}
```