Checkmk werks level1 June 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
272 discussions

[2.4.0] Checkmk Werk 16711 created: Changed format of host tag conditions in notifications.mk configuration file

by Checkmk werks level 1

[//]: # (werk v2) # Changed format of host tag conditions in notifications.mk configuration file key | value ---------- | --- date | 2024-06-09T12:24:41+00:00 version | 2.4.0b1 class | feature edition | cre component | notifications level | 1 compatible | yes The internal data format of the Checkmk notification rule definitions, normally configured via Setup "Notifications" page, has been changed. If you only use Setup for configuring Checkmk this change will not be relevant for you, since the data format will be changed automatically during update to 2.4x. In case you edit notifications.mk files manually or via script to define the <tt>notification_rules</tt> configuration options, you will likely have to change your scripts or at least the configuration files. A notification rule definition with it's tag conditions in the old format looks like this: F+:notifications.mk notification_rules += [ { "description": "Rule description", ..., "match_hosttags": ["my-host|cmk-agent|prod|lan|piggyback|no-snmp"], ..., } ] F-: The tags that should match are in list format, separated via pipe characters. There is no information about the tag group the configured tag is related with. The new structure looks like this: F+:notifications.mk: notification_rules += [ { "description": "Rule description", ..., "match_hosttags": { "agent": "cmk-agent", "criticality": "prod", "networking": "lan", "piggyback": "piggyback", "snmp_ds": "no-snmp", }, ..., } ] F-: In the <tt>match_hosttags</tt> dictionary the keys are the tag groups (as defined in Setup) and the values are the tags configured for each group.

3 months, 1 week

[2.4.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.4.0b1 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 ? ^ ^^ + version | 2.4.0b1 ? ^ ^^ 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.

3 months, 1 week

[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, 1 week

[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, 1 week

[2.4.0] Checkmk Werk 16876 created: Nutanix agent: resolve verify error when environment REQUEST_CA_BUNDLE is set

by Checkmk werks level 1

[//]: # (werk v2) # Nutanix agent: resolve verify error when environment REQUEST_CA_BUNDLE is set key | value ---------- | --- date | 2024-06-08T22:17:32+00:00 version | 2.4.0b1 class | fix edition | cee component | checks level | 1 compatible | yes Due to a specific behaviour in the requests Python library, the SSL verify disable option does not work when the REQUEST_CA_BUNDLE environment variable is set. This also affected the Nutanix agent. This werk resolves the error and therefore always respects the no-cert-check flag. In addition, this werk also improves the error message in case the agent fails when requesting the Nutanix API.

3 months, 1 week

[2.3.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.3.0p6 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, 1 week

[2.3.0] Checkmk Werk 16839 created: mk-sql ensures instance name is correct

by Checkmk werks level 1

[//]: # (werk v2) # mk-sql ensures instance name is correct key | value ---------- | --- date | 2024-06-05T11:27:42+00:00 version | 2.3.0p6 class | feature edition | cee component | checks level | 2 compatible | no The plugin verifies whether the name of the instance at the specified address matches the name indicated in the config. If the name specified in the config does not match the instance name that responds, the monitoring of this instance will return an error. Example: The config mistakenly indicates that the `SQLEXPRESS` instance is located at `localhost:1433`, whereas the `MSSQLSERVER` instance is actually located at this address. Previously, the instance `MSSQLSERVER` were mistakenly monitored as `SQLEXPRESS`. Starting from this release, this error has been corrected. You need to correct the config if your config contained bad data.

3 months, 1 week

[2.4.0] Checkmk Werk 16857 created: diskstat: Use WWN as service description for physical disks

by Checkmk werks level 1

[//]: # (werk v2) # diskstat: Use WWN as service description for physical disks key | value ---------- | --- date | 2024-06-04T11:51:10+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously, device name was used as service description for physical disks. Device names aren't persistent, which led to services starting to receive metrics of another device if device names get switched. This could happen after an update or a reboot. Now, it's possible to configure WWN (World Wide Name) to be used as service description in the `Disk IO discovery` rule, in `Physical disks` configuration. Old `Physical disks` configurations will continue to use device name as service description to preserve compatibility. For the new configurations using WWN will be the default.

3 months, 1 week

[2.3.0] Checkmk Werk 16839 deleted: mk-sql ensures instance name is correct

by Checkmk werks level 1

Werk 16839 was deleted. The following Werk is no longer relevant. [//]: # (werk v2) # mk-sql ensures instance name is correct key | value ---------- | --- date | 2024-06-05T11:27:42+00:00 version | 2.3.0p6 class | feature edition | cee component | checks level | 2 compatible | no The plugin verifies whether the name of the instance at the specified address matches the name indicated in the config. If the name specified in the config does not match the instance name that responds, the monitoring of this instance will return an error. Example: The config mistakenly indicates that the `SQLEXPRESS` instance is located at `localhost:1433`, whereas the `MSSQLSERVER` instance is actually located at this address. Previously, the instance `MSSQLSERVER` were mistakenly monitored as `SQLEXPRESS`. Starting from this release, this error has been corrected. You need to correct the config if your config contained bad data.

3 months, 1 week

[2.3.0] Checkmk Werk 16839 created: mk-sql ensures instance name is correct

by Checkmk werks level 1

3 months, 1 week

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 June 2024