Checkmk werks level1 April 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
306 discussions

[2.4.0] Checkmk Werk 16356 created: Synthetic Monitoring: Incompatible overhauls

by Checkmk werks level 1

[//]: # (werk v2) # Synthetic Monitoring: Incompatible overhauls key | value ---------- | --- date | 2024-04-17T11:05:50+00:00 version | 2.4.0b1 class | feature edition | cee component | checks level | 1 compatible | no This werk only affects users who have configured the rule *Robotmk scheduler (Windows)* during the 2.3.0 beta phase. The following incompatible changes have been made: * The plan naming convention introduced in [werk 16421](https://checkmk.com/werk/16421) has been adopted in more places, both internally and user-facing. * The service items of the *RMK Plan* and *RMK Test* services have been reworked to include the name of the corresponding top-level Robot Framework suite. * Previously, the scheduler terminated in case of permission issues for example with its working directory. As of this werk, the scheduler instead skips affected plans and forwards these issues to the Checkmk server, where they are reported to the user. After updating, the *RMK scheduler status* service will report UNKNOWN. The plan and test services will go stale. Furthermore, the *Check_MK* service will report that there is monitoring data missing for the plugins `robotmk_plan` and `robotmk_test`. To remedy these issues, users first have to re- bake and then update the Checkmk agent on affected systems. After updating the agent, users have to re-discover the services of affected Checkmk hosts.

5 months

[2.4.0] Checkmk Werk 16651 deleted: "TSM - IBM Tivoli Storage Manager (Linux, Unix)": Agent plugin rules are merged

by Checkmk werks level 1

Werk 16651 was deleted. The following Werk is no longer relevant. [//]: # (werk v2) # "TSM - IBM Tivoli Storage Manager (Linux, Unix)": Agent plugin rules are merged key | value ---------- | --- date | 2024-04-04T13:12:06+00:00 version | 2.4.0b1 class | feature edition | cee component | agents level | 1 compatible | yes Multiple matching rules of the bakery configuration ruleset "TSM - IBM Tivoli Storage Manager (Linux, Unix)" will now be merged to compute the set of effective parameters. Previously only the first matching rule was applied. During the migration to Checkmk 2.4 existing rules will be "filled", such that the outcome of the rule evaluation will not change on existing configurations.

5 months

[2.4.0] Checkmk Werk 16651 created: "TSM - IBM Tivoli Storage Manager (Linux, Unix)": Agent plugin rules are merged

by Checkmk werks level 1

[//]: # (werk v2) # "TSM - IBM Tivoli Storage Manager (Linux, Unix)": Agent plugin rules are merged key | value ---------- | --- date | 2024-04-04T13:12:06+00:00 version | 2.4.0b1 class | feature edition | cee component | agents level | 1 compatible | yes Multiple matching rules of the bakery configuration ruleset "TSM - IBM Tivoli Storage Manager (Linux, Unix)" will now be merged to compute the set of effective parameters. Previously only the first matching rule was applied. During the migration to Checkmk 2.4 existing rules will be "filled", such that the outcome of the rule evaluation will not change on existing configurations.

5 months

[2.4.0] Checkmk Werk 16682 created: Ruleset API: Fix migration with scaling of SimpleLevels

by Checkmk werks level 1

[//]: # (werk v2) # Ruleset API: Fix migration with scaling of SimpleLevels key | value ---------- | --- date | 2024-04-17T11:19:36+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | no This change is relevant to plugin developers The migration helper functions `migrate_to_integer_simple_levels` and `migrate_to_float_simple_levels` for `SimpleLevels` currently apply the scaling factor (if given) every time the migration is run, meaning also to the already migrated value. This means any rule where these helpers are used with a scaling factor will have incorrect values and will have to be manually corrected. No shipped rules are affected by this.

5 months

[2.4.0] Checkmk Werk 15199 created: Update OpenSSL to version 3.0.13

by Checkmk werks level 1

[//]: # (werk v2) # Update OpenSSL to version 3.0.13 key | value ---------- | --- date | 2024-04-17T10:08:23+00:00 version | 2.4.0b1 class | security edition | cre component | omd level | 1 compatible | yes OpenSSL was updated to version 3.0.13. OpenSSL 3 uses requirements regarding allowed configurations, such as allowed ciphers, renegotiation, and so on. In some scenarios, this can break monitoring for hosts with TLS configurations that are no longer considered secure. We have published a blog post to help you mitigate these issues, should they affect you: https://checkmk.com/blog/how-monitor-servers-broken-tls-checkmk. 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).

5 months

[2.4.0] Checkmk Werk 15198 created: Brute-force protection ineffective for some login methods

by Checkmk werks level 1

[//]: # (werk v2) # Brute-force protection ineffective for some login methods key | value ---------- | --- date | 2024-04-09T12:24:12+00:00 version | 2.4.0b1 class | security edition | cre component | wato level | 1 compatible | yes Prior to this Werk, the mechanism to lock user accounts after too many failed login attempts was only effective for the web form login method. Login attempts via the REST API and basic authentication did not count towards the lockout mechanism. As a result, an attacker could try to brute-force user passwords without triggering the lockout mechanism. This Werk adds the same locking mechanism to login via the REST API and basic authentication _for human user accounts_. Note that automation accounts are remain unaffected by the lockout mechanism to avoid having them locked by malicious intent. It is therefore important to use long, random automation secrets. This issue was found during internal review. **Affected Versions**: * 2.3.0 (beta) * 2.2.0 * 2.1.0 * 2.0.0 (EOL) **Mitigations**: If updating is not possible, the brute-force attempts can be hindered by using a strong password policy. **Vulnerability Management**: We have rated the issue with a CVSS Score of 5.9 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N` and assigned CVE `CVE-2024-28825`.

5 months

[2.4.0] Checkmk Werk 16690 created: pfsense_if: stale services in 2.3 beta

by Checkmk werks level 1

[//]: # (werk v2) # pfsense_if: stale services in 2.3 beta key | value ---------- | --- date | 2024-04-17T11:38:38+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes

5 months

[2.1.0] Checkmk Werk 16631 created: check_mailboxes: Fixed handling of error "Not allowed to access Non IPM folder."

by Checkmk werks level 1

Title: check_mailboxes: Fixed handling of error "Not allowed to access Non IPM folder." Class: fix Compatible: compat Component: packages Date: 1712910849 Edition: cre Level: 1 Version: 2.1.0p42 Due to a recent change in Microsoft 365, the access to Exchange mailbox folders via the active check <code>check_mailboxes</code> could fail with an error message like this: C+: Unhandled exception: ErrorAccessDenied('Not allowed to access Non IPM folder.') C-: With this werk we update the version of the package <code>exchangelib</code> to v5.2.1, fixing the respective error handling.

5 months

[2.2.0] Checkmk Werk 15843 adapted: mk_oracle(ps1): Follow-up to privilege escalation fix

by Checkmk werks level 1

Werk 15843 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: mk_oracle(ps1): Follow-up to privilege escalation fix Class: fix Compatible: incomp Component: checks Date: 1712314947 Edition: cre Level: 2 Version: 2.2.0p25 You might be affected by this Werk if you use <tt>mk_oracle</tt> on Windows. Werk <a href="https://checkmk.com/werk/16232">Werk #16232</a> introduced a regression, thereby disrupting Oracle monitoring on Windows. This Werk addresses above mentioned issue that affects versions 2.1.0p41, 2.2.0p24, and 2.3.0b4. Since this release, Oracle monitoring on Windows is fully supported under either of the following conditions: 1. The monitoring is performed using an account without administrator rights. 2. Specific Oracle executable binaries — namely, <tt>sqlplus.exe</tt>, <tt>tnsping.exe</tt> and, if presented, <tt>crsctl.exe</tt> - are not modifiable by non-admin users. If you are still unable to monitor Oracle, for example, you can't use an unprivileged account for monitoring and changing of permission is not possible, consider one of the following actions: 1. Enable <tt>Run as local group</tt> for group <tt>Administrators</tt> in <tt>Run plugins and local checks using non-system account</tt> ruleset. 2. Adjust <tt>Oracle Binaries Permissions Check</tt> settings in <tt>ORACLE databases (Linux, Solaris, AIX, Windows)</tt> ruleset. More information about can be found at <a href="https://checkmk.atlassian.net/wiki/x/AQA1B">here</a>. ------------------------------------<diff>------------------------------------------- Title: mk_oracle(ps1): Follow-up to privilege escalation fix Class: fix Compatible: incomp Component: checks Date: 1712314947 Edition: cre Level: 2 Version: 2.2.0p25 You might be affected by this Werk if you use <tt>mk_oracle</tt> on Windows. Werk <a href="https://checkmk.com/werk/16232">Werk #16232</a> introduced a regression, thereby disrupting Oracle monitoring on Windows. This Werk addresses above mentioned issue that affects versions 2.1.0p41, 2.2.0p24, and 2.3.0b4. - Since this release, Oracle monitoring on Windows is fully supported under ? - + Since this release, Oracle monitoring on Windows is fully supported under - condition you use an account without administrator rights or the certain - executable binaries, <tt>sqlplus.exe</tt>, <tt>tnsping.exe</tt> and, if - presented, <tt>crsctl.exe</tt> are write-protected, with the possible - exception being the Administrator. + either of the following conditions: + 1. The monitoring is performed using an account without administrator rights. + 2. Specific Oracle executable binaries — namely, <tt>sqlplus.exe</tt>, + <tt>tnsping.exe</tt> and, if presented, <tt>crsctl.exe</tt> - are not modifiable + by non-admin users. - If you are unable or prefer not to use an unprivileged account then you may - need to adjust permissions for above mentioned binaries: remove <tt>Write</tt>, - <tt>Full Control</tt> and <tt>Modify</tt> permissions for any non-Administrator - user and group. + If you are still unable to monitor Oracle, for example, you can't use an + unprivileged account for monitoring and changing of permission is not possible, + consider one of the following actions: + 1. Enable <tt>Run as local group</tt> for group <tt>Administrators</tt> in + <tt>Run plugins and local checks using non-system account</tt> ruleset. + 2. Adjust <tt>Oracle Binaries Permissions Check</tt> settings in <tt>ORACLE databases (Linux, + Solaris, AIX, Windows)</tt> ruleset. More information about can be found at <a href="https://checkmk.atlassian.net/wiki/x/AQA1B">here</a>. +

5 months

[2.2.0] Checkmk Werk 16606 created: agent_netapp_ontap: handle shelves without elements

by Checkmk werks level 1

Title: agent_netapp_ontap: handle shelves without elements Class: fix Compatible: compat Component: checks Date: 1712751995 Edition: cre Level: 1 Version: 2.2.0p25 The agent did not handle the cases where shelves had no fans, temperature sensors or PSUs. This led to crashes during the agent execution. With this werk we now correctly handle these scenarios and the corresponding services are not discovered if no items are found.

5 months

← Newer
1
...
18
19
20
21
22
23
24
...
31
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 April 2024