Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15938 discussions

[2.3.0] Checkmk Werk 14617 created: check_uniserv: running the active check results in exception "TypeError: a bytes-like object is required, not 'str'"

by Checkmk werks level 1

[//]: # (werk v2) # check_uniserv: running the active check results in exception "TypeError: a bytes-like object is required, not 'str'" key | value ---------- | --- date | 2024-01-17T15:06:16+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes `check_uniserv` implementation didn't encode the `close` command resulting in an exception `TypeError: a bytes-like object is required, not 'str'` being raised. This change adds the missing encoding among some general modernization.

8 months, 1 week

[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 - C+: + ``` {"match_service_levels": { "state": "enabled", "value": {"from_level": "silver", "to_level": "gold"} } } - C-: + ``` New schema - C+: + ``` {"match_service_levels: { "state": "enabled", "value": {"from_level" 10, "to_level": 20} } } - C-: + ```

8 months, 1 week

[2.2.0] Checkmk Werk 16386 created: notification rule: match service levels and match time period being saved with wrong key

by Checkmk werks level 1

Title: notification rule: match service levels and match time period being saved with wrong key Class: fix Compatible: compat Component: rest-api Date: 1705664610 Edition: cre Level: 1 Version: 2.2.0p20 Previously when creating or updating an notification rule via the rest-api, the matching conditions for service levels and time periods were being saved to file with an incorrect key. This werk addresses this issue by correcting the keys being saved.

8 months, 1 week

[2.3.0] Checkmk Werk 16375 adapted: Rule "Check Email": Allow all makros

by Checkmk werks level 1

Werk 16375 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Rule "Check Email": Allow all makros key | value ---------- | --- date | 2024-01-15T13:59:03+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The ruleset "Check Email" recently featured stricter validation. As a result, macros (like `$HOSTNAME$`) could not be used anymore. This was partially compensated for in [#15203](https://checkmk.com/werk/15203), but this was still too restrictive. Users can now configure validated host adresses or unvalidated strings containing macros. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Rule "Check Email": Allow all makros key | value ---------- | --- date | 2024-01-15T13:59:03+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes The ruleset "Check Email" recently featured stricter validation. - As a result, no makros (like `$HOSTNAME$`) could be used anymore. ? --- ^ + As a result, macros (like `$HOSTNAME$`) could not be used anymore. ? ^ ++++ This was partially compensated for in [#15203](https://checkmk.com/werk/15203), but this was still too restrictive. Users can now configure validated host adresses or unvalidated strings containing macros.

8 months, 1 week

[2.3.0] Checkmk Werk 16386 created: notification rule: match service levels and match time period being saved with wrong key

by Checkmk werks level 1

[//]: # (werk v2) # notification rule: match service levels and match time period being saved with wrong key key | value ---------- | --- date | 2024-01-19T11:43:30+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Previously when creating or updating an notification rule via the rest-api, the matching conditions for service levels and time periods were being saved to file with an incorrect key. This werk addresses this issue by correcting the keys being saved.

8 months, 1 week

[2.1.0] Checkmk Werk 15745 created: Checkmk now redacts site secrets during support diagnostics generation

by Checkmk werks level 1

Title: Checkmk now redacts site secrets during support diagnostics generation Class: feature Compatible: compat Component: multisite Date: 1705564261 Edition: cee Level: 1 Version: 2.1.0p39 Prior to this werk, generating a support diagnostic for deployments with distributed monitoring of multiple Checkmk instances would expose site secrets within the "etc/check_mk/multisite.d/sites.mk" file. All site secrets are now replaced with "redacted" during the generation process of support diagnostics (Setup > Maintenance > Support diagnostics) where Checkmk Configuration files have been selected with at least low sensitivity or the sites.mk file has been selected individually.

8 months, 1 week

[2.1.0] Checkmk Werk 16071 created: Notification spooler: Fix ignored timing settings for specific methods

by Checkmk werks level 1

Title: Notification spooler: Fix ignored timing settings for specific methods Class: fix Compatible: incomp Component: notifications Date: 1699356565 Edition: cee Level: 1 Version: 2.1.0p39 If you used notification spooling and configured "Timing settings for specific methods" in the global settings option "Notification Spooler Configuration", the settings "Maximum number of delivery attempts" and "Timeout" had no effect. The notification methods were executed until they succeded. Please note: This change can cause changes in the notification spooling, please check if the behaviour still matches your needs. Otherwise you would have to adjust the mentioned settings again.

8 months, 1 week

[2.1.0] Checkmk Werk 16075 created: Notification spooler: Fix possible wrong order of notification processing

by Checkmk werks level 1

Title: Notification spooler: Fix possible wrong order of notification processing Class: fix Compatible: compat Component: notifications Date: 1700481159 Edition: cee Level: 1 Version: 2.1.0p39 The notification spooler used the mtime of the spool files to determine the order of execution. In rare cases, the mtime was too imprecise so we now use the mtime in nanoseconds.

8 months, 1 week

[2.1.0] Checkmk Werk 16375 created: Rule "Check Email": Allow all makros

by Checkmk werks level 1

Title: Rule "Check Email": Allow all makros Class: fix Compatible: compat Component: checks Date: 1705327143 Edition: cre Level: 1 Version: 2.1.0p39 The ruleset "Check Email" recently featured stricter validation. As a result, no makros (like <code>$HOSTNAME$</code>) could be used anymore. This was partially compensated for in <a href="https://checkmk.com/werk/15203">#15203</a>, but this was still too restrictive. Users can now configure validated host adresses or unvalidated strings containing macros.

8 months, 1 week

[2.1.0] Checkmk Werk 16385 created: revert_changes: internal changes can be reverted only if the user has the correct permission

by Checkmk werks level 1

Title: revert_changes: internal changes can be reverted only if the user has the correct permission Class: fix Compatible: compat Component: wato Date: 1705491719 Edition: cre Level: 1 Version: 2.1.0p39 Changes made by the checkmk internal user can now only be reverted when the logged-in user has the permission "Discard foreign changes".

8 months, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1