Checkmk werks level1 August 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
228 discussions

[2.4.0] Checkmk Werk 16993 created: Automatically sync user visuals to remote sites

by Checkmk werks level 1

[//]: # (werk v2) # Automatically sync user visuals to remote sites key | value ---------- | --- date | 2024-07-25T13:45:53+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes When adjusting visuals (views, dashboards) the updated visuals are currently not synced to remote sites until the first activate changes is triggered. With no pending changes available this was not possible to be done. Now visuals get automatically synced to remote sites just like user reports and passwords.

3 weeks, 1 day

[2.4.0] Checkmk Werk 16866 created: azure: Handle Azure API rate limit

by Checkmk werks level 1

[//]: # (werk v2) # azure: Handle Azure API rate limit key | value ---------- | --- compatible | yes version | 2.4.0b1 date | 2024-08-07T08:56:46+00:00 level | 1 class | fix component | checks edition | cre After the changes in Azure API rate limits, the Azure agent requests to the API were getting throttled for the big Azure environments. This fix introduces handling for throttled requests. If the rate limit is reached, the agent will repeat the request after 5 s. If it fails again, the agent will repeat the request after another 10 s. Additionally, the default limits for 'Lower levels for remaining API reads' in the 'Azure Agent Info' monitoring rule are removed.

3 weeks, 1 day

[2.4.0] Checkmk Werk 16119 created: Don't log unparsable SNMP traps per default

by Checkmk werks level 1

[//]: # (werk v2) # Don't log unparsable SNMP traps per default key | value ---------- | --- date | 2024-08-08T09:11:31+00:00 version | 2.4.0b1 class | fix edition | cre component | ec level | 1 compatible | yes When an SNMP trap arrives at the event console which can't be parsed for various reasons (unknown SNMP engine ID, some deserialization error, ...), we previously logged a full Python backtrace to the EC log. This could lead to the incorrect conclusion that there is something wrong with the EC itself, which is not what has actually happened: Actually, some device was probably misconfigured and/or misbehaving. To avoid such log spam, such a trap is now silently dropped at the standard "informational" log level, and more details can be logged at higher levels when needed.

3 weeks, 1 day

[2.4.0] Checkmk Werk 16772 created: brocade_fcport: fix operating speed conversion

by Checkmk werks level 1

[//]: # (werk v2) # brocade_fcport: fix operating speed conversion key | value ---------- | --- date | 2024-07-09T09:22:21+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This werk affects anyone monitoring Brocade fibre channel ports by comparing current or average throughput to certain absolute or percentage levels via the _Brocade FibreChannel ports_ rule. In the plugin the current operating speed of the interface, read from the SNMP interface data, was not properly converted to GByte/s, the unit of measurement displayed in the interface. This resulted in an erroneous comparison of values and the related service states.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17228 created: Custom graphs: Visibility toggle had no effect

by Checkmk werks level 1

[//]: # (werk v2) # Custom graphs: Visibility toggle had no effect key | value ---------- | --- date | 2024-08-06T08:29:16+00:00 version | 2.4.0b1 class | fix edition | cee component | multisite level | 1 compatible | yes The visibility toggle to enable or disable elements of custom graphs had no effect.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17147 created: Disable automation user login via HTTP parameters

by Checkmk werks level 1

[//]: # (werk v2) # Disable automation user login via HTTP parameters key | value ---------- | --- date | 2024-08-05T12:56:10+00:00 version | 2.4.0b1 class | feature edition | cre component | wato level | 1 compatible | no As announced with Werk #16223 authentication via the `_username`/`_secret` parameters for automation users is disabled by default now. It can be enabled via the configuration option *Enable automation user authentication via HTTP parameters*. Please note that this option will be removed with Checkmk 2.5. We highly recommend to switch to Basic Authentication.

3 weeks, 1 day

[2.4.0] Checkmk Werk 16591 created: jenkins_version: New check for version of the queried Jenkins instance

by Checkmk werks level 1

[//]: # (werk v2) # jenkins_version: New check for version of the queried Jenkins instance key | value ---------- | --- date | 2024-04-03T14:04:34+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes A new check has been added which checks the version of the queried Jenkins instance. The version is obtained through HTTP headers in the response of existing checks against Jenkins. No additional configuration is required, besides the initial configuration of the Jenkins integration. The version of the Jenkins instance will be compared against publically available release information. In case an update is available the state will change to _warning_.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17205 created: agent_netapp_ontap: KeyError: 'rpm' and KeyError: 'temperature'

by Checkmk werks level 1

[//]: # (werk v2) # agent_netapp_ontap: KeyError: 'rpm' and KeyError: 'temperature' key | value ---------- | --- date | 2024-08-01T14:51:58+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This change affects users, which monitor NetApp via Ontap REST API. Previously, the special agent could crash with the following error: ``` File "/omd/sites/nyccheckmk2/lib/python3/cmk/special_agents/agent_netapp_ontap.py", line 28, in write_section for element in generator: File "/omd/sites/nyccheckmk2/lib/python3/cmk/special_agents/agent_netapp_ontap.py", line 471, in fetch_fans rpm=fan["rpm"], ~~^^^^^^^ KeyError: 'rpm'CRIT ``` This would occur, if either a fan or temperature sensor had an error, and thus did not report any rpm/temperature value. This has been fixed.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17229 created: CPU utilization checking: Alert if utilization is exactly at threshold for too long

by Checkmk werks level 1

[//]: # (werk v2) # CPU utilization checking: Alert if utilization is exactly at threshold for too long key | value ---------- | --- date | 2024-08-07T07:03:40+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Many CPU utilization checks can be configured to alert if the utilization is too high for too long (configuration options _Levels over an extended time period on total CPU utilization_ and _Levels over an extended time period on a single core CPU utilization_). Before, Checkmk alerted only if the utilization was above the threshold for too long. As of this werk, Checkmk alerts if the utilization is above or exactly at the threshold for too long. This is consistent with the general behavior of Checkmk to check against upper thresholds with a "greater than or equal to" operation.

3 weeks, 1 day

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

by Checkmk werks level 1

[//]: # (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.4.0b1 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 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 weeks, 1 day

← Newer
1
...
16
17
18
19
20
21
22
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 August 2024