Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15886 discussions

[2.3.0] Checkmk Werk 16485 created: host_config: Create hosts in folder with umlauts

by Checkmk werks level 1

[//]: # (werk v2) # host_config: Create hosts in folder with umlauts key | value ---------- | --- date | 2024-03-11T12:51:50+00:00 version | 2.3.0b2 class | fix edition | cre component | rest-api level | 1 compatible | yes When creating hosts in a folder with umlauts in the name via one of the `host_config` endpoints the endpoint would return an error 400 even though the query was correct. Now the hosts are created correctly.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16501 adapted: introduce command to start openapi-spec generation background job

by Checkmk werks level 1

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 -

3 months, 3 weeks

[2.3.0] Checkmk Werk 14226 created: Fixed stuck activate changes on bulk discovery and when using the DCD

by Checkmk werks level 1

[//]: # (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.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16581 created: Automatic creation of labels based on OS information from the agent

by Checkmk werks level 1

[//]: # (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

3 months, 3 weeks

[2.3.0] Checkmk Werk 16456 created: Fix licensing recording and verification due to missing instance IDs on remote sites

by Checkmk werks level 1

[//]: # (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',

3 months, 3 weeks

[2.3.0] Checkmk Werk 16242 created: Kill forked processes by mk_oracle under AIX

by Checkmk werks level 1

[//]: # (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.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16497 created: agent_aws: Use proxy for connections to 'STS' client

by Checkmk werks level 1

[//]: # (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.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16501 adapted: omd: trigger openapi-spec generation job during start, restart and reload

by Checkmk werks level 1

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 - -

3 months, 3 weeks

[2.3.0] Checkmk Werk 16560 created: Remove "Compute REST API specification" update config action

by Checkmk werks level 1

[//]: # (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.

3 months, 3 weeks

[2.3.0] Checkmk Werk 16174 created: mongodb_replica_set: Fix replication lag and last replication time

by Checkmk werks level 1

[//]: # (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.

3 months, 3 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1