Werk 16342 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Rename service labels for Robotmk
key | value
---------- | ---
date | 2024-03-25T12:28:56+00:00
version | 2.4.0b1
class | feature
edition | cee
component | multisite
level | 2
compatible | yes
This is a follow-up for werk #13872.
The service labels have been renamed to 'cmk/rmk/html_last_log:yes' and 'cmk/rmk/html_last_error_log:yes'.
The icons for the last log file and last error log file will have an icon based on the new labels as well as the old ones from werk #13872.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Rename service labels for Robotmk
key | value
---------- | ---
date | 2024-03-25T12:28:56+00:00
- version | 2.3.0b4
? ^ ^
+ version | 2.4.0b1
? ^ ^
class | feature
edition | cee
component | multisite
level | 2
compatible | yes
This is a follow-up for werk #13872.
The service labels have been renamed to 'cmk/rmk/html_last_log:yes' and 'cmk/rmk/html_last_error_log:yes'.
The icons for the last log file and last error log file will have an icon based on the new labels as well as the old ones from werk #13872.
Werk 16343 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# rmk: Remove 'Load environment variables from file' field in Robotmk Scheduler bakery rule
key | value
---------- | ---
date | 2024-03-27T14:51:09+00:00
version | 2.4.0b1
class | feature
edition | cee
component | wato
level | 1
compatible | no
Users who have configured the 'Load environment variable from file' field in the Robotmk Scheduler rule are affected by this incompatible werk. Any rules that contain the value for this field will be automatically migrated during the update and the value will be removed from the rules.
Originally, this field was designed to be fully compatible with Robots that could be used within Robocorp's cloud environment.
However, as Robocorp shifted its focus from Robot Framework to Python developers, the need for the VS Code extensions provided by Robocorp became redundant. The language server for Robot Framework would no longer be maintained, and the "RobotCode" extension would no longer serve Robot Framework users. In addition, both extensions had a rather confusing interface and didn't work well together. Now the RobotCode extension is the only necessary extension for VS Code, and it works very well.
The env.json file generated from this field was used exclusively by the Robocorp extension. This approach allowed local initiation and debugging of automations with the exact set of environment variables configured, mirroring those set later in the Cloud UI.
For the above reasons, we decided to remove this field.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# rmk: Remove 'Load environment variables from file' field in Robotmk Scheduler bakery rule
key | value
---------- | ---
date | 2024-03-27T14:51:09+00:00
- version | 2.3.0b4
? ^ ^
+ version | 2.4.0b1
? ^ ^
class | feature
edition | cee
component | wato
level | 1
compatible | no
Users who have configured the 'Load environment variable from file' field in the Robotmk Scheduler rule are affected by this incompatible werk. Any rules that contain the value for this field will be automatically migrated during the update and the value will be removed from the rules.
Originally, this field was designed to be fully compatible with Robots that could be used within Robocorp's cloud environment.
However, as Robocorp shifted its focus from Robot Framework to Python developers, the need for the VS Code extensions provided by Robocorp became redundant. The language server for Robot Framework would no longer be maintained, and the "RobotCode" extension would no longer serve Robot Framework users. In addition, both extensions had a rather confusing interface and didn't work well together. Now the RobotCode extension is the only necessary extension for VS Code, and it works very well.
The env.json file generated from this field was used exclusively by the Robocorp extension. This approach allowed local initiation and debugging of automations with the exact set of environment variables configured, mirroring those set later in the Cloud UI.
For the above reasons, we decided to remove this field.
Werk 15844 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Microsoft SQL Server (Windows) ruleset is deprecated
key | value
---------- | ---
date | 2024-04-17T13:40:06+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 2
compatible | no
We've introduced a new `Microsoft SQL Server (Linux, Windows)` plug-in for MS SQL
database monitoring, see
[werk 15842: Enhanced MS SQL Server monitoring](https://checkmk.com/werk/15842).
The new plugin extends the functionality of `Microsoft SQL Server (Windows)`
by adding more options and features.
We recommend that you upgrade to the `Microsoft SQL Server (Linux, Windows)` plug-in to monitor MS SQL databases. This new agent plugin can be deployed
alongside the Checkmk agent on your database systems, just like the previous
plugin. You can also use this plugin on any Windows or Linux
server to monitor remote MSSQL servers over the network.
The previous `Microsoft SQL Server (Windows)` rule set is deprecated and renamed to `Microsoft SQL Server (deprecated)`. Please note that you may need to adjust settings on your databases or continue running the old plug-in for the time being, as the agent plug-in cannot connect to local database instances that are not available over a TCP/IP connection.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Microsoft SQL Server (Windows) ruleset is deprecated
key | value
---------- | ---
date | 2024-04-17T13:40:06+00:00
- version | 2.3.0b6
? ^ ^
+ version | 2.4.0b1
? ^ ^
class | feature
edition | cre
component | checks
level | 2
compatible | no
We've introduced a new `Microsoft SQL Server (Linux, Windows)` plug-in for MS SQL
database monitoring, see
[werk 15842: Enhanced MS SQL Server monitoring](https://checkmk.com/werk/15842).
The new plugin extends the functionality of `Microsoft SQL Server (Windows)`
by adding more options and features.
We recommend that you upgrade to the `Microsoft SQL Server (Linux, Windows)` plug-in to monitor MS SQL databases. This new agent plugin can be deployed
alongside the Checkmk agent on your database systems, just like the previous
plugin. You can also use this plugin on any Windows or Linux
server to monitor remote MSSQL servers over the network.
The previous `Microsoft SQL Server (Windows)` rule set is deprecated and renamed to `Microsoft SQL Server (deprecated)`. Please note that you may need to adjust settings on your databases or continue running the old plug-in for the time being, as the agent plug-in cannot connect to local database instances that are not available over a TCP/IP connection.
Werk 16341 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# rmk: Ignore RCC suites and RCC profile configuration if CORE mode is active
key | value
---------- | ---
date | 2024-03-21T15:36:04+00:00
version | 2.4.0b1
class | fix
edition | cee
component | checks
level | 1
compatible | yes
When the Robotmk Core MKP is installed, RCC Suites configuration and RCC Profile configuration are not available as they are Enterprise features.
Previously, there were scenarios where RCC suites were running even though the Robotmk Core MKP was installed.
The Agent Bakery would use previously saved Enterprise configurations without first migrating them to their CoreMode counterparts.
This has now been fixed and the licensing mode is checked when the agent is baked. This means the RCC Suites/RCC Profile configuration will be ignored during the bake process.
This prevents users from inadvertently relying on a paid feature when CoreMode is enabled.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# rmk: Ignore RCC suites and RCC profile configuration if CORE mode is active
key | value
---------- | ---
date | 2024-03-21T15:36:04+00:00
- version | 2.3.0b4
? ^ ^
+ version | 2.4.0b1
? ^ ^
class | fix
edition | cee
component | checks
level | 1
compatible | yes
When the Robotmk Core MKP is installed, RCC Suites configuration and RCC Profile configuration are not available as they are Enterprise features.
Previously, there were scenarios where RCC suites were running even though the Robotmk Core MKP was installed.
The Agent Bakery would use previously saved Enterprise configurations without first migrating them to their CoreMode counterparts.
This has now been fixed and the licensing mode is checked when the agent is baked. This means the RCC Suites/RCC Profile configuration will be ignored during the bake process.
This prevents users from inadvertently relying on a paid feature when CoreMode is enabled.
Werk 16463 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Dashlets: Fix error while fetching data
key | value
---------- | ---
date | 2024-04-15T08:21:17+00:00
version | 2.4.0b1
class | fix
edition | cee
component | multisite
level | 1
compatible | yes
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Dashlets: Fix error while fetching data
key | value
---------- | ---
date | 2024-04-15T08:21:17+00:00
- version | 2.3.0b5
? ^ ^
+ version | 2.4.0b1
? ^ ^
class | fix
edition | cee
component | multisite
level | 1
compatible | yes
Werk 16559 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Host properties: Make "Additional IPv4/6 addresses" depend on "IP address family" attribute
key | value
---------- | ---
date | 2024-03-01T09:06:53+00:00
version | 2.4.0b1
class | fix
edition | cre
component | wato
level | 1
compatible | yes
The attributes "IPv4/6 address" are toggled based on the "IP address family"
attribute in the host properties dialog. This behavior is now also applied to
the "Additional IPv4/6 addresses" attributes.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Host properties: Make "Additional IPv4/6 addresses" depend on "IP address family" attribute
key | value
---------- | ---
date | 2024-03-01T09:06:53+00:00
- version | 2.3.0b1
? ^
+ version | 2.4.0b1
? ^
class | fix
edition | cre
component | wato
level | 1
compatible | yes
The attributes "IPv4/6 address" are toggled based on the "IP address family"
attribute in the host properties dialog. This behavior is now also applied to
the "Additional IPv4/6 addresses" attributes.
[//]: # (werk v2)
# Set group on sqlnet.ora for custom installation paths
key | value
---------- | ---
date | 2024-07-16T06:35:14+00:00
version | 2.3.0p11
class | fix
edition | cre
component | checks
level | 1
compatible | yes
You're affected by this werk, if you are monitoring oracle databases and the agent bakery.
Since [Werk #15328](https://checkmk.com/werk/15328), the group ownership of `sqlnet.ora` can be set via the agent updater.
However, the bakery did not yet honor custom installation paths, which are set via the rule `"Installation paths for agent files (Linux, UNIX)"`.
From this werk on, the bakery and the agent updater do also set the configured group on `sqlnet.ora`.
[//]: # (werk v2)
# Use comment during event rewrite instead of text
key | value
---------- | ---
date | 2024-07-12T12:57:44+00:00
version | 2.3.0p11
class | fix
edition | cee
component | ec
level | 1
compatible | yes
[//]: # (werk v2)
# Livestatus injection in mknotifyd
key | value
---------- | ---
date | 2024-07-08T11:58:09+00:00
version | 2.3.0p11
class | security
edition | cee
component | notifications
level | 1
compatible | yes
Before this Werk a malicious notification sent via mknotifyd could allow an attacker to send arbitrary livestatus commands.
With this Werk livestatus escaping was added to the relevant functions.
This issue was found during internal review.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 6.5 Medium (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L`) and assigned `CVE-2024-6542`.