Merge branch 'Checkmk:master' into feature_add_cisco_wlc_clients_c9800_lc_k9

Author: meni2029

.github/OWNERS

@@ -1,9 +1,5 @@
-# Component AI Tools
-#
-# Find information about code-owners (+ find-owners syntax) here:
-#  https://android-review.googlesource.com/plugins/code-owners/Documentation/backend-find-owners-cookbook.html
-#  https://android-review.googlesource.com/plugins/code-owners/Documentation/backend-find-owners.html#syntax
+# CI platform
 
-set noparent  # don't inherit owners information from parent folders
+set noparent
 
-file:/component_owners/ai_tools/OWNERS_DEFINITION
+file:/component_owners/ci_platform/OWNERS_DEFINITION

.werks/17759.md

@@ -0,0 +1,21 @@
+[//]: # (werk v2)
+# Fixed removal of non-sticky acknowledgements
+
+key        | value
+---------- | ---
+date       | 2025-12-03T14:37:59+00:00
+version    | 2.5.0b1
+class      | fix
+edition    | cee
+component  | cmc
+level      | 1
+compatible | yes
+
+Non-sticky acknowledgements of soft non-OK states have been removed even
+when the host or service stayed in the same soft non-OK state. This was
+inconsistent with the way Nagios works and has been fixed.
+
+Note: If you e.g. add a non-sticky acknowledgement for a soft-WARN state
+and the service goes to soft-CRIT, the acknowledgement will get removed.
+In other words: You acknowledge only the current state, not a general
+"non-OK" state, which is consistent with Nagios.

.werks/17779.md

@@ -0,0 +1,26 @@
+[//]: # (werk v2)
+# cmciii_io: Align the check with the checkman
+
+key        | value
+---------- | ---
+date       | 2025-09-09T08:57:53+00:00
+version    | 2.5.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+Previously, the cmciii_io check would incorrectly report a CRIT state for relay
+outputs when the status was "Off". This was due to special-case logic that
+treated relay devices differently from other I/O ports.
+
+The check has been simplified to consistently apply the same state mapping to
+all I/O devices:
+- "OK", "Off", and "Closed" states map to OK
+- "On" and "Open" states map to WARN
+- Unknown states default to WARN
+
+This fix ensures that relay outputs with "Off" status now correctly report OK
+state instead of CRIT, aligning the behavior with the documented checkman
+specification.

.werks/18479.md

@@ -0,0 +1,19 @@
+[//]: # (werk v2)
+# Use fractions of seconds for VSphere System Time Offset
+
+key        | value
+---------- | ---
+date       | 2025-12-04T12:19:02+00:00
+version    | 2.5.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+[Werk 17197](https://checkmk.com/werk/17197) accidentially rounded a timestamp
+to whole seconds. This lead to much higher values for the VSphere System Time
+Ofsset check.
+
+Also the two function calls for taking the local time and asking VSphere for the
+current time was moved closer to each other.

.werks/18596.md

@@ -0,0 +1,17 @@
+[//]: # (werk v2)
+# kernel_performance: Don't record negative number of context switches on reboot
+
+key        | value
+---------- | ---
+date       | 2025-12-08T10:09:42+00:00
+version    | 2.5.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+After a system reboot, the "Kernel Performance" service could record a negative number of context switches.
+This was caused by a counter reset during the reboot process.
+
+With this update, such negative results are now skipped and not recorded.

.werks/18600.md

@@ -0,0 +1,76 @@
+[//]: # (werk v2)
+# Preview of upcoming new plug-in APIs
+
+key        | value
+---------- | ---
+date       | 2025-11-16T20:05:52+00:00
+version    | 2.5.0b1
+class      | feature
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+Checkmk 2.5 features four new **unstable** APIs for plugin development.
+There are three new (versioned) APIs, and a new version of the bakery API.
+The replaced APIs will be removed in Checkmk 2.7 (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.
+
+Over the last versions we gradually replaced more and more of the poorly documented and unversioned APIs.
+The three new APIs do this for the special agents, active checks and HW/SW inventory views.
+
+All four of these APIs are incuded as an "unstable" version.
+You can find a detailed technical documentation of the APIs [online](https://docs.checkmk.com/plugin-api/master/) or in a running sites' "Help" menu, under "Plugin API references".
+
+We would love to receive your feedback via the [Checkmk Forum](https://forum.checkmk.com/c/exchange/new-devapi).
+You can of course also ask for help there.
+
+## APIs
+
+#### `cmk.bakery.v2_unstable`
+
+This is the successor of `cmk.base.cee.plugins.bakery.bakery_api.v1`.
+With version 2 of this API the bakery plugins are included in the new plug-in family layout (at `cmk_addons.plugins.<YOUR_NAME_HERE>.bakery`).
+
+There's a few other differences that you can read about in the [developer documentation](https://docs.checkmk.com/plugin-api/master/cmk.base.plugins.bakery.bakery_api/index.html#module-cmk.bakery.v2_unstable).
+
+#### `cmk.inventory_ui.v1_unstable`
+
+This is the new API to write user interfaces for HW/SW inventory entries.
+
+#### `cmk.password_store.v1_unstable`
+
+This API provides functionality to interact with the password store, mostly to access stored secrets.
+You will most likely want to use this in your special agents and active checks.
+
+#### `cmk.server_side_programs.v1_unstable`
+
+This API provides convenience features to be used in special agents and active checks.
+The most important ones are decorators to create crash reports and a class that allows to persist some data from one call to another.
+
+
+## Compatibility and timeline
+
+For all these four APIs the same timeline is planned:
+
+### Checkmk 2.5
+
+The APIs are released in an "unstable" version.
+This means that while we intend to release the APIs like this, we are not yet committed to keep them exactly as they are, and might change them in an incompatible manner.
+This allows us to gather some experience and react to your feedback.
+
+**Plug-in developers are encouraged to try out these APIs and give us their
+feedback via the [Checkmk Forum](https://forum.checkmk.com/c/exchange/new-devapi).**
+
+### Checkmk 2.6
+
+The APIs are released as stable version (their names change accordingly).
+We strongly recommend users migrate to the new APIs during the lifetime of 2.6.
+
+### Checkmk 2.7
+
+All functionality being replaced by the new APIs will be removed.
+In particular `cmk.special_agents`, `cmk.utils.password_store`, `cmk.base.cee.plugins.bakery.bakery_api.v1` and `cmk.bakery.v1`.
+**All plug-ins not migrated to the new APIs will stop working.**
+

.werks/18700.md

@@ -0,0 +1,16 @@
+[//]: # (werk v2)
+# Ensure new lines before and after sql based sections in mk_oracle
+
+key        | value
+---------- | ---
+date       | 2025-11-26T08:03:03+00:00
+version    | 2.5.0b1
+class      | fix
+edition    | cre
+component  | checks
+level      | 1
+compatible | yes
+
+mk_oracle sometimes produces output where two sections are concatenated without a line break. This happens due to misconfigured NLS parameters or errors in custom SQL statements, making the output unable to process.
+
+To fix this, mk_oracle now outputs an explicit new line before and after each SQL-based section. This ensures that sections are properly separated without requiring any changes to your existing configuration.

.werks/18702.md

@@ -0,0 +1,15 @@
+[//]: # (werk v2)
+# Remove debug option from redfish special agent
+
+key        | value
+---------- | ---
+date       | 2025-12-05T12:19:55+00:00
+version    | 2.5.0b1
+class      | fix
+edition    | cre
+component  | multisite
+level      | 1
+compatible | yes
+
+An additional debug mode was provided in the GUI for the Redfish special agent. However, this generated additional log files and did not comply with the relevant debugging standards for special agents.
+Since a CLI-based debug option already exists, this additional debug mode was removed.

.werks/18734.md

@@ -0,0 +1,25 @@
+[//]: # (werk v2)
+# OTel: Separate read-only and full-access permissions for OTel Collector configurations
+
+key        | value
+---------- | ---
+date       | 2025-11-27T12:34:08+00:00
+version    | 2.5.0b1
+class      | feature
+edition    | cce
+component  | checks
+level      | 1
+compatible | yes
+
+The OTel Collector configuration now uses a clearer permission model with two permissions:
+
+read_otel_collector — allows viewing OTel Collector configurations
+
+otel_collector — grants full access, including creating, editing, and deleting configurations
+
+Users with only read_otel_collector can view all configuration details but will receive a permission error if they attempt to edit or delete anything.
+This lets operational users access the information they need without exposing administrative actions.
+
+Additionally, the OTel receiver listing page now shows HTTP and gRPC credentials, making it easier for users to retrieve the required connection parameters for their agents or scrapers.
+
+Administrators should review existing roles to ensure users have the appropriate level of access.

.werks/18879.md

@@ -0,0 +1,27 @@
+[//]: # (werk v2)
+# New 'csm' command-line tool for Checkmk Synthetic Monitoring
+
+key        | value
+---------- | ---
+date       | 2025-12-03T00:12:14+00:00
+version    | 2.5.0b1
+class      | feature
+edition    | cee
+component  | checks
+level      | 1
+compatible | yes
+
+The new command-line tool `csm` (Checkmk Synthetic Monitoring) serves as a standalone, lean abstraction layer above the open source tool micromamba.
+
+The background to this is the future discontinuation of the "RCC" functionality that creates environments for executing Robot Framework tests.
+In particular, RCC's ability to execute post-installation commands after the environment has been created is not available in "micromamba" (introduced as a replacement for RCC in Checkmk 2.5).
+
+CSM brings back the convenience to create test environments with a single command without having to worry about the details of the micromamba syntax or necessary additional postinstall steps.
+
+The subcommand "csm env" encapsulates all tasks related to environment management (creating, activating, deactivating, and packing/unpacking environments).
+
+The subcommand "csm robot create" is used to quickly initialize new Robot Framework projects. The tool creates a new robot test structure and fills it with a fixed set of skeleton files from a minimal sample project. This provides users with ready-to-use directory and project structures without having to manually copy recurring boilerplate files. The aim is to simplify the start of new projects, ensure consistent structures and significantly reduce the time to the first functional test.
+
+"csm robot" will be given additional subcommands in the future, including the execution of robots with RobotCode profiles (used in VS Code).
+
+The csm tool is available for download on GitHub: https://github.com/Checkmk/csm/releases