Checkmk werks level1 October 2021

checkmk-werks-lvl1@lists.checkmk.com

22 participants
94 discussions

Checkmk Werk 13312: omd mv/cp: Improve handling of site renamings

by Lars Michelsen

ID: 13312 Title: omd mv/cp: Improve handling of site renamings Component: Core & setup Level: 2 Class: New feature Version: 2.1.0i1 Users which execute 'omd mv' or 'omd cp' expect Checkmk to not only rename the site, but also migrate the Checkmk configuration in a way that they can continue seamlessly with their existing Checkmk configuration. This feature did not exist before and was a common misunderstanding. OMD itself is only caring about migrating the files and file parts that are initially installed with the skel hierarchy of OMD and under control of it. *Clearer:* If you create a clean site and then execute 'grep -r $OMD_SITE etc' in your site, you can see a lot of files which contain the ID of the site. These things are already migrated by OMD. But OMD is not aware of the configuration files of the applications shipped with OMD. For example the Checkmk configuration files are not understood by OMD. And that's totally fine from an architectural point of view, because OMD is a separate component that manages installation of different applications, but must not mess with their individual files. However, from a user's perspective it's clear that you also want the application files to be migrated during site renaming. And this is what we'll now start to work on. We are now caring about the migration of more configuration parts. Technical details: <ul> <li>OMD detects changes of the site ID (mv, cp or restore)</li> <li>Then it executes the command 'post-rename-site -v -o [OLD_SITE_ID]'</li> <li>The command 'post-rename-site' then takes care of the Checkmk configuration updates</li> <li>It can also detect some situations it can not solve on it's own and warns the user about potential manual steps to do afterwards.</li> The migration steps are realized in so called rename action plugins. Examples can be found in the Checkmk git below 'cmk/post_rename_site/plugins/actions/sites.py` or in the site at 'lib/python3/cmk/post_rename_site/plugins/actions/sites.py'.

2 years, 12 months

Checkmk Werk 12997: Report scheduler does not remove elements anymore

by Óscar Nájera

ID: 12997 Title: Report scheduler does not remove elements anymore Component: Reporting & Availability Level: 1 Class: Bug fix Version: 2.1.0i1 Reports generated by the scheduler would consume the configured report elements leading to empty reports if the scheduler is triggered in sequence. This is now fixed.

2 years, 12 months

Checkmk Werk 13090: Fixed 'transitions' and 'next_transition' columns in timeperiods table.

by Sven Panne

ID: 13090 Title: Fixed 'transitions' and 'next_transition' columns in timeperiods table. Component: Livestatus Level: 1 Class: Bug fix Version: 2.1.0i1 Both columns didn't take the local time zone offset into account. Furthermore, 'next_transition' was off by a factor of 1e9, leading to funny 32bit overflow effects most of the time.

2 years, 12 months

Checkmk Werk 13367: Support Diagnostics: Fix "Argument list too long" exception

by Ronny Bruska

ID: 13367 Title: Support Diagnostics: Fix "Argument list too long" exception Component: Multisite Level: 1 Class: Bug fix Version: 2.1.0i1 When using support diagnostic options like, e.g. "Checkmk Configuration files", where files are packed to an archive, the error "OSError: [Errno 7] Argument list too long: 'check_mk'" could occur. The automation commands will now be splitted for such options.

2 years, 12 months

Checkmk Werk 13230: systemd_units: Handling of 'deactivating' services

by Moritz Kiemer

ID: 13230 Title: systemd_units: Handling of 'deactivating' services Component: Checks & agents Level: 1 Class: Bug fix Version: 2.1.0i1 Previously systemd services in the 'deactivating' state immediately led to a critical Checkmk service. Now it is ok for any systemd service to be in this state once, or for a configured interval. Note that this behaviour in particular affected users who monitored their hosts from two Checkmk sites, as the <tt>check_mk_agent</tt> would be 'deactivating' from time to time (which is expected).

2 years, 12 months

Checkmk Werk 13047: RESTAPI: fix agent information and agent download

by Benedikt Seidl

ID: 13047 Title: RESTAPI: fix agent information and agent download Component: Core & setup Level: 1 Class: Bug fix Version: 2.1.0i1 Before this Werk, both endpoints for downloading the agent binary and for getting the configuration of a agent shared the same URL, so effectively only the "show agent information" endpoint to show the configuration was active. This endpoint did not work properly and returned an error: <tt>AttributeError: 'str' object has no attribute 'items'</tt> With this Werk a second endpoint was introduced to download the agent binary and the endpoint to show the agent configuration was fixed.

2 years, 12 months

Checkmk Werk 13466: Increase cache validity for NTP service

by Moritz Kiemer

ID: 13466 Title: Increase cache validity for NTP service Component: Checks & agents Level: 1 Class: Bug fix Version: 2.1.0i1 The data for the NTP service "NTP Time" and "NTP Peer" had a cache validity intervall of 30 seconds, in order to create a new data set every time the agent was triggered. Unfortunately this meant that the data was expired, before it ever reached the monitoring server. This hack increases the validitiy of the data set to 120 seconds, while still recreating it every time the agent is called.

2 years, 12 months

Checkmk Werk 13447: check_mk_agent.linux: Write ntp section if ntpsec.service active

by External contributor

ID: 13447 Title: check_mk_agent.linux: Write ntp section if ntpsec.service active Component: Checks & agents Level: 1 Class: Bug fix Version: 2.1.0i1 Linux agent now writes the ntp section in the agent output if there is an active ntpsec.service in systemctl.

2 years, 12 months

Checkmk Werk 13330: Don't show clear text passwords in the audit log

by Tom Baerwinkel

ID: 13330 Title: Don't show clear text passwords in the audit log Component: Multisite Level: 2 Class: Security fix Version: 2.1.0i1 Beginning from version 2.0 passwords were written to the audit log in clear text when a rule with a password field was created/cloned or when a password in a rule was modified. This werk fixes that so that no passwords are written to the audit log anymore. By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. If a rule uses the password store, no passwords were written to the audit log. Existing passwords in the audit log should be replaced automatically by "hash:XXXXXXXXXX" during the update. But please double check that no passwords remain in the log (see next paragraph for details). If you e.g. use rulesets from extension packages that contain password fields, passwords from these rules may remain in the log. Additionally, rules from the rulesets "Check SFTP Service", "Microsoft SQL Server (Windows)" and "Redis databases" cannot be replaced reliably. So these passwords will remail in the audit log even after the update. You can remove/replace remaining passwords directly in the log files. The log files are placed in the directory var/check_mk/wato/log. The names of the files are wato_audit.log for the most recent file and wato_audit.log.YYYY-MM-DD for historic files. Note that if you use the action "Clear audit log" in the GUI the log is not deleted, but moved from wato_audit.log to wato_audit.log.YYYY-MM-DD. So in this case the passwords will not be visible in the GUI anymore, but remain in the historic log files of the site. The historic files are only accessible by the site user and group from the command line. In distributed setups which do not replicate the configuration passwords are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no passwords should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, passwords can be present in the logs. Since passwords may be in this scenario as well, the steps described before also apply.

2 years, 12 months

Checkmk Werk 13207: Windows interface plugins must be updated

by Joerg Herbel

ID: 13207 Title: Windows interface plugins must be updated Component: Checks & agents Level: 2 Class: New feature Version: 2.1.0i1 This werk only affects users using the Windows agent plugins 'windows_if.ps1' or 'wmic_if.bat' (bakery ruleset 'Network interfaces on Windows') or the plugin 'mk_dhcp_enabled.bat'. The above mentioned plugins have been restructured to improve code maintainability. As a result, users need to update the agents on Windows systems where one of these plugins is installed. The Windows interface check will go critical if these agents are not updated. Furthermore, without an update, the data produced by these plugins will not be processed by Checkmk. In case interfaces are monitored using their aliases as items, the interface checks on affected hosts might also report "Item not found in monitoring data" and go UNKNOWN. Updating the agent will fix this issue as well.

2 years, 12 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 October 2021