Checkmk werks level1 October 2020

checkmk-werks-lvl1@lists.checkmk.com

14 participants
63 discussions

Checkmk Werk 11118: Plugin development: make all includes imports

by Moritz Kiemer

ID: 11118 Title: Plugin development: make all includes imports Component: Checks & agents Level: 1 Class: New feature Version: 2.0.0i1 This Werk only affects users who have developed their own check or inventory plugins *and* are using some of the shipped includes in them. The *.include files have been moved to a dedicated module and are replaced with imports. Note that the "include" mechanism is still available. If you are using your own include file you can continue to to so. However, if you are using (or shadowing) one of the shipped include files, you will need to change your plugins. Users who are using code from a shipped include file should adapt their plugin in the following way: <ul> <li>drop the "includes" keyword from the <tt>check_info</tt></li> <li>import the required names from the module coresponding to the former include file</li> </ul> For example: If you used the line <tt>"includes": ["temperature.include"],</tt> to access the <tt>check_temperature</tt> function, you should now add the line <tt>from cmk.base.check_legacy_includes.temperature import check_temperature</tt> at the top of your plugin. You can grep for "temperature import" in the checks directory for some examples. The checks/ directory can be found either at the top level of the git repository, or in in the share/check_mk/ folder of your site. Note that a wildcard import is used currently, but this is considered bad practice. You should explicitly import the required names. If you have made local changes to an include file *but not to the plugin that should be affected*, you need to do the reverse: Locally change said plugin to re-introduce the "includes" key to the <tt>check_info</tt> *and* remove the corresponding import statement.

3 years, 10 months

Checkmk Werk 11402: Agent Bakery: New "Bake and sign" action

by Andreas Umbreit

ID: 11402 Title: Agent Bakery: New "Bake and sign" action Component: agents Level: 2 Class: New feature Version: 2.0.0i1 It is now possible to bake and sign all agents in one step. You can simply do this by pressing the corresponding button at the agent bakery. It will be available as soon as at least one signature key has been created or imported. When invoking "Bake and sign agents", you will be prompted for selecting a signature key and entering its passphrase. After that, every agent package will get baked and signed immediately after baking. When using "Bake and sign", it is assured that there are no unsigned packages visible for download at any time, avoiding that it could be seen accidentally by a calling agent updater, leading to a "The deployment server provides an agent but that is not signed." error. The "Bake and sign" action is also available via REST API, please refer to the documentation for details.

3 years, 10 months

Checkmk Werk 11401: New Bakery API

by Andreas Umbreit

ID: 11401 Title: New Bakery API Component: agents Level: 3 Class: New feature Version: 2.0.0i1 It is now possible to extend Checkmk by writing your own bakery plugins. That is, you can now deploy your own agent plugins and have them baked into your agents by the agent bakery. While this was also possible before by placing the right files at the right locations, you can now deploy your plugins with the help of a well-documented, versioned and comprehensive API. A bakery plugin is a Python 3 module that specifies files that should be deployed to the baked agents, scriptlets that should be executed on the target system (RPM scriplets, DEB maintainer scripts, Solaris PKG installation scripts) on package transition, and Windows agent config entries (YAML config) that should be available for the baked windows agents. You can add your own bakery plugins by placing them at <code>~/local/lib/check_mk/base/cee/plugins/bakery/</code>. For instructions and details on how to use the new API, please refer to the official Checkmk documentation. With Checkmk 2.0, also the majority of the builtin bakery plugins have been migrated to the new Bakery API, so having a look at them at <code>~/lib/check_mk/base/cee/plugins/bakery/</code> can also help to write your own plugins. If you have deployed your bakery plugins to Checkmk before, using the previous method of placing a plugin file to <code>~/local/share/check_mk/agents/bakery/</code>, your plugins will continue to work with Checkmk 2.0, if you convert them to Python 3 syntax. However, the Agent Bakery will display a deprecation warning on baking agents (visible at the bake-agents background job details at the GUI, or on the console if baking via command line), and the support for legacy bakery plugins will be removed in an upcoming version of Checkmk, so it's worth it to migrate your plugins to the new API early.

3 years, 10 months

Checkmk Werk 11403: Improved versioning for baked agent packages

by Andreas Umbreit

