[//]: # (werk v2)
# agent_aws: Use proxy for connections to 'STS' client
key | value
---------- | ---
date | 2024-03-07T09:45:40+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Previously, if configured, proxy was used to connect to all clients except for the 'STS' client.
This led to a crash in the agent if 'STS' client was only accessible via proxy.
Now, the configured proxy will be used for the 'STS' client as well.
Title: omd cp: Fix etc/ssl/agents/legacy_ca.pem Points to Source of Copy
Class: fix
Compatible: compat
Component: omd
Date: 1707904094
Edition: cre
Level: 1
Version: 2.2.0p24
Since Checkmk 2.2.0 there is a agent CA located in <code>etc/ssl/agents/</code>. This CA is
different from the site CA. In particular, if updating from 2.1.0 to 2.2.0,
Checkmk will create a symlink <code>etc/ssl/agents/legacy_ca.pem</code>, which points to
<code>etc/ssl/ca.pem</code>. After performing an <code>omd cp</code>. This symlink would still point
to the site, which was the source of the copy. The symlink is now relative. If
the site was created with version 2.2.0 or above no symlink is needed.
Werk 16589 was deleted. The following Werk is no longer relevant.
[//]: # (werk v2)
# Monitor Redfish compatible management boards / BMCs via optional MKP
key | value
---------- | ---
date | 2024-03-06T16:44:06+00:00
version | 2.4.0b1
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)
# omd update: Allow Aborting Before "Completed verifying site configuration."
key | value
---------- | ---
date | 2024-03-07T13:47:39+00:00
version | 2.4.0b1
class | fix
edition | cre
component | omd
level | 2
compatible | yes
Sites may have configuration, MKPs and other local files, which are incompatible with the version
targeted by `omd update`. If such a problem occurs, then aborting the update may be necessary. In
earlier versions, users were advised to perform a downgrade, which was not user-friendly and had
several pitfalls. Downgrading is not supported as it has many potential downsides. With this Werk,
`omd update` is better able to deal with these situations. `omd update` will show the message
```
Completed verifying site configuration. Your site now has version {target version}.
```
If the update is aborted before this message is shown, then the site is restored to it's previous
state. This includes selecting the `abort` option, unexpected internal errors, or aborting the
update using CTRL-C.
[//]: # (werk v2)
# cmk-update-config: Don't Prompt User if Using Conflict Mode "install" or "keepold"
key | value
---------- | ---
date | 2024-03-07T13:04:36+00:00
version | 2.4.0b1
class | fix
edition | cre
component | omd
level | 2
compatible | yes
While upgrading with `cmk-update-config`, the user can be prompted with questions about the next
update steps. This questioning can be disabled by using one of the conflict options `install`,
`keepold` or `abort`. Due to a regression in the 2.3.0b1 the options `install` and `keepold` do not
supress these questions. In particular, if there is a problem while `Verifying the Checkmk
configuration...`, then the update of Checkmk on Checkmk appliances will exit with a traceback.
Upgrading to the 2.3.0b1 is thus only possible here, if all problems are fixed beforehand.
[//]: # (werk v2)
# omd update: Don't Delete "config.pb" During Pre-Update
key | value
---------- | ---
date | 2024-03-07T13:27:55+00:00
version | 2.4.0b1
class | fix
edition | cee
component | omd
level | 1
compatible | yes
The `omd update` command has the capability to undo the changes it has done up until `Verifying
Checkmk configuration...`. However, if any change after `Verifying Checkmk configuration...` is
persisted. Due to a regression caused by Werk #15725, the file `config.pb` is deleted during this
verification. If the update aborts during the verification, then users will see the following error:
```
Starting cmc...Failed (Config /omd/sites/prod_dmz/var/check_mk/core/config.pb missing, run "cmk -U" and try again)
```
With this Werk, `config.pb` will be deleting only while `Updating Checkmk configuration...`.
[//]: # (werk v2)
# Monitor Redfish compatible management boards / BMCs via optional MKP
key | value
---------- | ---
date | 2024-03-06T16:44:06+00:00
version | 2.4.0b1
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)
# mongodb_replica_set: Fix replication lag and last replication time
key | value
---------- | ---
compatible | yes
version | 2.4.0b1
date | 2024-03-07T09:48:38+00:00
level | 1
class | fix
component | checks
edition | cre
Checkmk previously assumed that timestamps collected from MongoDB oplog
are provided in ms. This wasn't the case, which led to wrong values for
replication lag and last replication time being shown in
the 'MongoDB Replication Lag' service.
Title: Crash when creating combined graphs with empty time filter
Class: fix
Compatible: compat
Component: multisite
Date: 1709884230
Edition: cre
Level: 1
Version: 2.2.0p24
When creating a combined graph with an empty time filter (e.g. Last service check),
the creation of the combined graph would crash.
This behavior is not consistent with the view filtering behavior,
where the filter is not applied if it is empty.
Now the filter is not applied to combined graphs either.