ID: 8098
Title: Do not hang core if Carbon server is not resonding
Component: cmc
Level: 1
Class: Bug fix
Version: 1.2.6b1
If you connected the Check_MK Micro Core to Carbon (Graphite) and the
carbon server was down then the core would hang after a while in a
very nasty long TCP timeout. This is been fixed. If carbon is too slow
to handle all the data or if the server is hanging then Check_MK uses
the available TCP buffer space for queing graph updates and skips then
any further updates, while logging a message into <tt>cmc.log</tt>:
F+:var/log/cmc.log
2014-12-01 17:16:47 [4] Carbon is too slow. Skipping update of xysrv123;Check_MK;system_time
F-:
ID: 8099
Title: Correctly handle performance data variables with square brackets in their names
Component: cmc
Level: 1
Class: Bug fix
Version: 1.2.6b1
JMX4Perl uses such questionable variable names, for example (not the officially shipped
Check_MK checks but the legacy active checks).
ID: 8100
Title: Fix disabling of notifications when done both via rule and command
Component: cmc
Level: 2
Class: Bug fix
Version: 1.2.6b1
When you have disabled the notifications of a service (or host) via a
command and later disabled the notifications of the same service via a rule,
then in effect the notification became enabled again! This was due to the
internally stored information about which setting has been modified. This
has now been fixed. The core now correctly keeps track of which enabling
(notifications, active and passive checks) has been modified and which is
the new manual setting. The manual setting will override any configuration
setting until it is cleared.
Clearing manual settings can be done with the command <i>Clear modified
attributes</i> in Multisite (which internall calls <tt>CHANGE_HOST_MODATTR</tt>
or <tt>CHANGE_SVC_MODATTR</tt>.
<b>Note</b>: The Nagios core behaves different here. Clearing the modified
attributes just removes the information that they have been modified -
not their actual setting! There is no way to generally remove manual settings
here other then manually set all back to their configuration settings and
<b>afterwards</b> again issue <i>Clear modified attributes</i>. The CMC
decided to not mimick this strange behaviour.
ID: 8093
Title: New option for expiration of acknowledgements
Component: cmc
Level: 2
Class: New feature
Version: 1.2.6b1
Acknowledgements can now optionally expire. Multisite has been extended
by an option to set a timespan when acknowledging problems. At the end
of this timespan the acknowledgement is automatically removed and
a log entry created in <tt>cmc.log</tt>. You can see an expiration in the
details views about the comments of a host or service.
Expiration of acknowledgements mean something like "This should be
repaired within time X". In combination with periodic notifications
these acknowledgements will in effect stop the notifications for the
configured while.
ID: 8095
Title: Agent bakery now creates .tar.gz files as an alternative for RPM and DEB
Component: agents
Level: 2
Class: New feature
Version: 1.2.6b1
The tarballs are not meant for direct use in the first place. But they are
conventiant of you want to extract some of the baked files with your
own scripts.
ID: 8096
Title: Configurable installations paths for Linux agents
Component: agents
Level: 1
Class: New feature
Version: 1.2.6b1
The agent bakery now allows to configure the paths for the binaries
(Default: <tt>/usr/bin</tt>), the configuration files (Default:
<tt>/etc/check_mk</tt>) and the base directory for plugins and local checks
(Default: <tt>/usr/lib/check_mk_agent</tt>). These paths are correctly applied
to baked RPMs, DEBs and Tarballs. Also the environment variables that inform
plugins about the configuration path are correctly being modified in the
actual <tt>check_mk_agent</tt>.
ID: 8090
Title: Report scheduler - automatically email reports on a regular base
Component: Reporting & Availability
Level: 3
Class: New feature
Version: 1.2.6b1
The new reporting scheduler allows users to have reports emailed at
regular intervals. The scheduler is available for admins and normal
users. Normal users can only mail reports to themselves.
Currently the schedule can be daily, weekly or monthly, where you
can configure the time of day and the relative day in the week
or month.
The scheduler allows to specify contexts for reports that need
a context. For example you can use the shipped example report
<i>Report of host</i> and specify the host to report about
directly in the scheduler.
ID: 8091
Title: Make baked agents and configuration files unreadable for the world
Component: agents
Level: 1
Class: Bug fix
Version: 1.2.6b1
This is just for security. Agents and configuration files <b>might</b> contain
passwords. So read access to the agents on the monitoring server is now only
allowed for the OMD site user. Read access to any configuration file on the
agent itself in <tt>/etc/check_mk</tt> (Linux) is denied for the others.
ID: 8092
Title: Bake generic and vanilla agent
Component: agents
Level: 2
Class: New feature
Version: 1.2.6b1
The agent bakery used to always create a so called <i>Generic agent</i>. That was
an agent with a default configuration.
Now the bakery per default creates two - possible identical - agents: The <i>Vanilla</i>-agent is
what had been the generic agent. It is an agent without any plugins and with the default
configuration. The <i>Generic</i> agent is an agent with all rulesets being applied that do
not have any positive restrictions. It is the agent for a generic host, i.e. a host that
has no tags and no name. All rules that do not require certain tags to be <i>set</i> or
do require the host to have a certain name are being used. This allows you to create a proper
agent without creating any host at the first place.