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.
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.
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>
ID: 11248
Title: Agent bakery: Automatically build agents for created hosts
Component: agents
Level: 2
Class: New feature
Version: 1.7.0i1
After creating a new host in the configuration, the agent baking process for
the new host is triggered now. When multiple hosts are created at once, for
example using the API or an import mechanism, one baking process is started for
all of these hosts.
The process is started as a background job, just like when a bake process is
started manually. With the single difference that the process only cares about
the newly added hosts. You can see the process or result message when accessing
the Agent Bakery page in your Configuration.
ID: 11246
Title: Drop classic theme
Component: Multisite
Level: 2
Class: New feature
Version: 1.7.0i1
With this change we remove the Classic theme. Even though there are still many
fans of this theme who like to use our Classic Theme, we can no longer support
this theme in the future due to cost and effort.
Users of the Classic Theme will automatically be switched to the current
default theme.
The main reason for this change is that we will make massive changes to the
user interface of Checkmk with the upcoming version. We can easily implement
these changes in the modern and dark theme together. In addition, we would have
had to redesign and implement some of these in the Classic theme, which we
cannot afford.
ID: 11245
Title: Dashboard: Improve context sensitive dashboard handling
Component: Multisite
Level: 2
Class: New feature
Version: 1.7.0i1
Each user opening a dashboard is now able to apply custom filters to a dashboard
when viewing it. This can be done by opening the "Update context" dialog from
the dashboard menu.
>From that menu it is possible to select one or multiple filters that will then
be used to filter the data shown by the dashboard.
This is much like the filter form in the views.
One additional feature has been added that can be used to enforce the user to
use one or multiple filters when initially opening a dashboard.
Imagine you want to have a dashboard that shows data of hosts in a given
hostgroup, for example you want to have a linux, windows, unix dashboard and so
on.
In previous versions you could build one dashboard and clone it multiple times
while changing the filter group name for each of the cloned dashboards. That
would work, but you would end up with a lot of similar dashboards where only
the hard coded host group filter was different.
Now you can define a single dashboard and select the "Host is Group" filter in
the new "Required context filters" option from the dashboard properties. Once
you have done this, the dashboard will automatically open the "Dashboard Context"
dialog when initially opening the dashboard. After selecting the host group, the
dashboard will be rendered.
Btw.: You could also open the dashboard with the prefilled URL parameters to
prevent the "Dashboard Context" dialog from popping up.
ID: 10993
Title: Diagnostics: New WATO mode for diagnostic analysis purposes
Component: WATO
Level: 2
Class: New feature
Version: 1.7.0i1
In order to improve error analysis there's a new WATO mode {{Diagnostics}}.
With this new mode you can collection some general information about the
Checkmk server and version. Details can be found on the {{Diagnostics}} page.
In the future this mode will be extended with specific diagnostics elements,
eg. information about local files.
This mode will help you to analyse error situations. Another purpose is to have
an interface for collecting information for our support, your customers or
simply for your own analysis.
The diagnostics information are stored within tar files in the folder
{{var/check_mk/diagnostics}}. At the moment maximal five of these tar files are
stored. This number is not configurable.
There's also a command line option for collecting diagnostics information and
collects information about the Checkmk site where it's executed.
C+:
cmk --create-diagnostics-dump [OPTIONS]
C-:
Note: The {{Diagnostics}} mode does not solve any problems. It's just a data
collection which consolidates some commands and therefore facilitates error
analysis.
ID: 11078
Title: Dynamic configuration: Add connector plugin API
Component: DCD
Level: 2
Class: New feature
Version: 1.7.0i1
The Dynamic configuration is now loading plugins that are located below
the path <tt>local/lib/check_mk/cee/dcd/plugins/connectors/</tt>.
You can find a minimal example connector implementation it in your site at
<tt>lib/check_mk/cee/dcd/plugins/connectors/example_connector.py</tt>. You may
use this as base for your own connectors. To enable this connector, you need to
copy it to the plugin directory mentioned above and uncomment the registry
registration lines in the plugin (See TODO).
To be able to configure connections based on this connector in the GUI, you
also need to deploy a GUI plugin. An example can be found in your site at
<tt>lib/check_mk/gui/cee/plugins/wato/example_dcd_connector.py</tt>. This
needs to be placed in the WATO plugin directory of your site. You also need to
uncomment the registry registration line in the plugin (See TODO).
ID: 11078
Title: Dynamic configuration: Add connector plugin API
Component: DCD
Level: 2
Class: New feature
Version: 1.7.0i1
The Dynamic configuration is now loading plugins that are located below
the path <tt>local/lib/check_mk/cee/dcd/plugins/connectors/</tt>.
You can find a minimal example connector implementation it in your site at
<tt>lib/check_mk/cee/dcd/plugins/connectors/example_connector.py</tt>. You may
use this as base for your own connectors. To enable this connector, you need to
copy it to the plugin directory mentioned above and uncomment the registry
registration lines in the plugin (See TODO).
To be able to configure connections based on this connector in the GUI, you
also need to deploy a GUI plugin. An example can be found in your site at
<tt>lib/check_mk/gui/cee/plugins/wato/example_dcd_connector.py</tt>. This
needs to be placed in the WATO plugin directory of your site. You also need to
uncomment the registry registration line in the plugin (See TODO).
ID: 11078
Title: Dynamic configuration: Add connector plugin API
Component: DCD
Level: 2
Class: New feature
Version: 1.7.0i1
The Dynamic configuration is now loading plugins that are located below
the path <tt>local/lib/check_mk/cee/dcd/plugins/connectors/</tt>.
You can find a minimal example connector implementation it in your site at
<tt>lib/check_mk/cee/dcd/plugins/connectors/example_connector.py</tt>. You may
use this as base for your own connectors. To enable this connector, you need to
copy it to the plugin directory mentioned above and uncomment the registry
registration lines in the plugin (See TODO).
To be able to configure connections based on this connector in the GUI, you
also need to deploy a GUI plugin. An example can be found in your site at
<tt>lib/check_mk/gui/cee/plugins/wato/example_dcd_connector.py</tt>. This
needs to be placed in the WATO plugin directory of your site. You also need to
uncomment the registry registration line in the plugin (See TODO).