ID: 8024
Title: Notifications: New notification variables set by CMC: HOSTCONTACTGROUPNAMES / SERVICECONTACTGROUPNAMES
Component: cmc
Level: 1
Class: New feature
Version: 1.2.5i6
Please note that these new variables are not available when using the Nagios core.
ID: 8025
Title: Add all custom variables of host, service and contact to notification
Component: cmc
Level: 2
Class: New feature
Version: 1.2.5i1
The CMC now automatically adds all custom variables of hosts, service and
contacts to the notification context. The variable name is prefixed with
the word <tt>HOST</tt>, <tt>SERVICE</tt> or <tt>CUSTOM</tt> and - as its
variable name custom - converted to upper case. So a host variable with
the name <tt>_foobar</tt> will be available as <tt>HOST_FOOBAR</tt> in the
notification context. The names will be prefixed with <tt>NOTIFY_</tt> and put
into the environment of the notification plugin. So at the end the variable
will be available as <tt>NOTIFY_HOST_FOOBAR</tt>, e.g. in a shell script:
F+:mynotify.sh
echo "Foobar: $NOTIFY_HOST_FOOBAR"
F-:
H2:Notes
<ul>
<li>In the configuration files in <tt>main.mk</tt> or below <tt>conf.d</tt>
the variables can be set via <tt>extra_host_conf</tt> or <tt>extra_service_conf</tt>.
You need to have the variable names begin with an underscore. So a variable name of <tt>foobar</tt>
is not allowed. You have to write either <tt>_foobar</tt> or <tt>_FOOBAR</tt>.</li>
<li>When you add contact custom variables via WATO (button <i>Custom Attributes</i>
in the users management</i>) the underscore will <i>automatically</i> be added.</li>
<li>when using Nagios as monitoring core you have to adapt <tt>check_mk_templates.cfg</tt>
whenever you add a new custom variable.</li>
</ul>
ID: 8026
Title: Change default state retention of CMC from 1 to 10 minutes
Component: cmc
Level: 1
Class: New feature
Version: 1.2.5i1
This saves disk IO.
ID: 8020
Title: checkhelper: Reports an UNKNOWN error if the service check command exceeds the maximum size of 4096
Component: cmc
Level: 1
Class: Bug fix
Version: 1.2.5i4
ID: 8021
Title: hostgroups servicegroups: fixed host / service visible when using group_authorization AUTH_STRICT
Component: Livestatus
Level: 1
Class: Bug fix
Version: 1.2.5i5
This only applies with the setting group_authorization = AUTH_STRICT.
When an auth user was given the livestatus tables hostgroups and servicegroups did not
check if the auth user had permissions to all objects of the group.
As a result the user was able to view host- and servicegroups, even if he was not a contact
for every object in it. However, the "forbidden" object itself was not returned, just a subset
of the group. This was incorrect. The user needs to be contact of every element in this group.
Otherwise he should not see the group at all..
ID: 8022
Title: group_authorization AUTH_STRICT: no longer returns unexpected results
Component: Livestatus
Level: 1
Class: Bug fix
Version: 1.2.5i5
When the group_authorization was set to AUTH_STRICT the following problem happened:<br>
If an auth_user was the contact of every element in the group no data was from this group
was returned.<br>
This error could be observed in the multisite views <tt>Hostgroups (Summary)</tt> or
<tt>Servicegroups (Summary)</tt>
ID: 8017
Title: Host check command "use status of service" no longer fails on sles11
Component: cmc
Level: 1
Class: Bug fix
Version: 1.2.5i1
The plugin check_lql_service had troubles using the IFS /x01 while reading the livestatus answer.<br>
This has been observed for sles11sp2-64.<br>
The IFS has been changed to /x02.
ID: 8018
Title: Flapping notifiations for services are no longer sent if switched off
Component: cmc
Level: 2
Class: Bug fix
Version: 1.2.5i1
The users global notification option "Service" - "Start or end of flapping state"
was not processed correctly by the core, so the user received flapping alert
notifications even if this option was disabled.