Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15865 discussions

[2.4.0] Checkmk Werk 17159 created: Save scrollbar position on page load

by Checkmk werks level 1

[//]: # (werk v2) # Save scrollbar position on page load key | value ---------- | --- compatible | yes version | 2.4.0b1 date | 2024-08-12T11:33:16+00:00 level | 1 class | fix component | multisite edition | cre The sidebar of the main frame always scrolled up to the top after the page load. This was an issue if you e.g. edited large views and already scrolled down before the whole page was loaded.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17062 created: Fix problems on cloning built-in problems dashboard

by Checkmk werks level 1

[//]: # (werk v2) # Fix problems on cloning built-in problems dashboard key | value ---------- | --- date | 2024-07-04T14:02:37+00:00 version | 2.4.0b1 class | fix edition | cme component | multisite level | 1 compatible | yes If you cloned the built-in dashboard "problems", the "Topic" section showed "This element does not exist anymore". Furthermore, if you edited the "Host statistics" or "Service statistics" dashlet on the cloned dashboard, an error like "KeyError (size)" occurred.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17177 created: Slack/Mattermost: Updated notification message

by Checkmk werks level 1

[//]: # (werk v2) # Slack/Mattermost: Updated notification message key | value ---------- | --- date | 2024-08-13T08:36:24+00:00 version | 2.4.0b1 class | feature edition | cre component | notifications level | 1 compatible | yes The Slack notification plugin now uses Block Kit, resulting in differently rendered notifications. Some of these formatting changes also apply to Mattermost notifications.

3 weeks, 1 day

[2.4.0] Checkmk Werk 16710 created: Better handling of notification result in case of timeout

by Checkmk werks level 1

[//]: # (werk v2) # Better handling of notification result in case of timeout key | value ---------- | --- compatible | yes version | 2.4.0b1 date | 2024-06-05T09:42:42+00:00 level | 1 class | fix component | notifications edition | cre Werk #16707 added useful log information to failed notifications in case of a timeout. In some cases, this log contained also script output. We now show the timeout message within "Summary" of the notification result and, if available, the last output of the notification plugin followed by the timeout message within the "Comment" column. Both are separated by "--".

3 weeks, 1 day

[2.4.0] Checkmk Werk 17161 created: Fix link of "Open this Aggregation"

by Checkmk werks level 1

[//]: # (werk v2) # Fix link of "Open this Aggregation" key | value ---------- | --- compatible | yes version | 2.4.0b1 date | 2024-08-12T13:22:22+00:00 level | 1 class | fix component | multisite edition | cre If you used the option "Open this Aggregation" in the burger menu of a check based on "Check State of BI Aggregation", the link lead to a none existing page.

3 weeks, 1 day

[2.4.0] Checkmk Werk 15339 created: check_sql: activate thick mode for oracle connections

by Checkmk werks level 1

[//]: # (werk v2) # check_sql: activate thick mode for oracle connections key | value ---------- | --- date | 2024-08-08T09:40:54+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes With [Werk #16023](https://checkmk.com/werk/16023) we switched the library used to connect to oracle databases from `cx_Oracle` to `oracledb`. For `cx_Oracle` it was mandatory to install "Oracle Instant Client". The newer `oracledb` library has two modes: A stand alone thin mode and a thick mode that needs the "Oracle Instant Client". In order to fully replace `cx_Oracle`, `oracledb` needs to be in thick mode. This is something we have not considered for Werk #16023. With this Werk we now try to switch into the thick mode, and if this does not work, we use thin mode. If you execute `check_sql` with `-v` switch you will see a message if `oracledb` could not switch into thick mode. `oracledb` searches for the "Oracle Instant Client" in several standard location. `check_sql` will find the installation if the files (among other things `*.so` and `*.jar`) from the "Oracle Instant Client" files are directly in `~local/lib/` in your site.

3 weeks, 1 day

[2.4.0] Checkmk Werk 16615 adapted: Remove websphere_mq plugin

by Checkmk werks level 1

Werk 16615 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Remove websphere_mq plugin key | value ---------- | --- date | 2024-03-11T11:09:48+00:00 version | 2.4.0b1 class | security edition | cre component | checks level | 1 compatible | no With this Werk the `websphere_mq` plugin is removed for security reasons. In this plugin the output of `ps` is used to determine an argument for `runmqsc`. This meant that anybody who can launch processes with an arbitrary command line could manipulate one argument to `runmqsc`. The plugin was already superseded by the agent plugin `ibm_mq` and deprecated with Werk [10752](https://checkmk.com/werk/10752) and version 2.0.0. Since this plugin is already deprecated and it was not configurable via the *agent bakery* we assumed that this plugin is not frequently used. Therefore we decided to not fix the issue but to push the removal. We found this vulnerability internally. __Affected versions__: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 __Mitigations__: Migrate to the `ibm_mq` plugin. __Vulnerability Management__: We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N`. We assigned CVE-2024-3367 to this vulnerability. __Changes__: The plugin was removed. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Remove websphere_mq plugin key | value ---------- | --- date | 2024-03-11T11:09:48+00:00 version | 2.4.0b1 class | security edition | cre component | checks level | 1 - compatible | yes ? ^^^ + compatible | no ? ^^ With this Werk the `websphere_mq` plugin is removed for security reasons. In this plugin the output of `ps` is used to determine an argument for `runmqsc`. This meant that anybody who can launch processes with an arbitrary command line could manipulate one argument to `runmqsc`. The plugin was already superseded by the agent plugin `ibm_mq` and deprecated with Werk [10752](https://checkmk.com/werk/10752) and version 2.0.0. Since this plugin is already deprecated and it was not configurable via the *agent bakery* we assumed that this plugin is not frequently used. Therefore we decided to not fix the issue but to push the removal. We found this vulnerability internally. __Affected versions__: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 __Mitigations__: Migrate to the `ibm_mq` plugin. __Vulnerability Management__: We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N`. We assigned CVE-2024-3367 to this vulnerability. __Changes__: The plugin was removed.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17160 created: Opsgenie: Better error handling

by Checkmk werks level 1

[//]: # (werk v2) # Opsgenie: Better error handling key | value ---------- | --- date | 2024-08-12T12:32:45+00:00 version | 2.4.0b1 class | fix edition | cre component | notifications level | 1 compatible | yes In earlier versions some errors (like authentication failures) lead to a traceback. Errors should be shown in a better way now.

3 weeks, 1 day

[2.4.0] Checkmk Werk 17175 created: slack: Enforce HTTPS URLs

by Checkmk werks level 1

[//]: # (werk v2) # slack: Enforce HTTPS URLs key | value ---------- | --- date | 2024-07-30T13:57:16+00:00 version | 2.4.0b1 class | fix edition | cre component | notifications level | 1 compatible | no The Webhook URL for Slack notifications must now use HTTPS. Please update your notification rules for slack.

3 weeks, 1 day

[2.4.0] Checkmk Werk 16565 created: Introduce distributed tracing of Checkmk

by Checkmk werks level 1

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

3 weeks, 1 day

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1