Checkmk werks level1 February 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
287 discussions

[2.4.0] Checkmk Werk 16390 created: notification_rule: cancel previous notifications now working with custom plugin scripts

by Checkmk werks level 1

[//]: # (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.4.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.

5 months, 3 weeks

[2.4.0] Checkmk Werk 15324 created: agent_bakery: mk_postgres.py: restore required keys

by Checkmk werks level 1

[//]: # (werk v2) # agent_bakery: mk_postgres.py: restore required keys key | value ---------- | --- date | 2024-02-01T06:19:27+00:00 version | 2.4.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.

5 months, 3 weeks

[2.3.0] Checkmk Werk 16389 created: authentication: remove user profile dir when unknown user and failed to login

by Checkmk werks level 1

[//]: # (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.

5 months, 3 weeks

[2.4.0] Checkmk Werk 16325 created: netapp_ontap_psu: fix discovery ruleset

by Checkmk werks level 1

[//]: # (werk v2) # netapp_ontap_psu: fix discovery ruleset key | value ---------- | --- date | 2024-01-31T13:08:07+00:00 version | 2.4.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.

5 months, 3 weeks

[2.4.0] Checkmk Werk 16364 created: tag_group: change the identification field from 'ident' to 'id'

by Checkmk werks level 1

[//]: # (werk v2) # tag_group: change the identification field from 'ident' to 'id' key | value ---------- | --- date | 2024-01-29T13:13:54+00:00 version | 2.4.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"} ] } ```

5 months, 3 weeks

[2.3.0] Checkmk Werk 15694 adapted: Remove mod_auth_mellon

by Checkmk werks level 1

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>.

5 months, 3 weeks

[2.3.0] Checkmk Werk 16384 adapted: notification rule: allow for non builtin service levels

by Checkmk werks level 1

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} ? + } } ```

5 months, 3 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 February 2024