Checkmk werks level1 June 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
272 discussions

[2.1.0] Checkmk Werk 16989 created: NagVis: Updated to 1.9.41

by Checkmk werks level 1

Title: NagVis: Updated to 1.9.41 Class: fix Compatible: compat Component: packages Date: 1717745312 Edition: cre Level: 1 Version: 2.1.0p45

3 months, 2 weeks

[2.2.0] Checkmk Werk 16989 created: NagVis: Updated to 1.9.41

by Checkmk werks level 1

Title: NagVis: Updated to 1.9.41 Class: fix Compatible: compat Component: packages Date: 1717745312 Edition: cre Level: 1 Version: 2.2.0p28

3 months, 2 weeks

[2.2.0] Checkmk Werk 16827 created: Fix checkmk errors appearing at the bottom of the page

by Checkmk werks level 1

Title: Fix checkmk errors appearing at the bottom of the page Class: fix Compatible: compat Component: wato Date: 1716912326 Edition: cre Level: 1 Version: 2.2.0p28 A certain class of errors, including time out errors appeared at the bottom of a page, making the error difficult to notice, especially when viewing large tables. With this werk, these error messages will appear on top of the page like all other errors.

3 months, 2 weeks

[2.3.0] Checkmk Werk 16430 adapted: veeam_jobs: Always Monitor Result of Last Backup

by Checkmk werks level 1

Werk 16430 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # veeam_jobs: Always Monitor Result of Last Backup key | value ---------- | --- date | 2024-06-05T14:36:09+00:00 version | 2.3.0p6 class | fix edition | cee component | checks level | 1 compatible | yes Previously, the check plugin `veeam_jobs` would not always check the result of the last backup job to determine the monitoring state. If the creation time was an empty string, it would show `item not found`. Moreover, if the last state of the plugin was `Starting`, `Working` or `Postprocessing`, then the check would be OK, even if the last backup failed. The check now shows all the information available unconditionally. Moreover, * a Success result is OK, * a Warning result is WARN, * a Failed result is CRIT, * a None result is OK or UNKNOWN. There is no change in behaviour in this case. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # veeam_jobs: Always Monitor Result of Last Backup key | value ---------- | --- date | 2024-06-05T14:36:09+00:00 version | 2.3.0p6 class | fix edition | cee component | checks level | 1 compatible | yes Previously, the check plugin `veeam_jobs` would not always check the result of the last backup job to determine the monitoring state. If the creation time was - an empty string, it would show `item not found` in case. It will now show all - the information available and the correct monitoring state. + an empty string, it would show `item not found`. Moreover, if the last + state of the plugin was `Starting`, `Working` or `Postprocessing`, then the + check would be OK, even if the last backup failed. + The check now shows all the information available unconditionally. Moreover, + * a Success result is OK, + * a Warning result is WARN, + * a Failed result is CRIT, + * a None result is OK or UNKNOWN. There is no change in behaviour in this case. +

3 months, 2 weeks

[2.3.0] Checkmk Werk 16430 created: veeam_jobs: Always Monitor Result of Last Backup

by Checkmk werks level 1

