Checkmk werks level1 June 2022

checkmk-werks-lvl1@lists.checkmk.com

28 participants
139 discussions

Checkmk Werk 13932: non JSON 500 page in REST API

by Christoph Rauch

ID: 13932 Title: non JSON 500 page in REST API Component: REST API Level: 1 Class: Bug fix Version: 2.2.0i1 In some error cases, a non-JSON result page was returned by the REST API. This led to problems with script execution as the page was not valid JSON and thus the parsers threw errors. The errors which led to the non-JSON result will now be returned as a JSON result and a log entry will be made.

2 years, 1 month

Checkmk Werk 14136: apc_symmetra_test: support alternate date format

by Solomon Jacobs

ID: 14136 Title: apc_symmetra_test: support alternate date format Component: Checks & agents Level: 1 Class: Bug fix Version: 2.2.0i1 Previously, the check apc_symmetra_test would result in an unknown state, if the data was based on the PowerChute Business Edition. The underlying reason was that we did not implement parsing for the underlying date format correctly.

2 years, 1 month

Checkmk Werk 14477: Sanitize SiteConfiguration before logging it

by Maximilian Wirtz

ID: 14477 Title: Sanitize SiteConfiguration before logging it Component: Setup Level: 1 Class: Security fix Version: 2.2.0i1

2 years, 1 month

Checkmk Werk 14420: Docker container piggyback hosts: Go CRIT in case of multiple parent hosts

by Joerg Herbel

ID: 14420 Title: Docker container piggyback hosts: Go CRIT in case of multiple parent hosts Component: Checks & agents Level: 1 Class: Bug fix Version: 2.2.0i1 Docker containers are usually monitored as piggyback hosts in Checkmk. If a container with the same name runs on multiple Docker hosts, the piggyback host representing this container will receive data from all parent hosts (of course, this only happens if the Docker agent plugin is configured to use container names as piggyback host names). Since containers with the same name on different parent hosts are completely separate entities, there is no sensible way of merging the data from different parent hosts. In Checkmk 2.0, the container-related services simply used the data from the first parent host. In Checkmk 2.1 however, most container-related services will refuse to process data from multiple parent hosts. Instead, they will go stale and show up as vanished services in the discovery page. Furthermore, the Check_MK Discovery will show errors such as C+: Parsing of section docker_container_... failed C-: This behaviour is intended, since, as stated above, there is no sensible way of merging data from multiple parent hosts. To explicitly make the user aware of this situation, the service "Docker container status" will now additionally go CRIT and report "Found data from multiple Docker nodes - see service details for more information". To resolve this situation, users have multiple options: LI: Reconfigure the Docker agent plugin to use container IDs as piggyback host names. LI: Rename the containers on the parent hosts. LI: Use the ruleset "Hostname translation for piggybacked hosts" to make the host names in Checkmk unique.

2 years, 1 month

Checkmk Werk 14476: Update python-ldap

by Maximilian Wirtz

ID: 14476 Title: Update python-ldap Component: Setup Level: 1 Class: Security fix Version: 2.2.0i1 Update python-ldap to version 3.4.0 which has a fix for CVE-2021-46823.

2 years, 1 month

Checkmk Werk 14457: Fix crash on "Event history of host" view

by Ronny Bruska

ID: 14457 Title: Fix crash on "Event history of host" view Component: Multisite Level: 1 Class: Bug fix Version: 2.2.0i1 The view created an error like "Exception: Painter 'history_what_explained' returned invalid result".

2 years, 1 month

Checkmk Werk 14435: Make password store usable for all special agents

by Anastasiya Liatsetskaya

ID: 14435 Title: Make password store usable for all special agents Component: Reporting & Availability Level: 1 Class: Bug fix Version: 2.2.0i1 The password store is now usable in the configuration of all special agents which require a password. Specifically, the following special agents did not support the password store before: LI: Aerohive HiveManager NG LI: Aerohive HiveManager LI: Apache ActiveMQ queues LI: AppDynamics via REST API LI: BI Aggregations LI: DDN S2A LI: EMC VNX storage systems LI: HPE StoreOnce via REST API 4.x LI: HPE StoreOnce LI: HP MSA via Web Interface LI: IPMI Sensors via Freeipmi or IPMItool LI: Jolokia LI: Microsoft Azure LI: NetApp via WebAPI LI: Nutanix Prism LI: Ruckus Spot LI: UCS Bladecenter LI: VNX quotas and filesystems LI: Zerto

2 years, 1 month

Checkmk Werk 14338: Fix service level filter

by Ronny Bruska

ID: 14338 Title: Fix service level filter Component: Multisite Level: 1 Class: Bug fix Version: 2.2.0i1 The filter "Host service level" and "Service service level" returned wrong results.

2 years, 1 month

Checkmk Werk 14456: Fix operators in filter popup

by Ronny Bruska

ID: 14456 Title: Fix operators in filter popup Component: Multisite Level: 1 Class: Bug fix Version: 2.2.0i1 If a view used filter with operators like "=" or "≠" (e.g. the "Host Tags" filter), the value of the operator was empty when opening the filter popup.

2 years, 1 month

Checkmk Werk 14439: fortigate_ap_connection: Discover more Fortigate devices

by External contributor

ID: 14439 Title: fortigate_ap_connection: Discover more Fortigate devices Component: Checks & agents Level: 1 Class: New feature Version: 2.2.0i1 This loosens the discovery restrictions on the fortigate_ap_connection check, to allow detection of APs on other fortinet devices.

2 years, 1 month

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 June 2022