Werk 17082 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fixed another instance of hanging processes
key | value
---------- | ---
date | 2024-07-05T06:55:15+00:00
version | 2.3.0p11
class | fix
edition | cre
component | multisite
level | 1
compatible | yes
As explained in werk [#17080](https://checkmk.com/werk/17080) the wrong conditions could lead to processes not releasing crucial file locks and the site subsequently freezing.
However, the werk did not address all the conditions.
With this werk, the cleanup of open resources was improved, which together with werk [#17081](https://checkmk.com/werk/17081) fixes another instance of processes not releasing their locks.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fixed another instance of hanging processes
key | value
---------- | ---
date | 2024-07-05T06:55:15+00:00
version | 2.3.0p11
class | fix
- edition | cce
? ^
+ edition | cre
? ^
component | multisite
level | 1
compatible | yes
As explained in werk [#17080](https://checkmk.com/werk/17080) the wrong conditions could lead to processes not releasing crucial file locks and the site subsequently freezing.
However, the werk did not address all the conditions.
With this werk, the cleanup of open resources was improved, which together with werk [#17081](https://checkmk.com/werk/17081) fixes another instance of processes not releasing their locks.
[//]: # (werk v2)
# Rename host/item match rule search parameter to clarify behavior
key | value
---------- | ---
date | 2024-07-12T11:36:36+00:00
version | 2.3.0p11
class | fix
edition | cre
component | wato
level | 1
compatible | yes
The rule search page offers two parameters "Host match list" and "Item
match list". These parameters could be used to search for rules which
have their explicit host or item condition set up in such a way that it
matches the given host or service (either by being unset or set).
However, these parameters do not check other conditions and might return
rules which for other reasons (such as a second host tag condition for
example) still might not match the specified host or service.
This werk renames these fields to "Explicit host matching" and "Explicit
item matching" and expands on their inline help to clarify this
behavior.
To see which rules are effective on a given host, please refer to the
"effective parameters" item under the burger menu in a host monitoring
view.
[//]: # (werk v2)
# Check for predefined connections when deploying xinetd config
key | value
---------- | ---
date | 2024-07-01T07:23:49+00:00
version | 2.3.0p11
class | security
edition | cce
component | checks
level | 1
compatible | no
When an agent rule *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* was configured for an agent package one might assume that when installing this package the agent encrypts its traffic.
But when installing such a package on a system without systemd but with xinetd installed or a very old systemd versions, the agent was deployed without registration and encryption.
With this Werk the deployment script for systemd/xinetd checks for predefined/preconfigured connections and if it finds any it refuses to configure the legacy mode.
The agent is still installed though but will not be accessible via the network, so access with SSH will still be possible.
Therefore you can no longer use baked packages with auto registration for systems without systemd or very old systemd versions where the legacy mode is desired.
These systems need to be excluded from the *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* rule.
*Vulnerability Management*:
We do not rate this as a exploitable vulnerability but a safe guard for unintended configurations, therefore no CVE was assigned.
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`).
[//]: # (werk v2)
# KUBE: Addition of support for Kubernetes v1.29
key | value
---------- | ---
date | 2024-07-18T06:09:19+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 1
compatible | yes
With this release of Checkmk, we introduce support for version 1.29 of Kubernetes.
The supported versions are listed below:
Checkmk 2.2: 1.22, 1.23, 1.24, 1.25, 1.26, 1.27
Checkmk 2.3: 1.24, 1.25, 1.26, 1.27, 1.28, 1.29
The list of supported versions may not apply to future patch versions. For such cases, a
new werk will be released.
[//]: # (werk v2)
# Rename host/item match rule search parameter to clarify behavior
key | value
---------- | ---
date | 2024-07-12T11:36:36+00:00
version | 2.4.0b1
class | fix
edition | cre
component | wato
level | 1
compatible | yes
The rule search page offers two parameters "Host match list" and "Item
match list". These parameters could be used to search for rules which
have their explicit host or item condition set up in such a way that it
matches the given host or service (either by being unset or set).
However, these parameters do not check other conditions and might return
rules which for other reasons (such as a second host tag condition for
example) still might not match the specified host or service.
This werk renames these fields to "Explicit host matching" and "Explicit
item matching" and expands on their inline help to clarify this
behavior.
To see which rules are effective on a given host, please refer to the
"effective parameters" item under the burger menu in a host monitoring
view.
[//]: # (werk v2)
# Check for predefined connections when deploying xinetd config
key | value
---------- | ---
date | 2024-07-01T07:23:49+00:00
version | 2.4.0b1
class | security
edition | cce
component | checks
level | 1
compatible | no
When an agent rule *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* was configured for an agent package one might assume that when installing this package the agent encrypts its traffic.
But when installing such a package on a system without systemd but with xinetd installed or a very old systemd versions, the agent was deployed without registration and encryption.
With this Werk the deployment script for systemd/xinetd checks for predefined/preconfigured connections and if it finds any it refuses to configure the legacy mode.
The agent is still installed though but will not be accessible via the network, so access with SSH will still be possible.
Therefore you can no longer use baked packages with auto registration for systems without systemd or very old systemd versions where the legacy mode is desired.
These systems need to be excluded from the *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* rule.
*Vulnerability Management*:
We do not rate this as a exploitable vulnerability but a safe guard for unintended configurations, therefore no CVE was assigned.
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`).
Werk 15842 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Enhanced MS SQL Server monitoring
key | value
---------- | ---
date | 2024-04-03T07:47:56+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 2
compatible | yes
With this release MS SQL Server is monitored using new plugin and new GUI.
The old plugin is still supported but are considered deprecated.
Key Enhancements out-of-the-box:
- Configuration flexibility: The plugin can be configured through a YAML config file for any edition and/or a graphical user interface (GUI) for enterprise edition or better.
- Cross platform: The plugin can be deployed on Linux and Windows.
- Enhanced monitoring capabilities: Supports monitoring of remote databases on both Linux and Windows hosts, in addition to local monitoring on Windows hosts.
- Customizable monitoring sections: Sections are now selectable and configurable
- Customizable SQL statements: you may change SQL statement either manually(place file in `mssql` sub directory in config dir) or using `Custom files` rule in GUI.
- Multi-instance support: Enables the selection of different instances for monitoring. Every instance can be configured separately
- Multi-host support: possible to monitor databases on various hosts using one deployed plugin.
- Security enhancements: Limited support for certificates is now available.
- Asynchronous operation: Any section with exception `instances` can be set up for asynchronous operation.
- Piggyback: It's possible to direct the output of a plugin to a different host, rather than to the host that retrieves the data.
- Other improvements:
- Automatic detection of instances is possible for any Windows host, local and remote, depending on SQL Server Setup.
- Full logging support including rotation and file limits
- Limit for maximal connection counts
- Cache time and timeout can be configured too
With regard to the old plug-in, there are also a few restrictions at the moment:
- The database instances must be accessible via TCP/IP.
- If several databases are running on a system, each using their own IP addresses, these must be explicitly specified in the configuration of the agent plug-in, as the addresses and ports are currently not yet found automatically.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Enhanced MS SQL Server monitoring
key | value
---------- | ---
date | 2024-04-03T07:47:56+00:00
- version | 2.3.0b4
? ^ ^
+ version | 2.4.0b1
? ^ ^
class | feature
edition | cre
component | checks
level | 2
compatible | yes
With this release MS SQL Server is monitored using new plugin and new GUI.
The old plugin is still supported but are considered deprecated.
Key Enhancements out-of-the-box:
- Configuration flexibility: The plugin can be configured through a YAML config file for any edition and/or a graphical user interface (GUI) for enterprise edition or better.
- Cross platform: The plugin can be deployed on Linux and Windows.
- Enhanced monitoring capabilities: Supports monitoring of remote databases on both Linux and Windows hosts, in addition to local monitoring on Windows hosts.
- Customizable monitoring sections: Sections are now selectable and configurable
- Customizable SQL statements: you may change SQL statement either manually(place file in `mssql` sub directory in config dir) or using `Custom files` rule in GUI.
- Multi-instance support: Enables the selection of different instances for monitoring. Every instance can be configured separately
- Multi-host support: possible to monitor databases on various hosts using one deployed plugin.
- Security enhancements: Limited support for certificates is now available.
- Asynchronous operation: Any section with exception `instances` can be set up for asynchronous operation.
- Piggyback: It's possible to direct the output of a plugin to a different host, rather than to the host that retrieves the data.
- Other improvements:
- Automatic detection of instances is possible for any Windows host, local and remote, depending on SQL Server Setup.
- Full logging support including rotation and file limits
- Limit for maximal connection counts
- Cache time and timeout can be configured too
With regard to the old plug-in, there are also a few restrictions at the moment:
- The database instances must be accessible via TCP/IP.
- If several databases are running on a system, each using their own IP addresses, these must be explicitly specified in the configuration of the agent plug-in, as the addresses and ports are currently not yet found automatically.
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.