Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15865 discussions

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

by Checkmk werks level 1

Title: mk_informix: Follow up for Werk 16198 Class: security Compatible: compat Component: checks Date: 1721978318 Edition: cre Level: 1 Version: 2.2.0p32 <a href="https://checkmk.com/werk/16198">Werk #16198</a> addressed potential priviledge escalation by the agent plugin <code>mk_informix</code>. However, a few callsites to the binaries <code>dbaccess</code> and <code>onstat</code> where missing the safe execution. Those binaries are now also called in a safe way. Vulnerability Management: 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

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

by Checkmk werks level 1

Title: mk_job: MK_VARDIR defaults not being set in bakery Class: fix Compatible: compat Component: checks Date: 1721972847 Edition: cre Level: 1 Version: 2.2.0p32 Due to a different way to set in <code>MK_VARDIR</code> in <code>mk_job</code>, default values would not be baked into <code>mk_job</code> and derivates. This change adds a replacement rule for the way <code>MK_VARDIR</code> gets assigned in <code>mk_job</code> and also separates assignment and export in order to avoid known problems with Solaris.

3 weeks

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

by Checkmk werks level 1

Title: Agent Updates: host selection ignores configured host labels Class: fix Compatible: compat Component: agents Date: 1722519545 Edition: cee Level: 1 Version: 2.2.0p32 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

[2.3.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.3.0p14 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

[2.3.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.3.0p14 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

[2.3.0] Checkmk Werk 17153 created: Skip unnecessary site activations when editing users

by Checkmk werks level 1

[//]: # (werk v2) # Skip unnecessary site activations when editing users key | value ---------- | --- date | 2024-08-15T06:18:56+00:00 version | 2.3.0p14 class | fix edition | cre component | wato level | 1 compatible | yes Previously, any changes to users required site activations on all existing sites. This created a lot of unnecessary activations where users only exist on certain sites. With this werk, only the sites associated with the changed users require an activation.

3 weeks

[2.3.0] Checkmk Werk 17242 created: Fix Cisco Meraki missing services

by Checkmk werks level 1

[//]: # (werk v2) # Fix Cisco Meraki missing services key | value ---------- | --- date | 2024-08-27T09:38:07+00:00 version | 2.3.0p14 class | fix edition | cre component | checks level | 1 compatible | yes In some rare cases, when using the Cisco Meraki Special Agent, certain services such as temperature sensors or device status may be missing. This happened when no device name was configured for a particular device. These devices are now added to the main host on which the Cisco Meraki integration is configured. If you want to monitor the device as a separate piggyback host, you must configure a name for that device. The missing services must be discovered by running a service discovery on the main host.

3 weeks

[2.3.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.3.0p14 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

[2.3.0] Checkmk Werk 16250 created: Handle years in ntp output

by Checkmk werks level 1

[//]: # (werk v2) # Handle years in ntp output key | value ---------- | --- date | 2024-08-27T11:12:57+00:00 version | 2.3.0p14 class | fix edition | cre component | checks level | 1 compatible | yes This werk affects you, in case your last `ntpq` synchronization was indeed more than a year ago. A potential check crash traceback looks like: ``` File "/omd/sites/SITE/lib/python3/cmk/base/plugins/agent_based/ntp.py", line 67, in _ntp_fmt_time return int(raw) ValueError: invalid literal for int() with base 10: '3y' ``` The year case is now handled in the parse function.

3 weeks

[2.3.0] Checkmk Werk 15323 created: mk_postgres: Adapt environment file parsing

by Checkmk werks level 1

[//]: # (werk v2) # mk_postgres: Adapt environment file parsing key | value ---------- | --- date | 2024-01-31T10:45:29+00:00 version | 2.3.0p14 class | fix edition | cre component | checks level | 1 compatible | yes Reading variables from the environment file was adapted: Lines starting with `#` will now be ignored.

3 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1