Werk 16501 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# introduce command to start openapi-spec generation background job
key | value
---------- | ---
date | 2024-02-29T13:06:16+00:00
version | 2.3.0b2
class | feature
edition | cre
component | rest-api
level | 1
compatible | yes
Werk 15724 introduces a mechanism for regenerating the API specification,
which, in certain instances, is executed as a background job due to the
potential time required for completion. This update introduces a command
to trigger the background job for the regeneration of the API specification.
Users should be aware that triggering the job does not result
in immediate availability of the updated documentation; there may be a
delay before the documentation is updated. This saves the user from having
to trigger and wait for the specification regeneration manually.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
- # omd: trigger openapi-spec generation job during start, restart and reload
+ # introduce command to start openapi-spec generation background job
key | value
---------- | ---
date | 2024-02-29T13:06:16+00:00
version | 2.3.0b2
class | feature
edition | cre
- component | omd
+ component | rest-api
level | 1
compatible | yes
Werk 15724 introduces a mechanism for regenerating the API specification,
which, in certain instances, is executed as a background job due to the
- potential time required for completion. This update modifies the omd start,
? ^ ^^^ ^^^^ -------
+ potential time required for completion. This update introduces a command
? ^^^^ ^^ ^^^ +++
- restart, and reload commands to initiate this specific background job upon
+ to trigger the background job for the regeneration of the API specification.
- execution. Users should be aware that triggering the job does not result
? -----------
+ Users should be aware that triggering the job does not result
in immediate availability of the updated documentation; there may be a
delay before the documentation is updated. This saves the user from having
- to trigger and wait for the specification regeneration manually in case
? ^^^^^^^^
+ to trigger and wait for the specification regeneration manually.
? ^
- relevant changes have been made outside the user interface and the apache
- process needs to be restarted.
- Based on werk 15724 the specification is now updated in these situations:
-
- * post-create hook: Create the initial spec after a site has been created
- * post rename action: Update the spec after a site has been copied, restored or renamed
- * omd apache: Update the spec when the apache process is started, restarted or reloaded
-
[//]: # (werk v2)
# Fixed stuck activate changes on bulk discovery and when using the DCD
key | value
---------- | ---
date | 2024-03-08T13:17:45+00:00
version | 2.3.0b2
class | fix
edition | cme
component | wato
level | 1
compatible | yes
Activate changes stopped working when initiating a bulk discovery or using the DCD with automatic service discovery.
[//]: # (werk v2)
# Automatic creation of labels based on OS information from the agent
key | value
---------- | ---
date | 2024-03-08T12:39:02+00:00
version | 2.3.0b2
class | feature
edition | cre
component | checks
level | 1
compatible | yes
Checkmk automatically creates host labels based on OS data sent by the agents on check\_mk section.
* `cmk/os_type`: Value taken from `OSType` line. No label created if line is not present.
* `cmk/os_platform`: Value is taken from `OSPlatform` line. If line is not present, AgentOS value is used instead
* `cmk/os_name`: Value taken from `OSName` line. No label created if line is not present.
* `cmk/os_version`: Value taken from `OSVersion` line. No label created if line is not present.
The following list shows an example of the information that agents send for the labels creation. The source is noted in square brackets.
* AIX
* AgentOS: aix
* OSType: unix
* OSName: AIX
* OSVersion: [oslevel -s]: 7100-05-04-1914
* FreeBSD
* AgentOS: freebsd
* OSType: unix
* OSName: [/etc/os-release (NAME)]: FreeBSD
* OSVersion: [/etc/os-release (VERSION\_ID)]: 13.2
* HP-UX
* AgentOS: hpux
* OSType: unix
* OSName: HP-UX
* OSVersion: [uname -r | cut -d' ' -f1]: B.11.31
* Linux
* AgentOS: linux
* OSType: linux
* OSPlatform: [/etc/os-release (ID)]: ubuntu
* OSName: [/etc/os-release (NAME)]: Ubuntu
* OSVersion: [/etc/os-release (VERSION\_ID)]: 22.04
* MacOS
* AgentOS: macosx
* OSType: macos
* OSName: [sw\_vers -productName]: macOS
* OSVersion: [sw\_vers -productVersion]: 13.0
* NetBSD
* AgentOS: netbsd
* OSType: unix
* OSName: [uname -s]: NetBSD
* OSVersion: [uname -r]: 9.3
* OpenBSD
* AgentOS: openbsd
* OSType: unix
* OSName: [uname -s]: OpenBSD
* OSVersion: [uname -r]: 7.4
* OpenVMS
* AgentOS: openvms
* OSName: OpenVMS
* OpenWRT
* AgentOS: openwrt
* OSType: linux
* OSName: [/etc/os-release (NAME)]: OpenWRT
* OSVersion: [/etc/os-release (VERSION\_ID)]: snapshot
* Solaris
* AgentOS: solaris
* OSType: unix
* OSName: [/etc/os-release (NAME)]: Oracle Solaris
* OSVersion: [/etc/os-release (VERSION\_ID)]: 11.4
* Windows
* AgentOS: windows
* OSType: windows
* OSName: [wmi]: Microsoft Windows 10 Pro
* OSVersion: [wmi]: 10.0.19045
* z/OS
* AgentOS: z/OS
* OSType: z/os
* OSName: z/OS
[//]: # (werk v2)
# Fix licensing recording and verification due to missing instance IDs on remote sites
key | value
---------- | ---
date | 2024-03-11T09:10:30+00:00
version | 2.3.0b2
class | fix
edition | cme
component | omd
level | 1
compatible | yes
This situation can be fixed by stopping and starting remote sites via 'omd stop'
and 'omd start',
[//]: # (werk v2)
# Kill forked processes by mk_oracle under AIX
key | value
---------- | ---
date | 2024-03-06T12:43:13+00:00
version | 2.3.0b2
class | fix
edition | cre
component | checks
level | 1
compatible | yes
The agent plugin `mk_oracle` creates forked processes, e.g. from `sqlplus`.
In order to reliable clean up stale processes, we kill now the whole process chain under AIX
which corresponds to the stored `PID`.
We introduce this only for `AIX` now as we have customers which are affected under that OS.
[//]: # (werk v2)
# agent_aws: Use proxy for connections to 'STS' client
key | value
---------- | ---
date | 2024-03-07T09:45:40+00:00
version | 2.3.0b2
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.
Werk 16501 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# omd: trigger openapi-spec generation job during start, restart and reload
key | value
---------- | ---
date | 2024-02-29T13:06:16+00:00
version | 2.3.0b2
class | feature
edition | cre
component | omd
level | 1
compatible | yes
Werk 15724 introduces a mechanism for regenerating the API specification,
which, in certain instances, is executed as a background job due to the
potential time required for completion. This update modifies the omd start,
restart, and reload commands to initiate this specific background job upon
execution. Users should be aware that triggering the job does not result
in immediate availability of the updated documentation; there may be a
delay before the documentation is updated. This saves the user from having
to trigger and wait for the specification regeneration manually in case
relevant changes have been made outside the user interface and the apache
process needs to be restarted.
Based on werk 15724 the specification is now updated in these situations:
* post-create hook: Create the initial spec after a site has been created
* post rename action: Update the spec after a site has been copied, restored or renamed
* omd apache: Update the spec when the apache process is started, restarted or reloaded
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# omd: trigger openapi-spec generation job during start, restart and reload
key | value
---------- | ---
date | 2024-02-29T13:06:16+00:00
version | 2.3.0b2
class | feature
edition | cre
component | omd
level | 1
compatible | yes
Werk 15724 introduces a mechanism for regenerating the API specification,
which, in certain instances, is executed as a background job due to the
potential time required for completion. This update modifies the omd start,
restart, and reload commands to initiate this specific background job upon
execution. Users should be aware that triggering the job does not result
in immediate availability of the updated documentation; there may be a
delay before the documentation is updated. This saves the user from having
to trigger and wait for the specification regeneration manually in case
relevant changes have been made outside the user interface and the apache
process needs to be restarted.
Based on werk 15724 the specification is now updated in these situations:
* post-create hook: Create the initial spec after a site has been created
* post rename action: Update the spec after a site has been copied, restored or renamed
- * update-config action: Update the spec after the site has been updated
* omd apache: Update the spec when the apache process is started, restarted or reloaded
-
-
[//]: # (werk v2)
# Remove "Compute REST API specification" update config action
key | value
---------- | ---
date | 2024-03-11T07:12:14+00:00
version | 2.3.0b2
class | fix
edition | cre
component | core
level | 1
compatible | yes
As of werk #16501 the computation is executed during start, restart and reload
of the site apache in the background. With this mechanism the execution during
`cmk-update-config` is not needed anymore.
[//]: # (werk v2)
# mongodb_replica_set: Fix replication lag and last replication time
key | value
---------- | ---
compatible | yes
version | 2.3.0b2
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.
[//]: # (werk v2)
# Crash when creating combined graphs with empty time filter
key | value
---------- | ---
date | 2024-03-08T07:50:30+00:00
version | 2.3.0b2
class | fix
edition | cre
component | multisite
level | 1
compatible | yes
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.