Checkmk werks level1 July 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
398 discussions

[2.3.0] Checkmk Werk 16589 adapted: Monitor Redfish compatible management boards / BMCs via optional MKP

by Checkmk werks level 1

Werk 16589 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Monitor Redfish compatible management boards / BMCs via optional MKP key | value ---------- | --- date | 2024-03-06T16:44:06+00:00 version | 2.3.0b3 class | feature edition | cre component | checks level | 1 compatible | yes You can now monitor _Redfish_ compatible management boards / BMCs with Checkmk. To do so, please enable the natively shipped MKP redfish in _Setup --> Extension packages_ (in commercial editions of Checkmk) or via the command line tool `mkp` (in Checkmk Raw). This will enable a new datasource program under _Setup --> Other integrations --> Redfish Compatible Management Controller_. This is an experimental integration created and supported by the Checkmk community (Andreas Döhler/Yogibaer75), which has already been tested in many environments. However, due to the diverse nature of server hardware, we plan to integrate it entirely for Checkmk 2.4.0, once we have gathered further feedback. You can find the latest versions of the extensions in [Andreas' GitHub repository](https://github.com/Yogibaer75/Check_MK-Things/tree/master/check…. There you can also raise issues or raise pull requests until the plug-ins will be mainlined into Checkmk. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Monitor Redfish compatible management boards / BMCs via optional MKP key | value ---------- | --- date | 2024-03-06T16:44:06+00:00 version | 2.3.0b3 class | feature edition | cre component | checks level | 1 compatible | yes You can now monitor _Redfish_ compatible management boards / BMCs with Checkmk. To do so, please enable the natively shipped MKP redfish in _Setup --> Extension packages_ (in commercial editions of Checkmk) or via the command line tool `mkp` (in Checkmk Raw). This will enable a new datasource program under _Setup --> Other integrations --> Redfish Compatible Management Controller_. - This is an experimental integration created by the Checkmk community (Andreas Döhler from Bechtle), which has already been tested in many environments. ? ^^ ^^^^^^^^^^ + This is an experimental integration created and supported by the Checkmk community (Andreas Döhler/Yogibaer75), which has already been tested in many environments. ? ++++++++++++++ ^^^^^^^^ ^^ However, due to the diverse nature of server hardware, we plan to integrate it entirely for Checkmk 2.4.0, once we have gathered further feedback. + You can find the latest versions of the extensions in [Andreas' GitHub repository](https://github.com/Yogibaer75/Check_MK-Things/tree/master/check…. There you can also raise issues or raise pull requests until the plug-ins will be mainlined into Checkmk. +

2 months, 2 weeks

[2.3.0] Checkmk Werk 16431 adapted: omd restore: Fix RuntimeError: Failed to determine site version

by Checkmk werks level 1

Werk 16431 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # omd restore: Fix RuntimeError: Failed to determine site version key | value ---------- | --- compatible | yes version | 2.3.0p10 date | 2024-06-11T12:03:43+00:00 level | 1 class | fix component | omd edition | cre Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail: ``` File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar old_site.replacements(), ^^^^^^^^^^^^^^^^^^^^^^^ File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements raise RuntimeError("Failed to determine site version") ``` The failure only occured, if the user provided a site name, which differed from the original name, and the original site did no longer exist. This crash also affected the `Migrate existing Site` function of the appliance. If you are affected by this crash, but are unable to update, then you can start be restoring the site without a new name. The site can then be renamed with `omd mv`. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # omd restore: Fix RuntimeError: Failed to determine site version key | value ---------- | --- compatible | yes - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ date | 2024-06-11T12:03:43+00:00 level | 1 class | fix component | omd edition | cre Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail: ``` File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar old_site.replacements(), ^^^^^^^^^^^^^^^^^^^^^^^ File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements raise RuntimeError("Failed to determine site version") ``` The failure only occured, if the user provided a site name, which differed from the original name, and the original site did no longer exist. This crash also affected the `Migrate existing Site` function of the appliance. If you are affected by this crash, but are unable to update, then you can start be restoring the site without a new name. The site can then be renamed with `omd mv`.

2 months, 2 weeks

[2.3.0] Checkmk Werk 17076 adapted: Fix float rule values not checking all validations

by Checkmk werks level 1

Werk 17076 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Fix float rule values not checking all validations key | value ---------- | --- date | 2024-06-25T07:08:34+00:00 version | 2.3.0p10 class | fix edition | cre component | wato level | 1 compatible | no In Checkmk, it's possible for any rule value to specify custom validation functions to stop users from accidentally entering invalid data. Before this werk, the set of rule fields that allowed floating point values to be set in rare cases did not check these custom validation functions when setting up a rule. With this werk, we restore the expected functionality and check the validity of all floating point values in a rule. **Incompatibility** Some users might have created rules which should not have been valid. You will find out if such a rule is present in your setup when you update your site. The update process will raise an error warning you of any rule values that break custom validators. This error will tell you about the invalid rule and the reason it is invalid. Please abort the update process, fix the invalid value and restart the update process. **Plugin developers** If you have created a rule value with the `validate` (ValueSpec) or `custom_validate` (Form Spec) argument set, your rule will now correctly use provided functions to check the validity of the data. No change to the rule is necessary. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Fix float rule values not checking all validations key | value ---------- | --- date | 2024-06-25T07:08:34+00:00 - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ class | fix edition | cre component | wato level | 1 compatible | no In Checkmk, it's possible for any rule value to specify custom validation functions to stop users from accidentally entering invalid data. Before this werk, the set of rule fields that allowed floating point values to be set in rare cases did not check these custom validation functions when setting up a rule. With this werk, we restore the expected functionality and check the validity of all floating point values in a rule. **Incompatibility** Some users might have created rules which should not have been valid. You will find out if such a rule is present in your setup when you update your site. The update process will raise an error warning you of any rule values that break custom validators. This error will tell you about the invalid rule and the reason it is invalid. Please abort the update process, fix the invalid value and restart the update process. **Plugin developers** If you have created a rule value with the `validate` (ValueSpec) or `custom_validate` (Form Spec) argument set, your rule will now correctly use provided functions to check the validity of the data. No change to the rule is necessary.

2 months, 2 weeks

[2.3.0] Checkmk Werk 16533 adapted: Event Console fix regex match in rule text

by Checkmk werks level 1

Werk 16533 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Event Console fix regex match in rule text key | value ---------- | --- date | 2024-07-01T15:31:04+00:00 version | 2.3.0p10 class | fix edition | cee component | ec level | 1 compatible | yes Event console method compile_matching_value had a typo which caused a valid regex to not match, because it was sent as a string SUP-19224 ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Event Console fix regex match in rule text key | value ---------- | --- date | 2024-07-01T15:31:04+00:00 - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ class | fix edition | cee component | ec level | 1 compatible | yes Event console method compile_matching_value had a typo which caused a valid regex to not match, because it was sent as a string SUP-19224

2 months, 2 weeks

[2.3.0] Checkmk Werk 16863 adapted: proxmox: Fix log parsing crash for Proxmox versions 3.2.4 and newer

by Checkmk werks level 1

Werk 16863 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # proxmox: Fix log parsing crash for Proxmox versions 3.2.4 and newer key | value ---------- | --- compatible | yes version | 2.3.0p10 date | 2024-06-28T14:34:01+00:00 level | 1 class | fix component | checks edition | cre The backup log format changed in Proxmox version 3.2.4 which resulted in a crash in the Proxmox special agent. The special agent can now handle both old and the new format of backup log messages. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # proxmox: Fix log parsing crash for Proxmox versions 3.2.4 and newer key | value ---------- | --- compatible | yes - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ date | 2024-06-28T14:34:01+00:00 level | 1 class | fix component | checks edition | cre The backup log format changed in Proxmox version 3.2.4 which resulted in a crash in the Proxmox special agent. The special agent can now handle both old and the new format of backup log messages.

2 months, 2 weeks

[2.3.0] Checkmk Werk 17119 adapted: parent_scan: resolve failing parent scan background job

by Checkmk werks level 1

Werk 17119 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # parent_scan: resolve failing parent scan background job key | value ---------- | --- date | 2024-07-02T12:39:27+00:00 version | 2.3.0p10 class | fix edition | cre component | rest-api level | 1 compatible | yes The REST API endpoint to initiate the parent scan background job returned a 204 status code, which theoretically is correct. However, the started background job failed immediately due to an invalid Python syntax concerning the involving requested hosts. This werk fixes the issue. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # parent_scan: resolve failing parent scan background job key | value ---------- | --- date | 2024-07-02T12:39:27+00:00 - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ class | fix edition | cre component | rest-api level | 1 compatible | yes The REST API endpoint to initiate the parent scan background job returned a 204 status code, which theoretically is correct. However, the started background job failed immediately due to an invalid Python syntax concerning the involving requested hosts. This werk fixes the issue.

2 months, 2 weeks

[2.3.0] Checkmk Werk 17010 adapted: XSS in SQL check parameters

by Checkmk werks level 1

Werk 17010 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # XSS in SQL check parameters key | value ---------- | --- date | 2024-06-17T10:08:19+00:00 version | 2.3.0p10 class | security edition | cre component | wato level | 1 compatible | yes Prior to this Werk an attacher could add HTML to one parameter of the *Check SQL database* rule which was executed on the overview page. We found this vulnerability internally. **Affected Versions**: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) **Indicators of Compromis**: The creation of such rules is logged in the audit log. You can therefore check the `wato_audit.log` either on the terminal or in the UI for entries that contain malicious HTML. **Vulnerability Management**: We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L` We assigned CVE-2024-6052 to this vulnerability. **Changes**: This Werk fixes the escaping. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # XSS in SQL check parameters key | value ---------- | --- date | 2024-06-17T10:08:19+00:00 - version | 2.3.0p8 ? ^ + version | 2.3.0p10 ? ^^ class | security edition | cre component | wato level | 1 compatible | yes Prior to this Werk an attacher could add HTML to one parameter of the *Check SQL database* rule which was executed on the overview page. We found this vulnerability internally. **Affected Versions**: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) **Indicators of Compromis**: The creation of such rules is logged in the audit log. You can therefore check the `wato_audit.log` either on the terminal or in the UI for entries that contain malicious HTML. **Vulnerability Management**: We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L` We assigned CVE-2024-6052 to this vulnerability. **Changes**: This Werk fixes the escaping.

2 months, 2 weeks

[2.3.0] Checkmk Werk 16753 adapted: HW/SW Inventory: Fix missing joined service columns if a service is assigned to a cluster

by Checkmk werks level 1

Werk 16753 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # HW/SW Inventory: Fix missing joined service columns if a service is assigned to a cluster key | value ---------- | --- date | 2024-07-01T14:32:58+00:00 version | 2.3.0p10 class | fix edition | cre component | multisite level | 1 compatible | yes ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # HW/SW Inventory: Fix missing joined service columns if a service is assigned to a cluster key | value ---------- | --- date | 2024-07-01T14:32:58+00:00 - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ class | fix edition | cre component | multisite level | 1 compatible | yes

2 months, 2 weeks

[2.3.0] Checkmk Werk 16864 adapted: snmp: Fix error in SNMP context serialization introduced with werk 16862

by Checkmk werks level 1

Werk 16864 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # snmp: Fix error in SNMP context serialization introduced with werk 16862 key | value ---------- | --- date | 2024-07-03T07:48:10+00:00 version | 2.3.0p10 class | fix edition | cre component | checks level | 1 compatible | yes Werk 16862, which solved one SNMP context serialization bug, introduced another one. When using SNMP contexts, the change activation crashes in 2.3.0p8. After this Werk, SNMP contexts should work without errors. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # snmp: Fix error in SNMP context serialization introduced with werk 16862 key | value ---------- | --- date | 2024-07-03T07:48:10+00:00 - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ class | fix edition | cre component | checks level | 1 compatible | yes Werk 16862, which solved one SNMP context serialization bug, introduced another one. When using SNMP contexts, the change activation crashes in 2.3.0p8. After this Werk, SNMP contexts should work without errors.

2 months, 2 weeks

[2.3.0] Checkmk Werk 17016 adapted: notification_rules: typo in field sort_order_for_bulk_notifications

by Checkmk werks level 1

Werk 17016 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # notification_rules: typo in field sort_order_for_bulk_notifications key | value ---------- | --- date | 2024-07-03T05:22:21+00:00 version | 2.3.0p10 class | fix edition | cre component | rest-api level | 1 compatible | no The REST-API endpoints previously had a typo in the field 'sort_order_for_bulk_notifications'. The second t was missing. This werk now corrects this. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # notification_rules: typo in field sort_order_for_bulk_notifications key | value ---------- | --- date | 2024-07-03T05:22:21+00:00 - version | 2.3.0p9 ? ^ + version | 2.3.0p10 ? ^^ class | fix edition | cre component | rest-api level | 1 compatible | no The REST-API endpoints previously had a typo in the field 'sort_order_for_bulk_notifications'. The second t was missing. This werk now corrects this.

2 months, 2 weeks

← Newer
1
...
30
31
32
33
34
35
36
...
40
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 July 2024