Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15938 discussions

[2.3.0] Checkmk Werk 16398 created: mk_jolokia: Respect Timeout Settings

by Checkmk werks level 1

[//]: # (werk v2) # mk_jolokia: Respect Timeout Settings key | value ---------- | --- date | 2024-01-23T09:28:00+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously, passing a timeout parameter the agent plugin `mk_jolokia` had no effect. This has been fixed.

8 months, 1 week

[2.3.0] Checkmk Werk 16397 created: special_zerto: Error Message in Check_MK HW/SW Inventory

by Checkmk werks level 1

[//]: # (werk v2) # special_zerto: Error Message in Check_MK HW/SW Inventory key | value ---------- | --- date | 2024-01-23T08:14:35+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously, the agent special_zerto would show the following error message in the Check_MK HW/SW Inventory ``` NOOPParser: Ignoring invalid data b'<<<zerto_agent:sep(0)>>>Initialized OK<<<<host1.example.com>>>> ``` Moreover, the service `Zerto Agent Status` was not discoverable and some piggyback data would incorrectly be mapped to the source host. This is now fixed.

8 months, 1 week

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

by Checkmk werks level 1

Werk 16287 was adapted. The following is the new Werk, a diff is shown at the end of the message. 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.0p21 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-: ------------------------------------<diff>------------------------------------------- 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 ? ^ + Version: 2.2.0p21 ? ^ 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-:

8 months, 1 week

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

8 months, 1 week

[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-:

8 months, 1 week

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

8 months, 1 week

[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", } ], }, } ```

8 months, 1 week

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

8 months, 1 week

[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} } } ```

8 months, 1 week

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

8 months, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1