Checkmk werks level2 February 2019

checkmk-werks-lvl2@lists.checkmk.com

2 participants
8 discussions

Check_MK Werk 7185: Custom service attributes can now be configured

by Lars Michelsen

ID: 7185 Title: Custom service attributes can now be configured Component: WATO Level: 2 Class: New feature Version: 1.6.0i1 It is now possible to configure arbitrary custom attributes for all services just like it was already possible for hosts and users in previous versions. The configuration procedure is working equally, you first need to define an attribute in the first place, to be able to refer to the attribute and assign it to services. The definition of custom attributes is done using the Global Setting "Custom service attributes". Once you have defined a custom service attribute, you can assign it to a collection of services using the equal named ruleset "Custom service attributes". In general, you should keep the number of rules low. To support you in this, the rule is structured so that you can select several custom attributes for each rule. The custom service attribute will be named <tt>_[ID]</tt> in the core configuration and can be gathered using the Livestatus column <tt>custom_variables</tt> using the <tt>[ID]</tt>. The custom service attributes are available to notification scripts as environment variable named <tt>SERVICE_[ID]</tt>.

5 years, 6 months

Check_MK Werk 7100: mk_sap_hana: Refactored plugin; Deprecated old checks; Add new checks

by Simon Betz

ID: 7100 Title: mk_sap_hana: Refactored plugin; Deprecated old checks; Add new checks Component: Checks & agents Level: 2 Class: New feature Version: 1.6.0i1 Deprecated checks are: sap_hana_filesystem, sap_hana_full_backup, sap_hana_mem, sap_hana_process_list, sap_hana_version, New checks are: sap_hana_backup, sap_hana_data_volume, sap_hana_diskusage, sap_hana_ess, sap_hana_events, sap_hana_license, sap_hana_memrate, sap_hana_proc, sap_hana_replication_status, sap_hana_status, In order to make the SAP HANA checks work you have to install the agent plugin {{mk_sap_hana}} on your clients. If you have installed the old agent plugin then you have to replace it with the new agent plugin and perform a rediscovery of these hosts. The old check plugins are not discoverable any more and show the message WARN - "This check is deprecated. Please rediscover the services of that host."

5 years, 6 months

Check_MK Werk 7182: Improved GUI extension error handling

by Lars Michelsen

ID: 7182 Title: Improved GUI extension error handling Component: Multisite Level: 2 Class: New feature Version: 1.6.0i1 When extending the standard GUI functionality, using either a manually installed <tt>local/share/check_mk/web</tt> plugin or a Check_MK extension package (MKP), exceptions may occur while loading the plugin. In previous versions these exceptions caused the whole GUI to fail making it impossible to repair the problem using the GUI, for example via the extension package manager of the CEE/CME. The extension related loading errors are now all catched and logged to the <tt>var/log/web.log</tt> instead of making the whole application fail. In addition to this, an error message will be shown on the "Extension packages" WATO page. We've also added a new Analyze configuration check "Broken GUI extensions" which will report a CRIT state when broken GUI extensions are found.

5 years, 6 months

Check_MK Werk 7178: German translation is now available in all Check_MK Editions

by Lars Michelsen

ID: 7178 Title: German translation is now available in all Check_MK Editions Component: Multisite Level: 2 Class: New feature Version: 1.6.0i1 The German translation of the the Check_MK user interface is now available to the users of all Check_MK editions.

5 years, 6 months

Check_MK Werk 7089: Docker container: Simplified update procedure

by Lars Michelsen

ID: 7089 Title: Docker container: Simplified update procedure Component: Site Management Level: 2 Class: New feature Version: 1.6.0i1 The update procedure of the official Check_MK containers was a bit complicated compared to the update procedure on other servers. The root cause for this was that the update always required both, the old and the new versions, while the containers are only allowed to have one version installed. This made it necessary to create an intermediate container for the update. The werk #7088 made it possible to perform an update without having access to the old version. Once we have this functionality it is now possible to replace one container with a another container. In case the version has changed, the container is performing the update during startup of the new container.

5 years, 6 months

