[//]: # (werk v2)
# Standardize notification spooler log level configuration
key | value
---------- | ---
date | 2024-09-02T09:16:08+00:00
version | 2.4.0b1
class | fix
edition | cee
component | notifications
level | 2
compatible | yes
The notification spoolers log level was configured differently than other
services. Previously users had the choice between:
* Normal logging (only startup, shutdown and errors)
* Verbose logging (also spooled notifications)
* Debugging (log every single action)
This was changed to the standard log levels which we also use in all other services.
The command line flag `-v` of the `mknotifyd`, which could be used to override
the configured log level was replaced with the `--log-level=LEVEL` argument.
While the change to this command line flag is an incompatible change, we don't
rate this as a change that is worth marking the werk to be incompatible. In the
end it's only an option used for manual debugging.
[//]: # (werk v2)
# Introduce distributed tracing of Checkmk
key | value
---------- | ---
date | 2024-08-09T06:32:56+00:00
version | 2.4.0b1
class | feature
edition | cre
component | core
level | 2
compatible | yes
With this change, we aim to improve our capabilities as Checkmk developers to
understand the performance and behavior of Checkmk in a distributed environment
better. This will help us to identify issues and bottlenecks and improve the
performance of Checkmk in the future. Besides logging, metrics and profiling, it
is another tool which gives us great insights.
This change is not meant as a new user feature, e.g. to do distributed tracing
of another software with Checkmk. Nevertheless, we feel it makes sense to
document it here so that you are aware of it when you see the new related
configuration options.
## Goal & requirements
Developers can get easier and better insights into complex and large-scale
production and test environments of Checkmk.
1. The solution shall be usable in a production environment without major
performance impact.
2. No extra complex setup, such as installation of software in addition to
Checkmk, shall be required for the traces to be captured and visualized.
3. The solution shall capture execution steps and collect timing information of
them.
4. For each invocation of these program flows a supporter can visualize traces
including the nested spans across components.
5. The data can be visualized right in the production environment.
6. No data is sent to any external system except it is explicitly configured by
the user.
## High level concept
We use OpenTelemetry as the underlying technology for distributed tracing. The
Checkmk applications are instrumented to send traces. Those traces are sent to a
collector, which is running in every Checkmk site or just in the central site,
in case of a distributed Checkmk environment. This collector is Jaeger, which is
a popular open-source distributed tracing tool. The traces are stored in memory
and can be viewed in the Jaeger UI.
## Configuration
Sending and receiving traces is configured through `omd config`. The two options
`TRACE_RECEIVE` and `TRACE_SEND` are used to enable or disable the receiving and
sending of traces.
The `TRACE_RECEIVE` option will tell the Checkmk applications to send traces via
OTLP to a collector, which can be the local Jaeger instance or any other OTLP
collector of your choices.
The option `TRACE_SEND` enables the sites local Jaeger instance. The site apache
enables the exposure of the Jaeger UI via `http://checkmkhost/site_id/jaeger/`.
## Example
If you have just one site and want to enable tracing, set `TRACE_RECEIVE` to `on`.
Secondly set `TRACE_SEND` to on and set `TRACE_SEND_TARGET` to `local_site`.
Then start your site again. You can now access the Jaeger UI via the URL
`http://checkmkhost/site_id/jaeger/`. After a few seconds you should see the
first traces in the UI.
In a distributed setup, you would enable `TRACE_RECEIVE` on the central site and
`TRACE_SEND` on all other sites and point `TRACE_SEND_TARGET` to the central
site's collector (`TRACE_RECEIVE_ADDRESS:TRACE_RECEIVE_PORT`).
Even if tracing is not much overhead locally, and of course some overhead in the
distributed setup, because the traces need to be sent to the central site, we
recommend enabling tracing only when you need it and disable it again when you
don't need it anymore.
[//]: # (werk v2)
# Don't show automation secret in the audit log (addresses CVE-2024-28830)
key | value
---------- | ---
date | 2024-06-19T12:10:00+00:00
version | 2.4.0b1
class | security
edition | cre
component | wato
level | 2
compatible | no
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong
during the update, you have to copy the files back to ~var/check_mk/wato/log
and remove the automation secrets manually. If the update works as expected,
you can remove the backup files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Mitigations*:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE
`CVE-2024-28830`.
Werk 16846 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# The custom instances of the MS SQL Server plugin are configured correctly
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
version | 2.4.0b1
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong key names:
`conn` instead of a correct `connection` and `auth` instead of
a correct `authentication`.
With this release the problem has been eliminated,
If you are using custom instances you need to bake and deploy new
agent package
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
- # The custom instances of the MS SQL Server plugin are configured correctly
? -
+ # The custom instances of the MS SQL Server plugin are configured correctly
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
- version | 2.3.0p12
? ^ ^ -
+ version | 2.4.0b1
? ^ ^
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong key names:
- `conn` instead of a correct `connection` and `auth` instead of
? -
+ `conn` instead of a correct `connection` and `auth` instead of
a correct `authentication`.
With this release the problem has been eliminated,
- If you are using custom instances you need to bake and deploy new
? -
+ If you are using custom instances you need to bake and deploy new
agent package
Werk 14101 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Add InfluxDB exporter
Class: feature
Compatible: compat
Component: wato
Date: 1650970100
Edition: cee
Knowledge: undoc
Level: 2
Version: 2.1.0b7
With Checkmk 2.1 we introduce the new option to configure InfluxDB connections.
With this option you are able to send metrics directly from Checkmk to the
REST-API of InfluxDB.
More information on how to configure the connection can be found here:
https://docs.checkmk.com/master/en/metrics_exporter.html
Please note:
The integration is only compatible with InfluxDB 2.0 or later.
If you're using InfluxDB <= 1.8 you need to use the option "Send metrics to
Graphite" as described in the Checkmk docs.
------------------------------------<diff>-------------------------------------------
Title: Add InfluxDB exporter
Class: feature
Compatible: compat
Component: wato
Date: 1650970100
Edition: cee
Knowledge: undoc
Level: 2
- Version: 2.1.0b1
? ^
+ Version: 2.1.0b7
? ^
With Checkmk 2.1 we introduce the new option to configure InfluxDB connections.
With this option you are able to send metrics directly from Checkmk to the
REST-API of InfluxDB.
More information on how to configure the connection can be found here:
https://docs.checkmk.com/master/en/metrics_exporter.html
Please note:
The integration is only compatible with InfluxDB 2.0 or later.
If you're using InfluxDB <= 1.8 you need to use the option "Send metrics to
Graphite" as described in the Checkmk docs.
Werk 15714 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Add support for Checkmk Appliance 1.7+
Class: feature
Compatible: compat
Component: distros
Date: 1701285077
Edition: cre
Level: 2
Version: 2.2.0p16
------------------------------------<diff>-------------------------------------------
Title: Add support for Checkmk Appliance 1.7+
Class: feature
Compatible: compat
Component: distros
Date: 1701285077
Edition: cre
Level: 2
- Version: 2.2.0p17
? ^
+ Version: 2.2.0p16
? ^
-
Werk 14875 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: shadow hosts custom attributes doesn't disappear anymore
Class: fix
Compatible: compat
Component: config
Date: 1666099210
Edition: cee
Knowledge: doc
Level: 2
Version: 2.2.0b1
Previously, shadow hosts custom attributes were ignored during
config generation.
With this release the problem has been eliminated.
------------------------------------<diff>-------------------------------------------
Title: shadow hosts custom attributes doesn't disappear anymore
Class: fix
Compatible: compat
Component: config
Date: 1666099210
Edition: cee
Knowledge: doc
Level: 2
- Version: 2.1.0p15
? ^ ^ -
+ Version: 2.2.0b1
? ^ ^
- Previously, shadow hosts custom attributes were ignored during
? -
+ Previously, shadow hosts custom attributes were ignored during
config generation.
With this release the problem has been eliminated.
-
Werk 15714 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Add support for Checkmk Appliance 1.7+
Class: feature
Compatible: compat
Component: distros
Date: 1701285077
Edition: cre
Level: 2
Version: 2.3.0b1
------------------------------------<diff>-------------------------------------------
Title: Add support for Checkmk Appliance 1.7+
Class: feature
Compatible: compat
Component: distros
Date: 1701285077
Edition: cre
Level: 2
- Version: 2.2.0p17
? ^ ^ -
+ Version: 2.3.0b1
? ^ ^
-
Werk 16846 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# The custom instances of the MS SQL Server plugin are configured correctly
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
version | 2.3.0p12
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong key names:
`conn` instead of a correct `connection` and `auth` instead of
a correct `authentication`.
With this release the problem has been eliminated,
If you are using custom instances you need to bake and deploy new
agent package
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# The custom instances of the MS SQL Server plugin are configured correctly
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
- version | 2.3.0p11
? ^
+ version | 2.3.0p12
? ^
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong key names:
`conn` instead of a correct `connection` and `auth` instead of
a correct `authentication`.
With this release the problem has been eliminated,
If you are using custom instances you need to bake and deploy new
agent package
Werk 16846 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# The custom instances of the MS SQL Server plugin are configured correctly
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
version | 2.3.0p11
class | fix
edition | cee
component | checks
level | 2
compatible | yes
Previously, configuring custom instances, WATO used wrong key names:
`conn` instead of a correct `connection` and `auth` instead of
a correct `authentication`.
With this release the problem has been eliminated,
If you are using custom instances you need to bake and deploy new
agent package
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
- # WATO configures correctly custom imstances for MS SQL Server plugin
+ # The custom instances of the MS SQL Server plugin are configured correctly
key | value
---------- | ---
date | 2024-07-19T11:09:57+00:00
version | 2.3.0p11
class | fix
edition | cee
component | checks
level | 2
compatible | yes
- Previously, configuring custom instances, WATO used wrong names:
+ Previously, configuring custom instances, WATO used wrong key names:
? ++++
`conn` instead of a correct `connection` and `auth` instead of
a correct `authentication`.
With this release the problem has been eliminated,
If you are using custom instances you need to bake and deploy new
agent package