Checkmk werks level2 August 2020

checkmk-werks-lvl2@lists.checkmk.com

2 participants
3 discussions

Checkmk Werk 11361: Reworking of discovery rulesets for network interfaces and switch ports

by Joerg Herbel

ID: 11361 Title: Reworking of discovery rulesets for network interfaces and switch ports Component: Checks & agents Level: 2 Class: New feature Version: 1.7.0i1 Up to now, the discovery of network interfaces and switch ports was controlled by two main rules: "Network Interface and Switch Port Discovery" (discovery of single interfaces) and "Network interface groups" (grouping of interfaces). With this werk, we integrate "Network interface groups" into "Network Interface and Switch Port Discovery" and rework the latter. The rule "Network interface groups" is now deprecated and not applied any more. The reworked discovery ruleset is split into three parts: the configuration of the discovery of single interfaces, the configuration of interfaces groups and conditions which determine to which interfaces this rule applies. In the following, we explain the changes in more detail. <ul> <li>In the first part, you can activate or deactivate the discovery of single interfaces. You can also configure the way monitored interfaces are represented, i.e., by index, by description or by alias.</li> <li>The second part offers the option to group interfaces. Here, you can specify the names of the groups and they way the corresponding services display their members in the service output (again, by index, by description or by alias). Contrary to before, there is no separate option any more to define interface groups on clusters, since this option was anyway redundant. </li> <li>The third part of the rule determines to which interfaces this rule applies. You can choose to apply this rule to all interfaces or you can set conditions such as a regular expression matching the interface description or a set of port types. Each interface will first determine the set of rules which actually applies to this interface and then merge these rules together, whereby rules higher up in the hierarchy (e.g. rules in subfolders) overwrite rules further below.</li> <li>Note that due to the point above, this rule is a somewhat special case compared to other rulesets in checkmk. Usually, the conditions for a rule to apply are exclusively configured in the section "Conditions". However, here, you can set additional, interface-specific conditions, which offer a finer control over the discovery process.</li> </ul> This change is incompatible. It affects the following checks: <tt>aix_if</tt>, <tt>brocade_optical</tt>, <tt>emc_vplex_if</tt>, <tt>esx_vsphere_counters</tt>, <tt>fritz</tt>, <tt>hitachi_hnas_fc_if</tt>, <tt>hp_msa_if</tt>, <tt>hpux_if</tt>, <tt>if</tt>, <tt>if64</tt>, <tt>if64adm</tt>, <tt>if64_tplink</tt>, <tt>if_brocade</tt>, <tt>if_fortigate</tt>, <tt>if_lancom</tt>, <tt>lnx_if</tt>, <tt>mcdata_fcport</tt>, <tt>netapp_api_if</tt>, <tt>statgrab_net</tt>, <tt>ucs_bladecenter_if</tt>, <tt>vms_if</tt>, <tt>winperf_if</tt>. For users monitoring interface groups, this change is definitely incompatible. They have to migrate their current rules for grouping interfaces from the now deprecated ruleset "Network interface groups" to the new discovery ruleset. Note that there is no option any more to discover interface groups <i>instead of</i> the corresponding single interfaces. To reproduce this behavior, configure your interfaces groups and switch off the discovery of single interfaces for the group members. After migrating the grouping rules, these users have to re-discover the services of affected hosts. For all others users monitoring network interfaces, this change might be incompatible. Generally, any already discovered interface services will continue to work. However, depending on the user- defined rules from the (now reworked) ruleset "Network Interface and Switch Port Discovery", some interface services might vanish upon re-discovery or new interface services might appear. In such cases, users have to adapt the new, reworked versions of their user-defined rules. Finally, it is worth noting that the new ruleset offers the option to match all interfaces, which allows for simplifying some rules. In particular, users might be able to simplify rules where all interface port types and states are selected.

4 years

Checkmk Werk 11263: Fix piggyback path traversal

by Lars Michelsen

ID: 11263 Title: Fix piggyback path traversal Component: Core & setup Level: 2 Class: Security fix Version: 1.7.0i1 In previous versions it was possible to create files in the querying Checkmk site by modifying or extending an agent on a monitored system. So an attacker who gained rights on a monitored system to extend the agent could create and modify files in the monitoring Checkmk site with certain modifications of the agent. The creation or modification of files in the Checkmk site was done with rights of the Checkmk site user. This problem is now solved by a better validation of hostnames of piggybacked hosts. With this change only these characters are allowed in Piggybacked hostnames: <tt>0-9a-zA-Z_.-</tt>. These are exactly the same characters that Checkmk normally allows when creating hostnames. A special feature of Piggyback hostnames is that all illegal hostnames are replaced by "_". This change means that Piggyback hosts created with now invalid characters will have to be created differently after this change so that they can continue to be monitored.

4 years

Checkmk Werk 11261: Fix performance regression caused by too many live status queries between EC and core

by Lars Michelsen

ID: 11261 Title: Fix performance regression caused by too many live status queries between EC and core Component: Event Console Level: 2 Class: Bug fix Version: 1.7.0i1 The version 1.6.0p14 introduced an issue affecting the Event Console and it's Livestatus communication with the local monitoring core. Instead of querying static configuration related information, which is needed by the Event Console only once per core restart, these information were not cached as intended. This resulted in these queries being made over and over again. The query was executed in the following situations: <ul> <li>Multiple times when querying the "eventconsolestatus" table (Once for each host known by the Event Console)</li> <li>Once for each created event</li> </ul>

4 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 August 2020