Checkmk werks level1 January 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
231 discussions

[2.2.0] Checkmk Werk 16464 created: update action: resolve error during sync of automationuser secrets

by Checkmk werks level 1

Title: update action: resolve error during sync of automationuser secrets Class: fix Compatible: compat Component: wato Date: 1705944989 Edition: cre Level: 1 Version: 2.2.0p20 During the update config process, the step 'Synchronize automationuser secrets' could fail when a deleted automation user still had its 'var/check_mk/web/' profile present. This werk now correctly resolves this issue.

9 months, 2 weeks

[2.2.0] Checkmk Werk 16287 created: rule_notification: match_hosttag now accepts custom tag ids

by Checkmk werks level 1

Title: rule_notification: match_hosttag now accepts custom tag ids Class: fix Compatible: incomp Component: rest-api Date: 1705077038 Edition: cre Level: 1 Version: 2.2.0p20 Previously, when creating or updating a notification rule, the match_host_tag field would only allow for builtin tag ids. With this werk we now accept any configured host tag id. The schema has also changed in order to make this possible. This means that instead of a field representing each tag, you now have to pass a list of aux tag ids/tag group tag ids along with an operator. This way we can determine if the tag id should match or not. e.g. C+: { "match_host_tags": { "state": "enabled", "value": [ { "tag_type": "aux_tag", "tag_id": "snmp", "operator": "is_set", }, { "tag_type": "tag_group", "tag_group_id": "criticality", "operator": "is", "tag_id": "prod", }, { "tag_type": "tag_group", "tag_group_id": "networking", "operator": "is_not", "tag_id": "lan", } ], }, } C-:

9 months, 2 weeks

[2.3.0] Checkmk Werk 16464 created: update action: resolve error during sync of automationuser secrets

by Checkmk werks level 1