Check_MK Werk 7088: omd update can now be performed without access to source version

by Lars Michelsen

ID: 7088 Title: omd update can now be performed without access to source version Component: Site Management Level: 2 Class: New feature Version: 1.6.0i1 The "omd update" procedure, which is used to perform a version update for a site, always needed access to the previous version, the new version and the site. Since this change it is now possible to perform an update without access to the old version. This is possible becase we copy the information that are needed to the Check_MK site during site creation. This new mechanism can only be used when updating FROM a site that already implements this werk. Technical detail: <ul> <li>The meta files are saved for the first time during "omd create"</li> <li>The meta files are updated to the new version during each "omd update"</li> <li>The files are copied to the sites <tt>.version_meta</tt> directory.</li> <li>The directory <tt>/omd/versions/[version]/skel is copied.</li> <li>The file <tt>/omd/versions/[version]/share/omd/skel.permissions is copied.</li> <li>A file <tt><tt>.version_meta/version</tt> is created.</li> <li>When an update is performed, the meta files are used if they are available and up-to-date. In case they don't fit these conditiones, the previous version files need to be available as before this werk.</li> <li>

5 years, 6 months

Check_MK Werk 7081: Reworked "Distributed Monitoring" page

by Lars Michelsen

ID: 7081 Title: Reworked "Distributed Monitoring" page Component: WATO Level: 2 Class: New feature Version: 1.6.0i1 The "Distributed Monitoring" pages have been reworked to make it easier to manage multiple Check_MK site connections. The list page is now showing less site configuration details. Instead of these columns status columns have been added to visualize whether or not your site connections can currently be used. One column shows the current status of the Livestatus connection, which is needed by the GUI to gather the monitoring status from the site. In case your livestatus connection is not configured properly, you may have a look at the status and hover the icon for more information about the reason. One possible reason for a non functional Livestatus connection may be a TLS connection issue (if you use encrypted Livestatus). You can use this site to inspect the remote site certificate and establish a trust with this certificate to allow the GUI to connect with that site. The replication status column tells you whether or not the configuration replication connection is working.

5 years, 6 months

Check_MK Werk 7017: Livestatus via TCP can now be encrypted

by Lars Michelsen

ID: 7017 Title: Livestatus via TCP can now be encrypted Component: Livestatus Level: 2 Class: New feature Version: 1.6.0i1 Livestatus has been a plain text protocol since it's invention. This is normally OK for system local connections via unix socket or TCP connections in secure networks. Users always had the choice to secure the communication using TLS (e.g. via stunnel), SSH, VPN or some other solution that encrypts the communication in their local setup. To improve the security for all users of Check_MK, we have now changed the Livestatus TCP communication to be encrypted by default using TLS. This is realized using an internal CA and internally generated certificates. Existing sites that already have Livestatus via TCP enabled before updating to 1.6 still use the unencrypted communication for compatibility. An analyze configuration" test will create a CRITICAL message about the unencrypted Livestatus TCP configuration in this situation. Technical details: <ul> <li>For new sites Livestatus via TCP is encrypted by default. Existing sites which already have Livestatus via TCP enabled during the update keep the communication unencrypted for compatibility reasons. This is managed using the new 'omd config' option LIVESTATUS_TCP_TLS. This setting can also be managed through the "Global Settings > Site Management".</li> <li>During update or site creation a site local CA certificate is created to manage the sites local certificates.</li> <li>The site local certificate is created automatically during update or site creation.</li> <li>The sites local CA and certificates are stored in 'etc/ssl'. The CA certificate is always located at 'etc/ssl/ca.pem'.</li> <li>The keys are 2048 bit RSA keys and the certificates are signed using SHA512.</li> <li>The CA certificate is valid for 10 years, the site certificates are valid for 3 years.</li> <li>Check_MK / OMD code may use 'omdlib.certs.SiteLocalCA(site_id)' to use the local CA</li> <li>stunnel is introduced as site internal daemon that serves the TLS wrapped socket once it has been enabled through 'omd config'. </ul>

5 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 February 2019