[//]: # (werk v2)
# jenkins_nodes: Fix handling of multi-label nodes
key | value
---------- | ---
date | 2024-06-12T14:31:49+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
When using the Jenkins node check in an environment that had multiple labels assigned to a build node, the detection of busy and idle executors and the mode had been wrong.
This werk fixes the way this data is obtained and should produce the expected values.
[//]: # (werk v2)
# XSS in inventory tree
key | value
---------- | ---
date | 2024-06-07T07:20:37+00:00
version | 2.4.0b1
class | security
edition | cre
component | inv
level | 1
compatible | yes
Prior to this Werk an attacker with control over an agent was able to inject HTML in the output which was then rendered in the inventory tree of the coresponding host.
This problem exists only if the rule *Do hardware/software inventory* is set for the compromised agent/host.
We found this vulnerability internally.
**Affected Versions:**
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0
**Mitigations**:
If you are unable to patch you can disable inventory scanning for all hosts.
**Indicators of Compromise:**
You can check `var/check_mk/inventory/` for inventories with embedded HTML.
This only indicates current 'attacks'.
Previous attacks (where the agent does not output the payload anymore) are not discoverable after some time (caching).
**Vulnerability Management:**
We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector:
`CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L`
We assigned CVE-2024-5741 to this vulnerability.
**Changes:**
This Werk adds sanitation to the HTML output.
[//]: # (werk v2)
# cisco_temperature: Handle Invalid Device Readings
key | value
---------- | ---
date | 2024-06-13T12:14:09+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Cisco SNMP devices may report temperatures of "inf" or "-inf". According to
CISCO-ENTITY-SENSOR-MIB, these values are not valid.
Previously, Checkmk would treat non-finite temperatures as valid. This invalid
data would be written to `tmp/check_mk/counters/`, which then caused the
`Check_MK` service to become UNKNOWN. Furthermore, the services on the host
would become stale. With this Werk, the problematic values not persisted. Only
the affected service state will be UNKNOWN.
If you are affected, you can delete the corrupted counter file in
`tmp/check_mk/counters/<host name>`. To fix the readings reported by your
device, please directly contact Cisco.
[//]: # (werk v2)
# Restart scheduler after setting "use the status of a service"
key | value
---------- | ---
date | 2024-06-13T14:21:01+00:00
version | 2.4.0b1
class | fix
edition | cee
component | core
level | 1
compatible | yes
This fixes the case where the default check scheduler would not restart after
the user temporarily set "use the status of service" as the "host check
command". The corresponding log entry was "refuse to schedule invalid jobhost
... at 1970-0101 ...".
[//]: # (werk v2)
# mkeventd: Forward to remote Event Console or Syslog server if configured
key | value
---------- | ---
compatible | yes
version | 2.4.0b1
date | 2024-06-13T13:10:59+00:00
level | 1
class | fix
component | notifications
edition | cre
The notification method "Forward notification to Event Console" offers the
option to forward messages to a remote Event Console or Syslog server.
In earlier versions the messages were only forwarded if the local Event Console
(mkeventd) was not running.
This has been fixed.
[//]: # (werk v2)
# Test notifications: Match labels for hosts on remote sites
key | value
---------- | ---
date | 2024-06-11T17:19:29+00:00
version | 2.4.0b1
class | fix
edition | cre
component | notifications
level | 1
compatible | yes
Labels of hosts from remote sites were not added to the notification context.
This results in no match on testing a label condition, even the host had the
label configured.
Hosts on the central site were not affected.
[//]: # (werk v2)
# Don't escape customer name
key | value
---------- | ---
compatible | yes
version | 2.4.0b1
date | 2024-06-10T15:18:56+00:00
level | 1
class | fix
component | wato
edition | cme
If you created a customer with e.g. an ampersand in the customer name, the name
was escaped on the customers page showing "&" instead of "&".
Werk 16430 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: veeam_jobs: Always Monitor Result of Last Backup
Class: fix
Compatible: compat
Component: checks
Date: 1717598169
Edition: cee
Level: 1
Version: 2.2.0p28
Previously, the check plugin <code>veeam_jobs</code> would not always check the result of
the last backup job to determine the monitoring state. If the creation time was
an empty string, it would show <code>item not found</code>. Moreover, if the last
state of the plugin was <code>Starting</code>, <code>Working</code> or <code>Postprocessing</code>, then the
check would be OK, even if the last backup failed.
The check now shows all the information available unconditionally. Moreover,
<ul>
<li> a Success result is OK,</li>
<li> a Warning result is WARN,</li>
<li> a Failed result is CRIT,</li>
<li> a None result is OK or UNKNOWN. There is no change in behaviour in this case.</li>
</ul>
------------------------------------<diff>-------------------------------------------
Title: veeam_jobs: Always Monitor Result of Last Backup
Class: fix
Compatible: compat
Component: checks
Date: 1717598169
Edition: cee
Level: 1
Version: 2.2.0p28
Previously, the check plugin <code>veeam_jobs</code> would not always check the result of
the last backup job to determine the monitoring state. If the creation time was
an empty string, it would show <code>item not found</code>. Moreover, if the last
state of the plugin was <code>Starting</code>, <code>Working</code> or <code>Postprocessing</code>, then the
check would be OK, even if the last backup failed.
The check now shows all the information available unconditionally. Moreover,
- * a Success result is OK,
- * a Warning result is WARN,
- * a Failed result is CRIT,
- * a None result is OK or UNKNOWN. There is no change in behaviour in this case.
+ <ul>
+ <li> a Success result is OK,</li>
+ <li> a Warning result is WARN,</li>
+ <li> a Failed result is CRIT,</li>
+ <li> a None result is OK or UNKNOWN. There is no change in behaviour in this case.</li>
+ </ul>
+
Werk 16430 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# veeam_jobs: Always Monitor Result of Last Backup
key | value
---------- | ---
date | 2024-06-05T14:36:09+00:00
version | 2.3.0p6
class | fix
edition | cee
component | checks
level | 1
compatible | yes
Previously, the check plugin `veeam_jobs` would not always check the result of
the last backup job to determine the monitoring state. If the creation time was
an empty string, it would show `item not found`. Moreover, if the last
state of the plugin was `Starting`, `Working` or `Postprocessing`, then the
check would be OK, even if the last backup failed.
The check now shows all the information available unconditionally. Moreover,
* a Success result is OK,
* a Warning result is WARN,
* a Failed result is CRIT,
* a None result is OK or UNKNOWN. There is no change in behaviour in this case.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# veeam_jobs: Always Monitor Result of Last Backup
key | value
---------- | ---
date | 2024-06-05T14:36:09+00:00
version | 2.3.0p6
class | fix
edition | cee
component | checks
level | 1
compatible | yes
Previously, the check plugin `veeam_jobs` would not always check the result of
the last backup job to determine the monitoring state. If the creation time was
an empty string, it would show `item not found`. Moreover, if the last
state of the plugin was `Starting`, `Working` or `Postprocessing`, then the
check would be OK, even if the last backup failed.
The check now shows all the information available unconditionally. Moreover,
+
* a Success result is OK,
* a Warning result is WARN,
* a Failed result is CRIT,
* a None result is OK or UNKNOWN. There is no change in behaviour in this case.