ID: 13793
Title: KUBE: Base Cluster aggregation on Node role
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.2.0i1
You may find that some Nodes don't add resources to the overall workload your Cluster can handle.
This werk introduces a new option, which allows you to remove Nodes from aggregations on the Cluster
host based on their role. A node will be omitted, if any of the listed {role}s matches a label with
name 'node-role.kubernetes.io/{role}'. This affects the following services: Memory resources, CPU
resources, Pod resources. Only Services on the Cluster host are affected.
By default, Nodes with role control-plane and infra are omitted.
ID: 13838
Title: TCP fetcher: don't connect if no data is needed
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
When fetching the data from a Checkmk agent (unix/windows),
the fetcher would establish a connection before checking
the cache file. If the cached data was still valid the
connections has been closed.
These "unused" connections could lead to unwanted agent
executions or, in Checkmk 2.1, to irritating errors
in the log of <tt>cmk-agent-ctl</tt> on the monitored host,
such as <i>"Request failed: tls handshake eof"</i> or
<i>"Request failed: Connection reset by peer (os error 104)"</i>.
ID: 13085
Title: REST API: fix missing host/folder attributes
Component: Core & setup
Level: 1
Class: Bug fix
Version: 2.2.0i1
This werk fixes the disappearing attributes (e.g. locked_by, locked_attributes).
When editing hosts or folders through the REST API there could be a case, that
certain fields were not in the list of editable attributes. If a user attempted
to set this field (intrepreted as a "custom attribute") it would be treated as
a string. This would then lead to subsequent errors.
This werk also prevents internal attribute names to be used in "custom attributes".
While the fix is in effect immediately for all newly done REST API calls, if a previous
API call led to inconsistent data being stored in Checkmk, it may be neccessary to repeat
the API call which led to the error.
Ideally this would fix the error, though if this is not the case, contact us.
ID: 13871
Title: Fix possibility to edit foreign visuals without permission
Component: Multisite
Level: 1
Class: Bug fix
Version: 2.2.0i1
A user without the permission "Edit foreign ..." was able to edit
visuals (Views, Dashboards, ...) of other users.
ID: 13839
Title: cisco_stack: Handle switch role "standby"
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
The plugin now correctly displays the switch role "standby".
Previously "unknown" has been displayed.
ID: 13820
Title: Fix listing ruleset 500 error
Component: REST API
Level: 1
Class: Bug fix
Version: 2.2.0i1
When listing rulesets through the REST API, a 500 Internal Server error could occur.
This is fixed with this Werk.
There are no further actions to be taken by the user.
ID: 13840
Title: check_sql: Used metric name is now configurable
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.2.0i1
This werk adds an optional argument '--metrics' to check_sql that will
be used as metric name for the perfomance data.
If no argument is passed, "performance_data" is still the default metric name.
It can be configured using the WATO ruleset
<i>"Check SQL Database"</i>.
ID: 13870
Title: InfluxDB: Fix connection for remote sites
Component: Linux Distributions
Level: 1
Class: Bug fix
Version: 2.2.0i1
If you configured an InfluxDB connection for a remote site, this connection was
not used by the remote site.
The configuration for InfluxDB connections is now stored in
~/etc/check_mk/conf.d/wato instead of ~/etc/check_mk/conf.d/.
If you don't want to copy the file "influxdb_connections.mk" to the new location
on the central site, you would need to configure your connections again.
ID: 13886
Title: Improved performance of various Livestatus queries
Component: Livestatus
Level: 1
Class: New feature
Version: 2.2.0i1
For Livestatus queries containing an AuthUser header, authorization is now
checked immediately before any potentially complicated filters are
evaluated. Those authorization checks are fairly cheap, so depending on the
AuthUser and the filters used, performance can be improved quite a bit.