Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15865 discussions

[2.3.0] Checkmk Werk 17206 created: omd update: Log "Verifying site configuration"

by Checkmk werks level 1

[//]: # (werk v2) # omd update: Log "Verifying site configuration" key | value ---------- | --- date | 2024-08-05T08:59:03+00:00 version | 2.3.0p12 class | fix edition | cre component | omd level | 1 compatible | yes If a user runs `omd update`, then the output is written to both `$OMD_ROOT/var/log/update.log` and stdout. However, the output of site configuration verification <a href="https://checkmk.com/werk/16408"> Werk #16408</a> was missing. This has been fixed.

3 weeks, 1 day

[2.3.0] Checkmk Werk 16249 created: mk_informix: Follow up for Werk 16198

by Checkmk werks level 1

[//]: # (werk v2) # mk_informix: Follow up for Werk 16198 key | value ---------- | --- date | 2024-07-26T07:18:38+00:00 version | 2.3.0p12 class | security edition | cre component | checks level | 1 compatible | yes [Werk #16198](https://checkmk.com/werk/16198) addressed potential priviledge escalation by the agent plugin `mk_informix`. However, a few callsites to the binaries `dbaccess` and `onstat` where missing the safe execution. Those binaries are now also called in a safe way. <em>Vulnerability Management</em>: We have rated the issue with a CVSS Score of 5.2 (Medium) with the following CVSS vector: <code>CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:H/SI:H/SA:H</code> and assigned CVE <code>CVE-2024-28829</code>.

3 weeks, 1 day

[2.3.0] Checkmk Werk 16887 created: mk_job: MK_VARDIR defaults not being set in bakery

by Checkmk werks level 1

[//]: # (werk v2) # mk_job: MK_VARDIR defaults not being set in bakery key | value ---------- | --- compatible | yes version | 2.3.0p12 date | 2024-07-26T05:47:27+00:00 level | 1 class | fix component | checks edition | cre Due to a different way to set in `MK_VARDIR` in `mk_job`, default values would not be baked into `mk_job` and derivates. This change adds a replacement rule for the way `MK_VARDIR` gets assigned in `mk_job` and also separates assignment and export in order to avoid known problems with Solaris.

3 weeks, 1 day

[2.3.0] Checkmk Werk 16556 created: Agent Updates: host selection ignores configured host labels

by Checkmk werks level 1

[//]: # (werk v2) # Agent Updates: host selection ignores configured host labels key | value ---------- | --- date | 2024-08-01T13:39:05+00:00 version | 2.3.0p12 class | fix edition | cee component | agents level | 1 compatible | yes When configuring the global setting *Automatic agent updates/Activate update only on the selected hosts*, the selection of host labels under *Match host labels* didn't get recognized. Technical background: The set of host selection parameters used in above rule comes from a generic ruleset pattern that's used in some more host rulesets in Checkmk. Eventually, the option to filter for host labels got introduced to the generic ruleset, but we missed to evaluate it for the determination of allowed hosts for agent updates.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17241 created: Support Azure PostgreSQL Flexible Server

by Checkmk werks level 1

[//]: # (werk v2) # Support Azure PostgreSQL Flexible Server key | value ---------- | --- date | 2024-08-21T14:54:11+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes [Microsoft is retiring the Azure resource](https://learn.microsoft.com/en-us/azure/postgresql/single-server/… "Database for PostgreSQL single server" . With this Werk, we now support monitoring the recommended Azure resource "Database for PostgreSQL flexible server". In the rule "Microsoft Azure" under "Azure services to monitor", users can now select the new option "Database for PostgreSQL flexible server". Note that the former option "Database for PostgreSQL" was renamed to "Database for PostgreSQL single server" and stays in place. The metrics monitored for flexible servers correspond to those monitored for single servers and the same checks are used. See the [check plugin catalog](https://checkmk.com/integrations?distributions%5B%5D=check_mk&dist… for more details.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17230 created: heartbeat_crm_resources: Check for unmanaged nodes

by Checkmk werks level 1

[//]: # (werk v2) # heartbeat_crm_resources: Check for unmanaged nodes key | value ---------- | --- date | 2024-08-08T10:22:23+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes The plugin `heartbeat_crm_resources`, which monitors the resouces of Heartbeat/Pacemaker clusters, now additionally checks if there are any unmanaged nodes. If this is the case, the plugin goes WARN by default. The monitoring state is configurable in the corresponding ruleset.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17235 created: cpu_utilization: allow total CPU utilization to be set above 101%

by Checkmk werks level 1

[//]: # (werk v2) # cpu_utilization: allow total CPU utilization to be set above 101% key | value ---------- | --- date | 2024-08-28T06:45:04+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Before this werk, the "High utilization at" level option within the "Levels over an extended time period on total CPU utilization" target was limited to a maximum of 101%. However, in environments like containers, the total CPU utilization can exceed this threshold. This werk therefore removes the upper limit for the total value.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17123 created: KUBE: Addition of support for Kubernetes v1.30

by Checkmk werks level 1

[//]: # (werk v2) # KUBE: Addition of support for Kubernetes v1.30 key | value ---------- | --- date | 2024-08-27T10:39:49+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes With this release of Checkmk, we introduce support for version 1.30 of Kubernetes. The supported versions are listed below: Checkmk 2.2: 1.22, 1.23, 1.24, 1.25, 1.26, 1.27 Checkmk 2.3: 1.24, 1.25, 1.26, 1.27, 1.28, 1.29, 1.30 The list of supported versions may not apply to future patch versions. For such cases, a new werk will be released.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17232 created: Synthetic Monitoring: Fix XSS vector in HTML logs displayed in UI

by Checkmk werks level 1

[//]: # (werk v2) # Synthetic Monitoring: Fix XSS vector in HTML logs displayed in UI key | value ---------- | --- date | 2024-08-26T18:51:50+00:00 version | 2.4.0b1 class | security edition | cee component | multisite level | 1 compatible | yes The user interface offers the option to display the HTML logs of monitored synthetic tests. These logs are generated on the host where the test is executed and are therefore prone to XSS attacks. A malicious actor with access to the host could attempt to inject malicious JavaScript code into these logs before they are transferred to the monitoring server. As of this werk, the logs are rendered sandboxed, which prevents code injected into the logs from accessing the surrounding Checkmk site. However, note that an attacker could still attempt to hijack the log to eg. display a fake login page. Therefore, we additionally display a corresponding security note when rendering the logs. An unfortunate side effect of the sandboxing described above is that the "Expand/Collapse all" buttons in the logs are deactivated. Users can still download the logs and inspect them outside the Checkmk user interface, as before. This issue was found during internal review. *Affected Versions*: * 2.3.0 *Mitigations*: Avoid displaying the HTML logs in the user interface. *Vulnerability Management*: We have rated the issue with a CVSS Score of 2.3 Low (`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N`) and assigned `CVE-2024-38858`.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17148 created: Persist known host keys for checks that use SSH

by Checkmk werks level 1

[//]: # (werk v2) # Persist known host keys for checks that use SSH key | value ---------- | --- date | 2024-08-26T08:56:04+00:00 version | 2.4.0b1 class | security edition | cre component | checks level | 1 compatible | yes When using the special agent *VNX quotas and filesystems* or the active check *Check SFTP Service* the host keys were not properly checked. If an attacker would get into a machine-in-the-middle position he could intercept the connection and retrieve information e.g. passwords. As of this Werk the host key check is properly done. In order to store known host keys a regular `known_hosts` file is used that is stored in `/omd/sites/$SITENAME/.ssh/known_hosts`. If a host key changes an error is now raised that requires manual edit of this file. This issue was found during internal review. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Vulnerability Management*: We have rated the issue with a CVSS Score of 6.3 Medium CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N and assigned CVE-2024-6572.

3 weeks, 1 day

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1