Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 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, 11 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, 11 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, 11 months

Checkmk Werk 13089: Fixed logging with microsecond timestamps

by Sven Panne

ID: 13089 Title: Fixed logging with microsecond timestamps Component: cmc Level: 3 Class: Bug fix Version: 2.1.0i1 Checkmk 1.6.0 introduced a small regression where log lines in cmc.log were missing a space when logging with microseconds was enabled. Lines like 2021-10-13 10:24:51696.318 [5] [core 12345] Foo bar happened. should really read: 2021-10-13 10:24:51 696.318 [5] [core 12345] Foo bar happened. This has been fixed.

2 years, 11 months

Checkmk Werk 13088: Handle old syslog messages without a tag.

by Sven Panne

ID: 13088 Title: Handle old syslog messages without a tag. Component: Event Console Level: 3 Class: Bug fix Version: 2.1.0i1 The event console could not parse a RFC-3164-style message where the CONTENT did not start with a TAG. The TAG is specified as optional, so we handle that case now, too.

2 years, 11 months

Checkmk Werk 13087: Remove ad hoc restrictions in the generic check helper protocol.

by Sven Panne

ID: 13087 Title: Remove ad hoc restrictions in the generic check helper protocol. Component: Core & setup Level: 3 Class: Bug fix Version: 2.1.0i1 This enables, among other things, the use of very long command lines for active checks.

2 years, 11 months

Checkmk Werk 12955: host collection response in REST API

by Christoph Rauch

ID: 12955 Title: host collection response in REST API Component: Core & setup Level: 2 Class: Bug fix Version: 2.1.0i1 Up until Checkmk 2.0.0p8 the responses of all host_config collections, due to a bug, did not contain the attributes, members and links of the host_config objects. This werk fixes these responses, but changes the OpenAPI specification, so you may need to recompile your API client.

2 years, 11 months

Checkmk Werk 12954: generate default site configuration before Apache starts

by Christoph Rauch

ID: 12954 Title: generate default site configuration before Apache starts Component: Core & setup Level: 2 Class: Bug fix Version: 2.1.0i1 Before this Werk, the default configuration was created by Checkmk on the first request to the GUI. This has been changed to happend *before* the Apache process starts up the first time. The reason for this is that some parts of Checkmk (e.g. the REST API) now need the default configuration to already be present at startup. This may cause issues with server configuration management systems (e.g. Puppet, Chef or Ansible) when these systems expect a certain file to be missing in a newly created site, whereas now these files will exist. The files in question are: etc/check_mk/multisite.d/wato/ca-certificates.mk etc/check_mk/multisite.d/wato/groups.mk etc/check_mk/multisite.d/wato/global.mk etc/check_mk/multisite.d/wato/tags.mk etc/check_mk/multisite.d/wato/users.mk etc/check_mk/conf.d/wato/contacts.mk etc/check_mk/conf.d/wato/groups.mk etc/check_mk/conf.d/wato/rules.mk etc/check_mk/conf.d/wato/global.mk etc/check_mk/conf.d/wato/notifications.mk etc/check_mk/conf.d/wato/tags.mk

2 years, 11 months

Checkmk Werk 12951: response format of all host_config/folder_config REST API endpoints

by Christoph Rauch

ID: 12951 Title: response format of all host_config/folder_config REST API endpoints Component: Core & setup Level: 2 Class: Bug fix Version: 2.1.0i1 The response format of some host_config and folder_config endpoints did not fully conform to the OpenAPI spec. This has now been fixed, but this also means that the following endpoints create folder hosts of folder update folder bulk update folders move a folder bulk create hosts list hosts will have a different format in SOME attributes on the attributes key within the "extensions" key. The now documented format in the OpenAPI documentation is the correct one now.

2 years, 11 months

Checkmk Werk 12941: REST API: convert known host attributes to well defined structure

by Christoph Rauch

ID: 12941 Title: REST API: convert known host attributes to well defined structure Component: Core & setup Level: 2 Class: Bug fix Version: 2.1.0i1 Previously the outbound structure of host and folder attributes was not defined. The internal structure of the values were directly passed through. This was confusing because the inbound structure of these attributes was already defined, leading to 2 distinct structures of the same thing. This is no longer the case. This werk introduces documentation and validation/conversion of outbound host and folder attributes. Some attribute values may now be different due to this change. Please check your scripts.

3 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2