Werk 17076 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fix float rule values not checking all validations
key | value
---------- | ---
date | 2024-06-25T07:08:34+00:00
version | 2.3.0p10
class | fix
edition | cre
component | wato
level | 1
compatible | no
In Checkmk, it's possible for any rule value to specify custom
validation functions to stop users from accidentally entering invalid
data. Before this werk, the set of rule fields that allowed floating
point values to be set in rare cases did not check these custom
validation functions when setting up a rule.
With this werk, we restore the expected functionality and check
the validity of all floating point values in a rule.
**Incompatibility**
Some users might have created rules which should not have been valid.
You will find out if such a rule is present in your setup when you
update your site. The update process will raise an error warning you of
any rule values that break custom validators. This error will tell you
about the invalid rule and the reason it is invalid. Please abort the
update process, fix the invalid value and restart the update process.
**Plugin developers**
If you have created a rule value with the `validate` (ValueSpec) or
`custom_validate` (Form Spec) argument set, your rule will now correctly
use provided functions to check the validity of the data. No change to
the rule is necessary.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fix float rule values not checking all validations
key | value
---------- | ---
date | 2024-06-25T07:08:34+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | fix
edition | cre
component | wato
level | 1
compatible | no
In Checkmk, it's possible for any rule value to specify custom
validation functions to stop users from accidentally entering invalid
data. Before this werk, the set of rule fields that allowed floating
point values to be set in rare cases did not check these custom
validation functions when setting up a rule.
With this werk, we restore the expected functionality and check
the validity of all floating point values in a rule.
**Incompatibility**
Some users might have created rules which should not have been valid.
You will find out if such a rule is present in your setup when you
update your site. The update process will raise an error warning you of
any rule values that break custom validators. This error will tell you
about the invalid rule and the reason it is invalid. Please abort the
update process, fix the invalid value and restart the update process.
**Plugin developers**
If you have created a rule value with the `validate` (ValueSpec) or
`custom_validate` (Form Spec) argument set, your rule will now correctly
use provided functions to check the validity of the data. No change to
the rule is necessary.
Werk 16533 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Event Console fix regex match in rule text
key | value
---------- | ---
date | 2024-07-01T15:31:04+00:00
version | 2.3.0p10
class | fix
edition | cee
component | ec
level | 1
compatible | yes
Event console method compile_matching_value had a typo
which caused a valid regex to not match, because it was sent as a string
SUP-19224
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Event Console fix regex match in rule text
key | value
---------- | ---
date | 2024-07-01T15:31:04+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | fix
edition | cee
component | ec
level | 1
compatible | yes
Event console method compile_matching_value had a typo
which caused a valid regex to not match, because it was sent as a string
SUP-19224
Werk 16863 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# proxmox: Fix log parsing crash for Proxmox versions 3.2.4 and newer
key | value
---------- | ---
compatible | yes
version | 2.3.0p10
date | 2024-06-28T14:34:01+00:00
level | 1
class | fix
component | checks
edition | cre
The backup log format changed in Proxmox version 3.2.4 which resulted in a crash
in the Proxmox special agent.
The special agent can now handle both old and the new format of backup log messages.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# proxmox: Fix log parsing crash for Proxmox versions 3.2.4 and newer
key | value
---------- | ---
compatible | yes
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
date | 2024-06-28T14:34:01+00:00
level | 1
class | fix
component | checks
edition | cre
The backup log format changed in Proxmox version 3.2.4 which resulted in a crash
in the Proxmox special agent.
The special agent can now handle both old and the new format of backup log messages.
Werk 17119 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# parent_scan: resolve failing parent scan background job
key | value
---------- | ---
date | 2024-07-02T12:39:27+00:00
version | 2.3.0p10
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
The REST API endpoint to initiate the parent scan background job
returned a 204 status code, which theoretically is correct. However,
the started background job failed immediately due to an invalid Python
syntax concerning the involving requested hosts. This werk fixes the issue.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# parent_scan: resolve failing parent scan background job
key | value
---------- | ---
date | 2024-07-02T12:39:27+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
The REST API endpoint to initiate the parent scan background job
returned a 204 status code, which theoretically is correct. However,
the started background job failed immediately due to an invalid Python
syntax concerning the involving requested hosts. This werk fixes the issue.
Werk 17010 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# XSS in SQL check parameters
key | value
---------- | ---
date | 2024-06-17T10:08:19+00:00
version | 2.3.0p10
class | security
edition | cre
component | wato
level | 1
compatible | yes
Prior to this Werk an attacher could add HTML to one parameter of the *Check SQL database* rule which was executed on the overview page.
We found this vulnerability internally.
**Affected Versions**:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (probably older versions as well)
**Indicators of Compromis**:
The creation of such rules is logged in the audit log. You can therefore check the `wato_audit.log` either on the terminal or in the UI for entries that contain malicious HTML.
**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-6052 to this vulnerability.
**Changes**:
This Werk fixes the escaping.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# XSS in SQL check parameters
key | value
---------- | ---
date | 2024-06-17T10:08:19+00:00
- version | 2.3.0p8
? ^
+ version | 2.3.0p10
? ^^
class | security
edition | cre
component | wato
level | 1
compatible | yes
Prior to this Werk an attacher could add HTML to one parameter of the *Check SQL database* rule which was executed on the overview page.
We found this vulnerability internally.
**Affected Versions**:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (probably older versions as well)
**Indicators of Compromis**:
The creation of such rules is logged in the audit log. You can therefore check the `wato_audit.log` either on the terminal or in the UI for entries that contain malicious HTML.
**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-6052 to this vulnerability.
**Changes**:
This Werk fixes the escaping.
Werk 16753 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# HW/SW Inventory: Fix missing joined service columns if a service is assigned to a cluster
key | value
---------- | ---
date | 2024-07-01T14:32:58+00:00
version | 2.3.0p10
class | fix
edition | cre
component | multisite
level | 1
compatible | yes
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# HW/SW Inventory: Fix missing joined service columns if a service is assigned to a cluster
key | value
---------- | ---
date | 2024-07-01T14:32:58+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | fix
edition | cre
component | multisite
level | 1
compatible | yes
Werk 16864 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# snmp: Fix error in SNMP context serialization introduced with werk 16862
key | value
---------- | ---
date | 2024-07-03T07:48:10+00:00
version | 2.3.0p10
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Werk 16862, which solved one SNMP context serialization bug, introduced another one.
When using SNMP contexts, the change activation crashes in 2.3.0p8.
After this Werk, SNMP contexts should work without errors.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# snmp: Fix error in SNMP context serialization introduced with werk 16862
key | value
---------- | ---
date | 2024-07-03T07:48:10+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Werk 16862, which solved one SNMP context serialization bug, introduced another one.
When using SNMP contexts, the change activation crashes in 2.3.0p8.
After this Werk, SNMP contexts should work without errors.
Werk 17016 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# notification_rules: typo in field sort_order_for_bulk_notifications
key | value
---------- | ---
date | 2024-07-03T05:22:21+00:00
version | 2.3.0p10
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
The REST-API endpoints previously had a typo in the field
'sort_order_for_bulk_notifications'. The second t was missing.
This werk now corrects this.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# notification_rules: typo in field sort_order_for_bulk_notifications
key | value
---------- | ---
date | 2024-07-03T05:22:21+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
The REST-API endpoints previously had a typo in the field
'sort_order_for_bulk_notifications'. The second t was missing.
This werk now corrects this.
Werk 17031 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# TrippLite UPS: discover devices with .1.3.6.1.4.1.850.1 as sysObjectID
key | value
---------- | ---
date | 2024-06-26T16:13:34+00:00
version | 2.3.0p10
class | feature
edition | cre
component | checks
level | 1
compatible | yes
TrippLite UPSs use OID .1.3.6.1.4.1.850.1 as sysObjectID.
These devices are currently not discovered and monitored.
This has now been changed and they will be discovered.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# TrippLite UPS: discover devices with .1.3.6.1.4.1.850.1 as sysObjectID
key | value
---------- | ---
date | 2024-06-26T16:13:34+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | feature
edition | cre
component | checks
level | 1
compatible | yes
TrippLite UPSs use OID .1.3.6.1.4.1.850.1 as sysObjectID.
These devices are currently not discovered and monitored.
This has now been changed and they will be discovered.
Werk 17077 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Allow filesystem service rule levels to go above 100%
key | value
---------- | ---
date | 2024-06-25T10:07:14+00:00
version | 2.3.0p10
class | feature
edition | cre
component | wato
level | 1
compatible | yes
Previously, the option `Levels for used/free space` of various
`Filesystem` rules did not allow percent values beyond 101.0 %. With
this werk any non-negative value can be set, allowing virtualized file
systems to be monitored more granularly.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Allow filesystem service rule levels to go above 100%
key | value
---------- | ---
date | 2024-06-25T10:07:14+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p10
? ^^
class | feature
edition | cre
component | wato
level | 1
compatible | yes
Previously, the option `Levels for used/free space` of various
`Filesystem` rules did not allow percent values beyond 101.0 %. With
this werk any non-negative value can be set, allowing virtualized file
systems to be monitored more granularly.