Checkmk werks level1 June 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
272 discussions

[2.3.0] Checkmk Werk 16841 created: mk-sql plugin produces backup section correctly

by Checkmk werks level 1

[//]: # (werk v2) # mk-sql plugin produces backup section correctly key | value ---------- | --- date | 2024-06-21T09:07:51+00:00 version | 2.3.0p7 class | fix edition | cre component | checks level | 2 compatible | yes Since this release the backup section content is identical to the expected one(from mssql.vbs)

3 months

[2.3.0] Checkmk Werk 17056 adapted: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk werks level 1

Werk 17056 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.3.0p7 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/audit_log_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.3.0p7 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is - copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong ? - ^^^^^^^ -------- --------- + copied to "~/audit_log_backup". If anything goes wrong ? ^^^^ during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`.

3 months

[2.3.0] Checkmk Werk 16988 created: Proxmox monitoring: Fix incorrect backup monitoring results

by Checkmk werks level 1

[//]: # (werk v2) # Proxmox monitoring: Fix incorrect backup monitoring results key | value ---------- | --- compatible | no version | 2.3.0p7 date | 2024-06-14T10:15:39+00:00 level | 1 class | fix component | checks edition | cre For certain Proxmox VMs, the service <i>Proxmox VE VM Backup Status</i> might have incorrectly alerted about missing backups. This was caused by a limitation in the Proxmox agent regarding the processing of logs and tasks. Specifically, log files larger than 5,000 lines were truncated. A possible indicator that monitored VMs are affected by this issue is the presence of files named <tt>erroneous-...</tt> in <tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Especially if these files end with messages such as "Log for VMID=... not finalized", at least some VMs are likely affected. To immediately benefit from this werk, users should delete the folder <tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Otherwise, it can take up the maximum log age for this werk come into effect after updating Checkmk (the maximum log age is configured in the Proxmox agent rule).

3 months

[2.3.0] Checkmk Werk 16769 created: MultipleChoice formspec: use list as default value instead of tuple

by Checkmk werks level 1

[//]: # (werk v2) # MultipleChoice formspec: use list as default value instead of tuple key | value ---------- | --- date | 2024-06-20T06:07:52+00:00 version | 2.3.0p7 class | fix edition | cre component | checks level | 1 compatible | yes During the creation of certain rules with MultipleChoice formspec, the following warning appeared due to default values being saved as a list instead of a tuple: _"Unable to read current options of this rule. Falling back to default values. When saving this rule now, your previous settings will be overwritten. The problem was: [...]: The datatype must be list, but is tuple."_ This werk corrects this behavior by allowing the use of any `Sequence` of strings as values.

3 months

[2.4.0] Checkmk Werk 16200 created: mk_informix: Add example configuration

by Checkmk werks level 1

[//]: # (werk v2) # mk_informix: Add example configuration key | value ---------- | --- date | 2024-03-11T12:28:06+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Add an example configuration file to showcase how mk_informix can be configured. The `EXCLUDES_INFORMIX-INSTANCE` option mentioned in werk #4580 is not included since this option is not considered in the current implementation.

3 months

[2.4.0] Checkmk Werk 17055 created: Fix unescaped details for process discovery checks in "Log: Details" column

by Checkmk werks level 1

[//]: # (werk v2) # Fix unescaped details for process discovery checks in "Log: Details" column key | value ---------- | --- compatible | yes version | 2.4.0b1 date | 2024-06-18T12:31:13+00:00 level | 1 class | fix component | multisite edition | cre Werk #16701 already fixed the escaping for availability views. This werk fixes the escaping in views with "Log: Details" columns. If the long output is truncated, there will be a warning because we can not render the table without the complete table styling, which is missing in that case.

3 months

[2.4.0] Checkmk Werk 17089 created: Change Transaction ID Format

by Checkmk werks level 1

[//]: # (werk v2) # Change Transaction ID Format key | value ---------- | --- date | 2024-06-21T07:56:55+00:00 version | 2.4.0b1 class | security edition | cre component | wato level | 1 compatible | yes This Werk changes the format of transaction IDs and the way they are generated. Before this Werk transaction IDs used the format `<unix timestamp>/<number>`. The new format is `<unix timestamp>/<string>`, where the string component can contain any URL-safe character. Transaction IDs are now generated using a cryptographically secure random number generator. This security Werk does not address any exploitable vulnerability. To aid automated scanning we assign a CVSS score of 0.0 (None) (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N`).

3 months

[2.4.0] Checkmk Werk 16988 created: Proxmox monitoring: Fix incorrect backup monitoring results

by Checkmk werks level 1

[//]: # (werk v2) # Proxmox monitoring: Fix incorrect backup monitoring results key | value ---------- | --- compatible | no version | 2.4.0b1 date | 2024-06-14T10:15:39+00:00 level | 1 class | fix component | checks edition | cre For certain Proxmox VMs, the service <i>Proxmox VE VM Backup Status</i> might have incorrectly alerted about missing backups. This was caused by a limitation in the Proxmox agent regarding the processing of logs and tasks. Specifically, log files larger than 5,000 lines were truncated. A possible indicator that monitored VMs are affected by this issue is the presence of files named <tt>erroneous-...</tt> in <tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Especially if these files end with messages such as "Log for VMID=... not finalized", at least some VMs are likely affected. To immediately benefit from this werk, users should delete the folder <tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Otherwise, it can take up the maximum log age for this werk come into effect after updating Checkmk (the maximum log age is configured in the Proxmox agent rule).

3 months

[2.4.0] Checkmk Werk 16769 created: MultipleChoice formspec: use list as default value instead of tuple

by Checkmk werks level 1

[//]: # (werk v2) # MultipleChoice formspec: use list as default value instead of tuple key | value ---------- | --- date | 2024-06-20T06:07:52+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes During the creation of certain rules with MultipleChoice formspec, the following warning appeared due to default values being saved as a list instead of a tuple: _"Unable to read current options of this rule. Falling back to default values. When saving this rule now, your previous settings will be overwritten. The problem was: [...]: The datatype must be list, but is tuple."_ This werk corrects this behavior by allowing the use of any `Sequence` of strings as values.

3 months

[2.1.0] Checkmk Werk 17074 created: MS Exchange: Use consistent units (ms/s) in rules & graphs

by Checkmk werks level 1

Title: MS Exchange: Use consistent units (ms/s) in rules & graphs Class: fix Compatible: compat Component: checks Date: 1718695214 Edition: cee Level: 1 Version: 2.1.0p45 Various msexch_* checks reported its values in ms in the summary/ruleset but displayed the same value as seconds in the graph. With this werk, all units will be reported consistently.

3 months

← Newer
1
...
5
6
7
8
9
10
11
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 June 2024