[//]: # (werk v2)
# Fix failed expiration date check while license verification
key | value
---------- | ---
date | 2024-02-28T14:26:27+00:00
version | 2.4.0b1
class | fix
edition | cce
component | wato
level | 1
compatible | yes
If you encounter "[Error] Certificate is expired" on the licensing page please
run verification again.
[//]: # (werk v2)
# New APIs for plugin development
key | value
---------- | ---
date | 2024-02-26T21:27:58+00:00
version | 2.4.0b1
class | feature
edition | cre
component | checks
level | 2
compatible | yes
Checkmk 2.3 features new APIs for plugin development.
There are three new APIs, and a new version of the agent based API (also known as "Check API").
The replaced APIs will not be supported after 2.3 (details below).
Plugin APIs in general provide means to write own code that interacts with the main application using well defined and stable code libraries.
While Checkmk has always offered the possibility to add custom plugins, the APIs were often ad-hoc and undocumented.
In Checkmk 2.0 we started to address this with the introduction of the agent-based API.
With this werk, all important elements of creating your own monitoring plugins are covered by an API.
With the APIs we introduce here we clarify what is meant to be used by plugin developers and what are internal modules, which can and likely will change over time and should not be used.
This is beneficial for all involved parties:
* Checkmk developers can easily figure out what parts of the code can be changed without breaking plugins.
We can focus on providing stable APIs while gaining the freedom to rapidly refactor the backend code.
* Plugin developers know what features to use to prevent their plugin from unexpectedly breaking during an upgrade, without having to closely follow the changes we make to the code.
* Checkmk users can have reliable information on which of their extensions will continue to work after a major upgrade.
As a result, the increased transparency leads to a better stability and hence a better user experience on all sides.
While the APIs are also intended to be stable, the main focus now is on transparency.
All of the APIs have a limited scope, and we have tried to have them feature complete within these limits.
However, as the development of Checkmk progresses, we might have to add some features or redesign others.
The versioning of the APIs will allow us in these cases to maintain the old version (for a while) and provide documentation on how to migrate to the newer API version.
**While we recommend testing the APIs and highly appreciate any feedback: Be aware that during the beta phase incompatible changes to the APIs might occur.
Start with a small subset of your plugins to check out the APIs capabilities and limitations.
Wait for the stable release before migrating a large amount of plugins to avoid having to make adjustments in all of them.**
You can find a detailed technical documentation of the APIs in a running sites "Help" menu, under "Plugin API references".
## Compatibility
For all affected plugins (see below) the following migration timeline is supported:
For Checkmk 2.3 we tried our best to ensure all plugins will continue working as in 2.2.
Note that we can't guarantee all plugins will work for the above reasons.
We strongly recommend users migrate to the new APIs during the lifetime of 2.3.
With the update to 2.4 all measures to ensure that older plugins still work are dropped, effectively making it extremely unlikely that these plugins will continue to work.
## General changes and common API properties
The main changes of these APIs is to reduce side effects when importing the code (for better testablility) and allow for a better component oriented structure:
* We move away from the "registry" approach we had in the past, to a discovery based approach.
Plugins are instances of specific classes that are created in a certain place with a certain naming scheme.
* All plugins (rulesets, check plugins, metrics, ...) of the same "plugin family" can now live in a common folder.
A detailed description can be found in the technical documentation mentioned above.
Plugins already migrated by us can be found in the [cmk/plugins](https://github.com/Checkmk/checkmk/tree/master/cmk/plugins) folder of the source code.
## Rulesets API: `cmk.rulesets.v1`
This is the new API for the creation of rulesets used by the users to configure their plugins.
The supported Ruleset types and input form elements can be found in the technical documentation.
These are the plugins formally known to sit in your sites `local/share/check_mk/web/plugins/wato`.
To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/rulesets`.
## Graphing API: `cmk.graphing.v1`
This is the new API for the creation of objects required for metric visualization, such as perfometers and graphs.
The supported metric objects can be found in the technical documentation.
These plugins previously where located at `local/share/check_mk/web/plugins/metrics`.
To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/graphing`.
## Server side calls API: `cmk.server_side_calls.v1`
This is the new API for plugins that convert a configured ruleset for a special agent or active check to the command line command that is used to run the special agent or active check.
Details on the exposed classes and their usage can be found in the technical documentation.
These plugins previously where located at `local/share/check_mk/checks`, and filled a `special_agent_info` or `active_check_info` dictionary.
To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/server_side_calls`.
## New version of agent based API: `cmk.agent_based.v2`
The new version of the agent based API was mostly added to increase consistency with the other three APIs (discovery mechanism, plugin location).
It also features a couple of less important improvements. Details can be found in the technical documentation.
These plugins previously where located at `local/lib/check_mk/base/plugins/agent_based`.
To be discovered by Checkmk they now have to be in `local/lib/python3/cmk_addons/plugins/<YOUR PLUGIN FAMILY NAME>/agent_based`.
Title: Add m7i.large as aws resource type
Class: feature
Compatible: compat
Component: checks
Date: 1709038229
Edition: cre
Level: 1
Version: 2.1.0p41
You're affected if your aws_ec2_limits check reported "Unknown resource" and you're using "m7i.large".
The aws resource names are changing from time to time and we will need to find a more stable solution for that in the future.
But for now, this will be fixed by adding the resource name "m7i.large" to our internal list of aws resources.
Title: Path to mysql.ini under Windows for mk_sql
Class: fix
Compatible: compat
Component: checks
Date: 1708687568
Edition: cre
Level: 1
Version: 2.1.0p41
If you've been using mysql and the corresponding agent plugin <em>mk_sql</em>
under Windows, the plugin may have crashed and the agent output would then
show the following error:
C+:
<<<mysql_ping>>>
[[MySQL83]]
mysqladmin: File '\etc\check_mk\mysql.local.ini' not found (OS errno 2 - No such file or directory)
mysqladmin: [ERROR] Stopped processing the 'include' directive in file C:\ProgramData\checkmk\agent\config\mysql.ini at line 8.
C-:
Under Windows, the plugin config path <code>C:\ProgramData\checkmk\agent\config</code> is now used.
In contrast to the corresponding Linux plugin <code>mk_mysql</code>, the config path under Windows cannot be changed.
Title: Add m7i.large as aws resource type
Class: feature
Compatible: compat
Component: checks
Date: 1709038229
Edition: cre
Level: 1
Version: 2.2.0p23
You're affected if your aws_ec2_limits check reported "Unknown resource" and you're using "m7i.large".
The aws resource names are changing from time to time and we will need to find a more stable solution for that in the future.
But for now, this will be fixed by adding the resource name "m7i.large" to our internal list of aws resources.
Title: symantec_av: Don't run sav command if it isn't owned by root
Class: security
Compatible: compat
Component: checks
Date: 1709110689
Edition: cre
Level: 1
Version: 2.2.0p24
Symantec Anti Virus plugin uses /opt/Symantec/symantec_antivirus/sav command
to monitor a Symantec Anti Virus installation.
To prevent privilege escalation, the plugin (which is run by root user) must
not run executables which can be changed by less privileged users.
In the default installation, sav command is owned by root and root is the only
user with write permissions, which prevents privilege escalation attacks.
With this Werk, the plugin checks if sav command is owned by root and root
is the only user with write permissions before running the command. If that's not
the case the command won't be run. This prevents privilege escalation attacks if
the permissions of the sav command have been changed.
We rate this with a CVSS of 0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N).
This CVSS is primarily meant to please automatic scanners.
CMK-15318
Title: kaspersky_av: Don't run kav4fs-control or kesl-control if they aren't owned by root
Class: security
Compatible: compat
Component: checks
Date: 1709025290
Edition: cre
Level: 1
Version: 2.2.0p24
Kaspersky Anti-Virus plugin uses /opt/kaspersky/kav4fs/bin/kav4fs-control and
/opt/kaspersky/kesl/bin/kesl-control commands to monitor a Kaspersky Anti-Virus
installation.
To prevent privilege escalation, the plugin (which is run by root user) must
not run executables which can be changed by less privileged users.
In the default installation, kav4fs-control and kesl-control commands are owned
by root and root is the only user with write permissions, which prevents privilege
escalation attacks.
With this Werk, the plugin checks if control commands are owned by root and root
is the only user with write permissions before running the command. If that's not
the case the commands won't be run. This prevents privilege escalation attacks if
the permissions of the control commands have been changed.
We rate this with a CVSS of 0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N).
This CVSS is primarily meant to please automatic scanners.
[//]: # (werk v2)
# Add m7i.large as aws resource type
key | value
---------- | ---
compatible | yes
version | 2.4.0b1
date | 2024-02-27T12:50:29+00:00
level | 1
class | feature
component | checks
edition | cre
You're affected if your aws_ec2_limits check reported "Unknown resource" and you're using "m7i.large".
The aws resource names are changing from time to time and we will need to find a more stable solution for that in the future.
But for now, this will be fixed by adding the resource name "m7i.large" to our internal list of aws resources.
[//]: # (werk v2)
# heartbeat_crm_resources: unmanaged stopped resources could not go critical
key | value
---------- | ---
date | 2024-01-25T13:39:59+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Stopped resources are marked `CRIT`.
If a resources was stopped and unmanaged, it was not marked as `CRIT`.
[//]: # (werk v2)
# Fix "State if specific check plugins receive no monitoring data" of Rule "Status of the Checkmk service"
key | value
---------- | ---
date | 2024-01-29T12:49:03+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Rule "Status of the Checkmk service" provides a setting called "State if
specific check plugins receive no monitoring data" where you can specify a
regular expression to match specific check plugins, and assign a status for
the "Check_MK" service if this check plugins receives no data.
The feature did work correctly if you specified a Status worse than "WARN".
But the "Check_MK" service went to "WARN" even if there was an rule to set the
status to "OK" if the specific section did not receive any data. This is fixed now.