ID: 11403 Title: Improved versioning for baked agent packages Component: agents Level: 1 Class: New feature Version: 2.0.0i1 Previously, when updating a baked agent via a package manager, you would eventually receive a warning about a downgrade of the Checkmk agent. The reason for this was the baked agent's version string, that was formed of Checkmk version and the agent's configuration hash , with the latter being quite random and thus confusing the package manager, that expects an increasing versioning. E.g. a version string could be <tt>1.6.0p18.f123abcd</tt> before bake, and <tt>1.6.0p18.1234cdef</tt> after bake. This behavior is now fixed by introducing an internal bake revision, that increases on every newly baked package (per Checkmk version) and that's only purpose is to guarantee an increasing version string for the .rpm, .deb and .pkg packages (e.g. <tt>1.6.0p18-1.f123abcd</tt> before bake, <tt>1.6.0p17-2.1234cdef</tt> after bake). Please note that this revision won't be visible on the GUI or in the package's filenames, it only affects the package's metadata.

3 years, 10 months

Checkmk Werk 11373: Made titles of options in host/folder permissions less uncertain

by Marcel Arentz

ID: 11373 Title: Made titles of options in host/folder permissions less uncertain Component: WATO Level: 1 Class: Bug fix Version: 2.0.0i1 There have always been additional option when assigning contact groups to WATO folders or hosts. The effect of this options meanwhile has not always been absolute transparent depending if the user is in folder or in host properties. Especially the outcome of option "Always add host contact groups also to its services" has not been clear. The titles do now explain better, what a particular option really does. This is just a clarification of the current, actual behaviour and no change of the behaviour itself. Therefore there is no need for manual interaction.

3 years, 10 months

Checkmk Werk 11325: mssql_jobs: new plugin to monitor scheduled jobs on MSSQL Server

by Lisa Pichler

ID: 11325 Title: mssql_jobs: new plugin to monitor scheduled jobs on MSSQL Server Component: Checks & agents Level: 1 Class: New feature Version: 1.7.0i1 mssql_jobs is a new plugin that enables the monitoring of scheduled jobs on Microsoft SQL Server. Each job is listed as a seperate service, for which the following information is shown: -job duration -MSSQL job status -outcome message -step name at which the job failed (if applicable) -last run -next run It is possible to set warn/crit levels for the job duration, in case the job or schedule is inactive, and/or corresponding to the MSSQL job status. Performance data is tracked in terms of job duration.

3 years, 10 months

Checkmk Werk 11338: Fix "Fortigate Active Sessions" ruleset duplicates

by Wontek Hong

ID: 11338 Title: Fix "Fortigate Active Sessions" ruleset duplicates Component: WATO Level: 1 Class: Bug fix Version: 2.0.0i1 In previous versions, there were two WATO rules which had the name "Fortigate Active Sessions" where one concerned the Cluster environment. This change renames the Cluster rule to allow a proper differentitation.

3 years, 10 months

Checkmk Werk 11117: Drop support for creation of HostLabels via discovery function

by Moritz Kiemer

ID: 11117 Title: Drop support for creation of HostLabels via discovery function Component: Checks & agents Level: 1 Class: New feature Version: 2.0.0i1 This werk only affect users who implemented their own plugins *and* where creating HostLabels using the discovery function. Plugins trying to create HostLabel instances will fail with a NameError. The afore mentioned feature is no longer supported. Creation of host labels can now only be implemented using the new check API. It is done by passing a `host_label_function` to the `register.agent_section` function. For details please refer to the dokumentation.

3 years, 10 months

Checkmk Werk 11486: LDAP: Fixed updating of attribute "Disabled Notifications"

by Ronny Bruska

ID: 11486 Title: LDAP: Fixed updating of attribute "Disabled Notifications" Component: Multisite Level: 1 Class: Bug fix Version: 2.0.0i1 Werk #11481 fixed the usage of the attribute but did not take care, that the attribute was updated, once it was enabled. If you set the attribute from "True" to "False" in LDAP, the attribute now will be updated.

3 years, 10 months

Checkmk Werk 11511: Host label dependent services are now discovered automatically

by Simon Jess

ID: 11511 Title: Host label dependent services are now discovered automatically Component: Checks & agents Level: 1 Class: New feature Version: 2.0.0i1 A service discovery had to be executed twice in order to detect new services based on host labels. The first execution found new host labels, the second one found new services based on the previously found host labels. These two steps are merged into one and services based on host labels are discovered on-the-fly.

3 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 October 2020