[//]: # (werk v2) # veeam_jobs: Always Monitor Result of Last Backup key | value ---------- | --- date | 2024-06-05T14:36:09+00:00 version | 2.3.0p6 class | fix edition | cee component | checks level | 1 compatible | yes Previously, the check plugin `veeam_jobs` would not always check the result of the last backup job to determine the monitoring state. If the creation time was an empty string, it would show `item not found` in case. It will now show all the information available and the correct monitoring state.

3 months, 2 weeks

[2.3.0] Checkmk Werk 16989 created: NagVis: Updated to 1.9.41

by Checkmk werks level 1

[//]: # (werk v2) # NagVis: Updated to 1.9.41 key | value ---------- | --- date | 2024-06-07T07:28:32+00:00 version | 2.3.0p6 class | fix edition | cre component | packages level | 1 compatible | yes

3 months, 2 weeks

[2.3.0] Checkmk Werk 16347 adapted: Synthetic monitoring: Fix missing keyword metrics in test services

by Checkmk werks level 1

Werk 16347 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Synthetic monitoring: Fix missing keyword metrics in test services key | value ---------- | --- date | 2024-06-03T22:20:51+00:00 version | 2.3.0p6 class | fix edition | cee component | checks level | 1 compatible | yes Before this werk, certain keyword runtime metrics were missing the output of the RMK test services. This applied to both high-level and regex-matched keywords. Specifically, this issue affected keywords nested in a TRY statement. As a result of this werk, new keyword runtime metrics may appear in the test services. Also, the names of existing metrics may change due to shifts in the underlying keyword IDs. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Synthetic monitoring: Fix missing keyword metrics in test services key | value ---------- | --- date | 2024-06-03T22:20:51+00:00 - version | 2.3.0p5 ? ^ + version | 2.3.0p6 ? ^ class | fix edition | cee component | checks level | 1 compatible | yes Before this werk, certain keyword runtime metrics were missing the output of the RMK test services. This applied to both high-level and regex-matched keywords. Specifically, this issue affected keywords nested in a TRY statement. As a result of this werk, new keyword runtime metrics may appear in the test services. Also, the names of existing metrics may change due to shifts in the underlying keyword IDs.

3 months, 2 weeks

[2.4.0] Checkmk Werk 17014 created: notification_rules: auth value should be a required field when auth is enabled

by Checkmk werks level 1

[//]: # (werk v2) # notification_rules: auth value should be a required field when auth is enabled key | value ---------- | --- date | 2024-06-05T15:51:31+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Previously, when you created a notification rule via the REST-API using the 'mail' plugin, the value of the 'auth' field within the "enable_sync_smtp" schema was not a required field. This is incorrect. If 'auth' is enabled, then the value of 'auth' should be a required field. This werk now addresses this issue. e.g ``` "enable_sync_smtp": { "state": "enabled", "value": { "auth": { "state": "enabled", "value": {"method": "plaintext", "password": "1234", "user": "user_a"}, }, "encryption": "ssl_tls", "port": 25, "smarthosts": ["abc", "def"], }, } ```

3 months, 2 weeks

[2.4.0] Checkmk Werk 16788 created: notification_rules: encryption type now an enum

by Checkmk werks level 1

[//]: # (werk v2) # notification_rules: encryption type now an enum key | value ---------- | --- date | 2024-06-05T15:09:16+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no When creating a notification rule via the REST-API with the plugin 'asciimail', and configuring the 'enable_sync_smtp field', you could previously set the subfield 'encryption' to any string. Any string is not a valid encryption type. This werk addresses this issue by having this field be an enum of two values which are "ssl_tls" or "starttls". This aligns with the options found in the UI for the same plugin. select

3 months, 2 weeks

[2.4.0] Checkmk Werk 16830 created: Bruteforce protection for two factor authentication

by Checkmk werks level 1

[//]: # (werk v2) # Bruteforce protection for two factor authentication key | value ---------- | --- date | 2024-06-06T17:19:18+00:00 version | 2.4.0b1 class | security edition | cre component | core level | 1 compatible | yes Prior to this werk, Two Factor Authentication failures could not trigger account lockout. All three methods will now count towards failed login attempts against a user's account. As a result, an attacker could try to brute-force and therefore bypass user's two factor protections without triggering the lockout mechanism. This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH. *Affected Versions*: * 2.3.0 *Indicators of Compromise*: Failed two factor authentication attempts can be identified within a Checkmk site's security log file (~/var/log/security.log). *Vulnerability Management*: We have rated the issue with a CVSS Score of 5.9 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N</code> and assigned CVE <code>CVE-2024-28833</code>.

3 months, 2 weeks

← Newer
1
...
18
19
20
21
22
23
24
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 June 2024