ID: 14605
Title: windows_updates: correctly evaluate ruleset
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
The windows updates agent plugin got packaged to the Windows agent,
even if the corresponding agent ruleset "Windows Updates" was set to
"Do not deploy Windows Updates plugin".
ID: 14290
Title: Improve 'omd update' apache config handling
Component: Site Management
Level: 1
Class: Bug fix
Version: 2.2.0i1
The intended update warning that should be shown in case the
Apache hook was not up-to-date was not shown correctly in 2.1.0p9.
And during update a update warning
<tt>Unwanted etc/apache/apache-own.conf (unchanged, deleted by you)</tt>
was shown which could lead to confusions. This warning has been removed.
ID: 14681
Title: Fixed activation of event console log levels
Component: Event Console
Level: 1
Class: Bug fix
Version: 2.2.0i1
Changing the log levels for the event console only didn't have an effect
when it was triggered via the GUI, only when the EC was restarted. This has
been fixed.
ID: 14656
Title: service discovery: addition of wait for completion endpoint
Component: REST API
Level: 1
Class: New feature
Version: 2.2.0i1
This werk introduces the wait for completion endpoint for a service discovery run.
The current redirect link in the "Execute a service discovery on a host" with mode
"refresh" which previously linked to the service_discovery_run object will be replaced
by this newly introduced endpoint.
ID: 14261
Title: Manual enablement of login using HTTP GET to avoid unintentional leakage of user credentials in Apache's access logs
Component: Setup
Level: 1
Class: Security fix
Version: 2.2.0i1
Using <tt>GET</tt> requests to <tt>login.py</tt> means that the credentials supplied in the query parameters will appear in the site's Apache logs. To avoid unintentional leakage of such credentials, we <b>by default</b> block login attempts via the <tt>GET</tt> method.
If you used the <tt>GET</tt> method to, for example, export the data of views and dashboards in formats such as <tt>JSON</tt>, you can make use of the <tt>automation</tt> user as described in <a href="https://docs.checkmk.com/latest/en/wato_user.html#automation">documentation</a> article. For example, to display the view <i>allhosts</i> in <tt>JSON</tt> format, you can issue requests like this one <tt>curl -X GET 'http://localhost/heute/check_mk/view.py?_username=automation&_secret=[autom…'</tt>.
However, if you <b>still need to use the <tt>GET</tt> method to login to WATO</b>, you can manually enable this method as follows:
In the WATO interface, go to Setup > Global Settings > User interface, and switch on the <i>Enable login via GET requests</i> property.
ID: 14639
Title: megaraid_ldisks: Missing variable expansion in item
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
Every linux server with MegaRAID controller reported only one service for logical disks, independent of the actual number of configured logical disks, named <i>"RAID Adapter/LDisk /c{adapter}/v{disk}"</i> (sic, without replacement of the variables).
Please rediscover the services.
ID: 14638
Title: Agent vSphere: Configuration of expected name in SSL certificate
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
The configuration of the expected name in the servers SSL certificate now works as intended.
ID: 14451
Title: mk_logwatch: lost log messages
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 2.2.0i1
This werk fixes the occasional loss of messages reported by the agent plugin <i>mk_logwatch</i>.
Sometimes messages could be "stolen" by (for instance) a manual execution of <tt>cmk -d MyHost</tt>.
<b>Previously:</b>
Every time the logwatch plugin was executed, it gathered all relevant log messages that have accumulated since its last execution.
Those messages where then reported as agent output during this execution of the plugin, and never again.
The problem:
Log messages are only dealt with by the checking engine of Checkmk.
If the plugin is executed in a different context (such as the HW/SW inventory or service discovery) the reported log messages are lost.
To mitigate this problem, the default caching parameters of a site are carefully calibrated so that this should rarely only occur.
However a manual execution of <tt>cmk -d MyHost</tt> for instance can always result in data loss.
<b>From now on:</b>
Every time the plugin is executed, as previously the plugin gathers all relevant messages since its last execution.
It now puts these messages in a bundle and stores it on disk.
Then all bundles that have been created within a configurable period, the <i>retention period</i>, are output and sent to the monitoring site.
The monitoring site will keep track of the bundles, and only process the ones it has not seen before.
You can configure the <i>retention period</i> using the ruleset <i>Text logfiles (Linux, Solaris, Windows)</i>.
The <i>retention period</i> should be - at least - as long as the check interval of the host, to decrease the risk of data loss drastically.
A value that is much smaller than the hosts check intervall, will not automatically lead to data loss, tough.
It will just not help preventing it.
Note that putting the N-fold of the hosts check intervall will result in every bundle of messages being fetched N times (during regular operation).
As a result the amount of transmitted data increases, obviously.
Also those bundles are stored on disk on the monitored host, taking up as much space as the transmitted data.
Those are the two ressources that are being traded for a reduced risk of data loss.
ID: 14489
Title: UI: Open PDFs in new tab
Component: Multisite
Level: 1
Class: New feature
Version: 2.2.0i1
Reports and other PDFs used to be opened within the current page. Now, PDFs are opened in a new tab.
ID: 14500
Title: lnx_if_sys_class_net: new agent and section plugin for network interfaces
Component: Checks & agents
Level: 1
Class: New feature
Version: 2.2.0i1
We have added a new agent plugin and corresponding section plugin to monitor
network interfaces. These plugins provide essentially the same information as
the section <tt>lnx_if</tt>, which is a Checkmk agent section, and are an
alternative: if both sections are provided, only <tt>lnx_if_sys_class_net</tt>
is considered.
Note that this agent plugin is not supported by the agent bakery.