[//]: # (werk v2)
# Let cmcdump handle semicolons in plugin output
key | value
---------- | ---
date | 2024-02-21T13:39:02+00:00
version | 2.3.0b1
class | fix
edition | cee
component | multisite
level | 1
compatible | yes
cmcdump would not handle semicolons correctly, leading to
garbled or incomplete output and spurious errors.
This has been fixed by escaping semicolons in cmcdump
and unescaping them in livestatus.
Title: ldap & saml: resolve error when connection config is edited or created
Class: fix
Compatible: compat
Component: wato
Date: 1690532069
Edition: cme
Knowledge: doc
Level: 1
Version: 2.3.0b1
Prior to this werk, Checkmk raised an error in the following cases:
LI: when the user attempted to create a LDAP connection with a config with the customer option set to "Global"
LI: when the user attempted to change a LDAP connection config with the customer option set to "Global"
LI: when the user attempted to create a SAML connection config
LI: when the user attempted to delete an existing SAML connection config
This werk resolves these issues and Checkmk will not throw an error anymore.
[//]: # (werk v2)
# mtr: Fix section parsing error
key | value
---------- | ---
date | 2024-02-25T22:30:51+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
When the mtr section contained a line that started with `**ERROR**`, the parsing of the section failed.
This has now been fixed.
The lines starting with `**ERROR**` will be ignored.
[//]: # (werk v2)
# Introduced topology visualization
key | value
---------- | ---
date | 2024-02-25T15:22:55+00:00
version | 2.3.0b1
class | feature
edition | cee
component | multisite
level | 2
compatible | yes
The topology visualization is a new feature that allows the visualization of complex interconnected networks.
A simple example for this visualization is the parent/child topology. The new mechanism that comes with this werk allows the linking of external data with the data of the monitoring core.
When it comes to the display, you simply define some starting points via the filter form.
Based on these, the topology visualization then builds a mesh of incoming and outgoing connections.
The type of external data might be
* Netstat, showing connections between the interfaces/ips/ports
* LLDP/CDP, showing the network neighbors
There is a common data format specification for all external data.
So you just can create your own data file which provides information about the relationships between hosts, services or generic objects which are not linked to the core.
If you drop this file into a specific folder, the visualization will handle the rest. There is no need to write python code.
Right now you can configure
* Objects - either linked to an entity in the core or some standalone object
* Icons/emblems which should be added to the object
* Connections between objects
* Line style/color of specific connections
Since this is a quite visualization heavy topic and hard to explain only via text, feel free to check out the
[thread](https://forum.checkmk.com/t/network-visualization-now-in-version-2-… in our checkmk forum
We will also publish a blog article in the coming weeks
```
Important:
The visualization only works if external data is provided in a special folder.
At the moment these are not created by Checkmk, but come from external MKP developments.
```
[//]: # (werk v2)
# EC: fix a wrong message on a matched rule
key | value
---------- | ---
date | 2024-02-23T08:14:30+00:00
version | 2.3.0b1
class | fix
edition | cee
component | ec
level | 1
compatible | yes
Previously, the tooltip on a matched rule would say it is a cancelling rule.
This message was misleading and was changed.
[//]: # (werk v2)
# bi_rule: schema update to match the api docs
key | value
---------- | ---
date | 2024-02-19T14:34:33+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
The Open API schema previously did not reflect the response or the request
schema format that was required to create or show BI rules. This werk
addresses this issue.
Previously, when creating or getting a BI rule, via the REST-API, the
schema for host_label_groups or service_label_groups looked similar
to the following:
```
"host_label_groups": [
[
"and",
[
["and", "mystery/switch:yes"],
["or", "mystery/switch:no"],
],
],
]
```
This did not match the schema documented in the Open API docs.
To fix this, we have now changed the format to the following
```
"host_label_groups": [
{
"operator": "and",
"label_group": [
{"operator": "and", "label": "mystery/switch:yes"},
{"operator": "or", "label": "mystery/switch:no"},
],
},
]
```
This also aligns with other endpoints that use our new
host_label_groups or service_label_groups, for example the
rules endpoints.
As this is a breaking change, user scripts should be adjusted
accordingly.
[//]: # (werk v2)
# netapp_ontap_info: enhanced presentation of NetApp system information
key | value
---------- | ---
date | 2024-02-15T10:04:03+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The version and hardware information for a NetApp system was only displayed for the first retrieved node.
With this werk we now display information for each retrieved node.
[//]: # (werk v2)
# sla: range field for predefined_time_range parameter is mandatory
key | value
---------- | ---
date | 2024-02-23T08:00:57+00:00
version | 2.3.0b1
class | fix
edition | cee
component | rest-api
level | 1
compatible | yes
Before this werk, when the sla was computed for a predefined time
range without specifying the range field, an error status 500
Internal Server Error was returned. This werk solves the problem
by checking for the existence of the range field, and if it does
not exist, the endpoint returns an error status 400 - Bad Request.
[//]: # (werk v2)
# snmp: Store OID cache per context group
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-02-07T09:54:40+00:00
level | 1
class | fix
component | checks
edition | cre
SNMP caching didn't take contexts in consideration when storing
OID data. This led to the same result being reported for the OID
in different sections even if sections use different contexts.
Now, SNMP caching stores fetched OID data for every group of contexts
it was called with.
[//]: # (werk v2)
# apidocs: improve the request/response examples
key | value
---------- | ---
date | 2024-02-21T11:07:55+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
Previously the requests and urllib examples were hard coded to show
the same response samples and the same response status codes in
the request samples.
This werk addresses this issue by showing the correct possible
status codes for each endpoint.