[//]: # (werk v2) # update action: resolve error during sync of automationuser secrets key | value ---------- | --- date | 2024-01-22T17:36:29+00:00 version | 2.3.0b1 class | fix edition | cre component | wato level | 1 compatible | yes During the update config process, the step 'Synchronize automationuser secrets' could fail when a deleted automation user still had its 'var/check_mk/web/' profile present. This werk now correctly resolves this issue.

9 months, 2 weeks

[2.3.0] Checkmk Werk 16287 created: rule_notification: match_hosttag now accepts custom tag ids

by Checkmk werks level 1

[//]: # (werk v2) # rule_notification: match_hosttag now accepts custom tag ids key | value ---------- | --- date | 2024-01-12T16:30:38+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no Previously, when creating or updating a notification rule, the match_host_tag field would only allow for builtin tag ids. With this werk we now accept any configured host tag id. The schema has also changed in order to make this possible. This means that instead of a field representing each tag, you now have to pass a list of aux tag ids/tag group tag ids along with an operator. This way we can determine if the tag id should match or not. e.g. ``` { "match_host_tags": { "state": "enabled", "value": [ { "tag_type": "aux_tag", "tag_id": "snmp", "operator": "is_set", }, { "tag_type": "tag_group", "tag_group_id": "criticality", "operator": "is", "tag_id": "prod", }, { "tag_type": "tag_group", "tag_group_id": "networking", "operator": "is_not", "tag_id": "lan", } ], }, } ```

9 months, 2 weeks

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

by Checkmk werks level 1

Werk 14617 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: check_uniserv: running the active check results in exception "TypeError: a bytes-like object is required, not 'str'" Class: fix Compatible: compat Component: checks Date: 1705503976 Edition: cre Level: 1 Version: 2.2.0p21 <code>check_uniserv</code> implementation didn't encode the <code>close</code> command resulting in an exception <code>TypeError: a bytes-like object is required, not 'str'</code> being raised. This change adds the missing encoding among some general modernization. ------------------------------------<diff>------------------------------------------- Title: check_uniserv: running the active check results in exception "TypeError: a bytes-like object is required, not 'str'" Class: fix Compatible: compat Component: checks Date: 1705503976 Edition: cre Level: 1 - Version: 2.2.0p20 ? ^ + Version: 2.2.0p21 ? ^ <code>check_uniserv</code> implementation didn't encode the <code>close</code> command resulting in an exception <code>TypeError: a bytes-like object is required, not 'str'</code> being raised. This change adds the missing encoding among some general modernization.

9 months, 3 weeks

[2.2.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. Title: notification rule: allow for non builtin service levels Class: fix Compatible: incomp Component: rest-api Date: 1705490346 Edition: cre Level: 1 Version: 2.2.0p21 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>------------------------------------------- Title: notification rule: allow for non builtin service levels Class: fix Compatible: incomp Component: rest-api Date: 1705490346 Edition: cre Level: 1 - Version: 2.2.0p20 ? ^ + Version: 2.2.0p21 ? ^ 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} } } ```

9 months, 3 weeks

[2.2.0] Checkmk Werk 16025 adapted: Update PHP version in SLES15SP3 from 7 to 8

by Checkmk werks level 1

Werk 16025 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Update PHP version in SLES15SP3 from 7 to 8 Class: fix Compatible: incomp Component: rpm Date: 1701254497 Edition: cre Level: 2 Version: 2.2.0p21 Checkmk was shipped with a dependency to PHP7 for SLES15SP3. Since PHP7 is part of the legacy module, this Werk updates the dependency from PHP7 to PHP8. As SLES only allows one version of PHP to be installed, the following steps will uninstall PHP7 from the system and install the new version of Checkmk with PHP8. Be aware that this procedure updates PHP from version 7 to 8 for the whole OS. In case you run additional PHP applications next to Checkmk, the update will also affect them. Run the following commands to perform the update to the new Checkmk version: * add SLES-15SP4 repo to get PHP8 with <tt>zypper addrepo https://updates.suse.com/SUSE/Products/SLE-BCI/15-SP4/x86_64/product/ sles15sp4</tt> * install the new Checkmk version with <tt>zypper install NEW_CHECKMK.rpm</tt> * Zypper will now complain about a conflict with several PHP packages and asks you to select a solution. There, select <tt>solution 1</tt> to confirm the deinstallation of the current Checkmk version, the PHP7 modules and to continue with the installation * confirm the installation of the new Checkmk version and PHP8 with <tt>yes</tt> * removing the existing Checkmk version will throw an error like `Site <SITENAME> is still using this version! Removal of <OLD_CHECKMK>(@System) failed:`, proceed by choosing <tt>ignore</tt> which creates a inconsistent state for the old Checkmk version package, which we will resolve in a later step. * PHP7 will be removed and PHP8 gets installed * change to the site user with <tt>omd su SITE_NAME</tt> * stop the site with <tt>omd stop</tt> * perform the update to the new Checkmk version with <tt>omd update</tt>, select <tt>Update</tt> at the user prompt * in case further prompts regarding wrong permissions of BUILD files appear, choose the default value with <tt>d</tt> * start the site again with <tt>omd start</tt> * exit from the site user * list all installed Checkmk version with <tt>omd versions</tt> * finally remove the old Checkmk installation with <tt>zypper remove OLD_CHECKMK</tt> ------------------------------------<diff>------------------------------------------- Title: Update PHP version in SLES15SP3 from 7 to 8 Class: fix Compatible: incomp Component: rpm Date: 1701254497 Edition: cre Level: 2 - Version: 2.2.0p20 ? ^ + Version: 2.2.0p21 ? ^ Checkmk was shipped with a dependency to PHP7 for SLES15SP3. Since PHP7 is part of the legacy module, this Werk updates the dependency from PHP7 to PHP8. As SLES only allows one version of PHP to be installed, the following steps will uninstall PHP7 from the system and install the new version of Checkmk with PHP8. Be aware that this procedure updates PHP from version 7 to 8 for the whole OS. In case you run additional PHP applications next to Checkmk, the update will also affect them. Run the following commands to perform the update to the new Checkmk version: * add SLES-15SP4 repo to get PHP8 with <tt>zypper addrepo https://updates.suse.com/SUSE/Products/SLE-BCI/15-SP4/x86_64/product/ sles15sp4</tt> * install the new Checkmk version with <tt>zypper install NEW_CHECKMK.rpm</tt> * Zypper will now complain about a conflict with several PHP packages and asks you to select a solution. There, select <tt>solution 1</tt> to confirm the deinstallation of the current Checkmk version, the PHP7 modules and to continue with the installation * confirm the installation of the new Checkmk version and PHP8 with <tt>yes</tt> * removing the existing Checkmk version will throw an error like `Site <SITENAME> is still using this version! Removal of <OLD_CHECKMK>(@System) failed:`, proceed by choosing <tt>ignore</tt> which creates a inconsistent state for the old Checkmk version package, which we will resolve in a later step. * PHP7 will be removed and PHP8 gets installed * change to the site user with <tt>omd su SITE_NAME</tt> * stop the site with <tt>omd stop</tt> * perform the update to the new Checkmk version with <tt>omd update</tt>, select <tt>Update</tt> at the user prompt * in case further prompts regarding wrong permissions of BUILD files appear, choose the default value with <tt>d</tt> * start the site again with <tt>omd start</tt> * exit from the site user * list all installed Checkmk version with <tt>omd versions</tt> * finally remove the old Checkmk installation with <tt>zypper remove OLD_CHECKMK</tt>

9 months, 3 weeks

[2.2.0] Checkmk Werk 16444 adapted: EC: Fix missing configuration files

by Checkmk werks level 1

Werk 16444 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: EC: Fix missing configuration files Class: fix Compatible: compat Component: ec Date: 1705915976 Edition: cee Level: 1 Version: 2.2.0p21 With werk 16012 the event console rules are filtered and saved to the location var/mkeventd/active_config during activate changes. Unfortunatelly other configuration files like global.mk are missing which are now copied recursively, too. ------------------------------------<diff>------------------------------------------- Title: EC: Fix missing configuration files Class: fix Compatible: compat Component: ec Date: 1705915976 Edition: cee Level: 1 - Version: 2.2.0p20 ? ^ + Version: 2.2.0p21 ? ^ With werk 16012 the event console rules are filtered and saved to the location var/mkeventd/active_config during activate changes. Unfortunatelly other configuration files like global.mk are missing which are now copied recursively, too.

9 months, 3 weeks

[2.2.0] Checkmk Werk 16071 adapted: Notification spooler: Fix ignored timing settings for specific methods

by Checkmk werks level 1

Werk 16071 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Notification spooler: Fix ignored timing settings for specific methods Class: fix Compatible: incomp Component: notifications Date: 1699356565 Edition: cee Level: 1 Version: 2.2.0p21 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. ------------------------------------<diff>------------------------------------------- Title: Notification spooler: Fix ignored timing settings for specific methods Class: fix Compatible: incomp Component: notifications Date: 1699356565 Edition: cee Level: 1 - Version: 2.2.0p20 ? ^ + Version: 2.2.0p21 ? ^ 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.

9 months, 3 weeks

[2.2.0] Checkmk Werk 16292 adapted: user_config: add verification for contact groups and locked attributes

by Checkmk werks level 1

Werk 16292 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: user_config: add verification for contact groups and locked attributes Class: fix Compatible: compat Component: rest-api Date: 1705416141 Edition: cre Knowledge: doc Level: 1 Version: 2.2.0p21 This werk introduces two changes: LI: it now verifies for create & edit if the provided contact groups actually exist LI: it verifies that for an edit request, locked attributes are not being modified ------------------------------------<diff>------------------------------------------- Title: user_config: add verification for contact groups and locked attributes Class: fix Compatible: compat Component: rest-api Date: 1705416141 Edition: cre Knowledge: doc Level: 1 - Version: 2.2.0p20 ? ^ + Version: 2.2.0p21 ? ^ This werk introduces two changes: LI: it now verifies for create & edit if the provided contact groups actually exist LI: it verifies that for an edit request, locked attributes are not being modified

9 months, 3 weeks

← Newer
1
...
6
7
8
9
10
11
12
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 January 2024