Checkmk werks level1 June 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
272 discussions

[2.4.0] Checkmk Werk 16743 created: Fix vertical graph range if it does not start at zero

by Checkmk werks level 1

[//]: # (werk v2) # Fix vertical graph range if it does not start at zero key | value ---------- | --- date | 2024-06-12T11:41:10+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes

2 months, 4 weeks

[2.4.0] Checkmk Werk 17070 created: Agent controller on Linux: More informative error message in case of file reading erros in import mode

by Checkmk werks level 1

[//]: # (werk v2) # Agent controller on Linux: More informative error message in case of file reading erros in import mode key | value ---------- | --- date | 2024-06-21T16:39:48+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes On Linux systems, the agent controller always runs as the cmk-agent user, independently of the user starting the controller. Hence, in import mode, the input file must readable by the cmk-agent user. Otherwise, the import will fail. As of this werk, the controller displays a more informative error message in this case, hinting at the point that the input file must be readable by cmk-agent.

2 months, 4 weeks

[2.4.0] Checkmk Werk 16661 created: Notification Spooler: Support IPv6

by Checkmk werks level 1

[//]: # (werk v2) # Notification Spooler: Support IPv6 key | value ---------- | --- date | 2024-06-18T06:24:52+00:00 version | 2.4.0b1 class | feature edition | cee component | notifications level | 1 compatible | yes Previously mknotifyd only supported IPv4. This werk adds support for IPv6. Incoming connections now accept IPv4 and IPv6 if the server supports dual-stack IPv6. For outgoing connections you may now enter IPv6 addresses as well. IPv6 will also be used, if a hostname resolves to an IPv6 address. If a hostname resolves to both IPv4 and IPv6, IPv4 is still preferred.

2 months, 4 weeks

[2.4.0] Checkmk Werk 16748 created: Fix graph areas which expand below time axis while zooming

by Checkmk werks level 1

[//]: # (werk v2) # Fix graph areas which expand below time axis while zooming key | value ---------- | --- date | 2024-06-21T13:29:22+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes

2 months, 4 weeks

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

by Checkmk werks level 1

Title: Don't show automation secret in the audit log (addresses CVE-2024-28830) Class: security Compatible: incomp Component: wato Date: 1718799000 Edition: cre Level: 2 Version: 2.1.0p45 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: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 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: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE <code>CVE-2024-28830</code>.

3 months

[2.2.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. Title: Don't show automation secret in the audit log (addresses CVE-2024-28830) Class: security Compatible: incomp Component: wato Date: 1718799000 Edition: cre Level: 2 Version: 2.2.0p28 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: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 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: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE <code>CVE-2024-28830</code>. ------------------------------------<diff>------------------------------------------- Title: Don't show automation secret in the audit log (addresses CVE-2024-28830) Class: security Compatible: incomp Component: wato Date: 1718799000 Edition: cre Level: 2 Version: 2.2.0p28 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: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 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: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE <code>CVE-2024-28830</code>.

3 months

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

by Checkmk werks level 1

Title: Proxmox monitoring: Fix incorrect backup monitoring results Class: fix Compatible: incomp Component: checks Date: 1718360139 Edition: cre Level: 1 Version: 2.2.0p28 For certain Proxmox VMs, the service Proxmox VE VM Backup Status 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 16844 created: fix tablespaces section of mk-sql for older SQL Servers

by Checkmk werks level 1

[//]: # (werk v2) # fix tablespaces section of mk-sql for older SQL Servers key | value ---------- | --- date | 2024-06-21T09:19:49+00:00 version | 2.3.0p7 class | fix edition | cre component | checks level | 1 compatible | yes Since this release, the tablespaces section correctly delivers all required data, thereby preventing the stalling of some services in SQL Server monitoring

3 months

[2.3.0] Checkmk Werk 16843 created: increase performance of mk-sql for some cases

by Checkmk werks level 1

[//]: # (werk v2) # increase performance of mk-sql for some cases key | value ---------- | --- date | 2024-06-21T09:14:33+00:00 version | 2.3.0p7 class | feature edition | cee component | checks level | 1 compatible | yes Due to parallelization and extensive use of asynchronous processing, the execution time of the plugin decreased by up to 3 times for instances with many databases.

3 months

[2.3.0] Checkmk Werk 16842 created: mk-sql detects instances faster

by Checkmk werks level 1

[//]: # (werk v2) # mk-sql detects instances faster key | value ---------- | --- date | 2024-06-21T09:11:30+00:00 version | 2.3.0p7 class | feature edition | cre component | checks level | 1 compatible | yes The timeout for instances accessible through ODBC (Shared Memory transport) is decreased to 2 seconds, thus processing unavailable instances faster. Additionally, mk-sql no longer tries to connect to or detect excluded instances, thereby decreasing the plugin execution time.

3 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 June 2024