ID: 2779
Title: Fix moving of folders
Component: WATO
Level: 2
Class: Bug Fix
Version: 1.2.7i4
This fixes the error message <i>Cannot move folder: A folder with this name
already exists in the target folder.</i>
ID: 2843
Title: Hanging notification scripts could prevent all other notifications
Component: Notifications
Level: 2
Class: Bug Fix
Version: 1.2.7i4
Notification scripts are assumed to finish within short time like a couple
of seconds. If a notification script takes longer or is hanging for ever,
it prevent Check_MK from sending out other notifications. So one hanging
notification could prevent all others.
This has been fixed by introducing a global notification plugin timeout.
All notification plugins which take more than 60 seconds will be killed
so that other notifications can be done again. If you need a different
timeout, you can configure it using the global setting "Notification plugin timeout".
ID: 2771
Title: Errors in Check_MK configuration do not prevent the core from being restarted anymore
Component: Core & Setup
Level: 2
Class: New Feature
Version: 1.2.7i4
This has been implemented for the CMC configuration generating mechanism some time ago.
See werk #8294 for details. This has also been implemented for installations which use
Nagios as monitoring core.
ID: 0973
Title: Renaming of hosts via WATO
Component: WATO
Level: 2
Class: New Feature
Version: 1.2.5i3
WATO has now a new function <i>Rename Host</i>. You will find a button with that name
in the Properties of a host. It allows a renaming of an existing host. Before you
can use that feature you need to have all changes activated, so nothing is pending.
Renaming a host is a complex precedure that will not only rename the host in WATO,
but also in:
<ul>
<li>all rules from <i>Host & Service Parameters</i></li>
<li>cluster's node definitions</li>
<li>a host's parent definitions</li>
<li>Business Intelligence rules</li>
<li>notification rules (both rule based and flexible notifications)</li>
<li>internal Check_MK data like caches and performance counters</li>
<li>auto-disovered services of the host</li>
<li>logfile information of logwatch plugin</li>
<li>stored SNMP walks</li>
<li>RR databases with performance data</li>
<li>RRD updates in journal of RRD Cache</li>
<li>spool files of PNP4Nagios</li>
<li>NagVis maps</li>
<li>monitoring history entries (events and availability)</li>
<li>the current monitoring state (including ackowledgements and downtimes)</li>
</ul>
Please note that renaming of a host involves a temporary stop of the monitoring
core. This is neccessary in order to avoid situation where the old and the new
name of a host is being used at the same time.
ID: 2756
Title: SNMP: Generalized error handling of emtpy info for SNMP checks
Component: Core & Setup
Level: 2
Class: Bug Fix
Version: 1.2.7i4
This change changes the way empty data for SNMP checks is handled.
In previous version each SNMP check had to deal with the fact that
the SNMP agent could respond with an empty response (info = []).
This situation can better be handled in the Check_MK SNMP engine
which catches this issue now before calling the discovery/check
function of the check. The error is then reported as missing info
like for the Check_MK Agent based checks.
There might be some special SNMP checks which need to treat this
case of empty data on its own. These checks now need to declare
the attribute <tt>handle_empty_info</tt> in the <tt>check_info</tt>.