Werk 16114 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: folder_config: Extend GET and DELETE endpoints folder name pattern to match the CREATE enpoint one
Class: fix
Compatible: compat
Component: rest-api
Date: 1696846527
Edition: cre
Knowledge: doc
Level: 1
Version: 2.3.0b1
Prior to this Werk, the folder name pattern for GET and DELETE endpoints did not allow the use of unicode characters while they were supported by the CREATE endpoint, with the result that folders created with such characters could not be accessed or deleted from the REST API.
For example, the user was able to create a folder named û亿Ï8Ĺ, which then could not be read or deleted from the API.
This Werk widens the folder name pattern on GET and DELETE endpoints to align with the CREATE one and now all of them support unicode characters.
------------------------------------<diff>-------------------------------------------
Title: folder_config: Extend GET and DELETE endpoints folder name pattern to match the CREATE enpoint one
Class: fix
Compatible: compat
Component: rest-api
Date: 1696846527
Edition: cre
Knowledge: doc
Level: 1
Version: 2.3.0b1
- Previously, the folder name pattern for GET and DELETE endpoints were stricter than the CREATE, provoking that a new folder could not be retrieved nor deleted. This fix widens the folder name pattern on GET and DELETE endpoints to align with the CREATE one.
+ Prior to this Werk, the folder name pattern for GET and DELETE endpoints did not allow the use of unicode characters while they were supported by the CREATE endpoint, with the result that folders created with such characters could not be accessed or deleted from the REST API.
+
+ For example, the user was able to create a folder named û亿Ï8Ĺ, which then could not be read or deleted from the API.
+
+ This Werk widens the folder name pattern on GET and DELETE endpoints to align with the CREATE one and now all of them support unicode characters.
[//]: # (werk v2)
# agent_azure: fix parsing loadbalancer data
key | value
---------- | ---
date | 2024-03-06T15:46:21+00:00
version | 2.3.0b3
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The agent would crash if information (backend pools or outbound rules) was missing for a load balancer.
This werk ensures that the system handles scenarios where this data may not be present.
[//]: # (werk v2)
# Robotmk: Add Inventory
key | value
---------- | ---
date | 2024-03-13T10:26:52+00:00
version | 2.3.0b3
class | feature
edition | cee
component | checks
level | 1
compatible | yes
This Werks adds a HW/SW inventory for Robotmk. The content is under active development.
[//]: # (werk v2)
# Handle empty operational status during interface inventory
key | value
---------- | ---
date | 2024-03-14T13:48:35+00:00
version | 2.3.0b3
class | fix
edition | cre
component | checks
level | 1
compatible | yes
`inv_if.py` crashed on empty oper_status.
This is fixed now as at least on some Cisco ASA/FirePower devices this value is empty.
[//]: # (werk v2)
# Monitor Redfish compatible management boards / BMCs via optional MKP
key | value
---------- | ---
date | 2024-03-06T16:44:06+00:00
version | 2.3.0b3
class | feature
edition | cre
component | checks
level | 1
compatible | yes
You can now monitor _Redfish_ compatible management boards / BMCs with Checkmk.
To do so, please enable the natively shipped MKP redfish in _Setup --> Extension packages_ (in commercial editions of Checkmk) or via the command line tool `mkp` (in Checkmk Raw).
This will enable a new datasource program under _Setup --> Other integrations --> Redfish Compatible Management Controller_.
This is an experimental integration created by the Checkmk community (Andreas Döhler from Bechtle), which has already been tested in many environments.
However, due to the diverse nature of server hardware, we plan to integrate it entirely for Checkmk 2.4.0, once we have gathered further feedback.
[//]: # (werk v2)
# Publish permission handling for various components
key | value
---------- | ---
compatible | no
version | 2.3.0b3
date | 2024-03-14T09:54:25+00:00
level | 1
class | fix
component | multisite
edition | cre
Werk 13498 introduced the possibility to set limit publish permissions
to certain contact groups, sites etc. Still, the permission "Publish views"
(e.g. for publishing views) was needed to see the published views. With
Werk 16320 this has been fixed for dashboards, views and reports.
This werk fixes the behavior for the remaining components (Bookmarks, Graphs,
SLAs and Reports).
Note: Please check the respective publish configuration.
[//]: # (werk v2)
# bulk discovery: remove mode parameter and introduce options
key | value
---------- | ---
date | 2024-03-11T08:55:56+00:00
version | 2.3.0b3
class | feature
edition | cre
component | rest-api
level | 1
compatible | no
Starting with the 2.3, the bulk discovery mode has been split up
for more granular control regarding the discovery execution. This
werk now introduces the same approach to the equivalent REST API
bulk discovery endpoint introducing the 'options' field. The previous 'mode'
field is deprecated with the 2.3 and will be removed in 2.4. The user should
migrate existing scripts to make use of the 'options' field.
[//]: # (werk v2)
# check_httpv2: Introduce a reworked way to test web sites
key | value
---------- | ---
date | 2024-03-08T10:06:58+00:00
version | 2.3.0b3
class | feature
edition | cre
component | checks
level | 2
compatible | no
The legacy http monitoring plugin caused quite some trouble over the last
years. This included lots of effort to add features or just simply fixing
bugs.
With the new plugin, the functionality is moved to maintainable and
extendable code completely under control of Checkmk. This means also
breaking changes with the old plugin:
* Some metrics are not available anymore as it has been known. We
discovered that these are simply not directly understandable. Instead we
will add metrics as needed in the future. Some metrics will already be
added in this first release
* Some functionality has been a workaround and is now implemented directly
into the new plugin. This makes it hard to migrate rules automatically.
* Users are now able to decide on their own which functionality should be
in an own service. This means, that it is now possible to test the
certificate validity and response times in one service, if needed.
* User are able to configure multiple http checks within one rule. You can
provide standard settings to be used for all endpoints, and overwrite
them per entry for each endpoint. Migrating manually makes absolute
sense here.
Please note that we will not remove the old plugin for now. We understand
that you need some time to migrate your configurations. Nethertheless, we
will deprecate the old plugin and eventually remove it from Checkmk.