ID: 7032
Title: logwatch: Optional shared log pointer for several ip addresses
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
Previous Check_MK versions potentially showed duplicate log file entries
in case the monitoring setup used a failover cluster configuration (cluster
consisting of at least 2 cluster nodes, each running a Check_MK instance
and providing Check_MK via virtual host).
This werk adds support for an optional shared log pointer between several
requesting IP addresses. This prevents from potentially duplicate log file entries.
The mapping of cluster node IP addresses to a cluster name may be configured
either manually by editing the logwatch configuration file or via the agent bakery.
Users of the configuration file logwatch.cfg and/or files logwatch.d/*.cfg may
configure a mapping according to the syntax described in
agents/cfg_examples/logwatch.cfg for configuration.
Users of the agent bakery may use the ruleset "Text logfiles (Linux, Windows)"
option "Specify a mapping of cluster node IPs to a cluster name (failover cluster)".
ID: 7017
Title: Livestatus via TCP can now be encrypted
Component: Livestatus
Level: 2
Class: New feature
Version: 1.6.0i1
Livestatus has been a plain text protocol since it's invention. This is
normally OK for system local connections via unix socket or TCP connections
in secure networks.
Users always had the choice to secure the communication using TLS (e.g.
via stunnel), SSH, VPN or some other solution that encrypts the
communication in their local setup.
To improve the security for all users of Check_MK, we have now changed
the Livestatus TCP communication to be encrypted by default using TLS.
This is realized using an internal CA and internally generated
certificates.
Existing sites that already have Livestatus via TCP enabled before
updating to 1.6 still use the unencrypted communication for
compatibility. An analyze configuration" test will create a CRITICAL
message about the unencrypted Livestatus TCP configuration in this
situation.
Technical details:
<ul>
<li>For new sites Livestatus via TCP is encrypted by default. Existing sites
which already have Livestatus via TCP enabled during the update keep the
communication unencrypted for compatibility reasons. This is managed using
the new 'omd config' option LIVESTATUS_TCP_TLS. This setting can also
be managed through the "Global Settings > Site Management".</li>
<li>During update or site creation a site local CA certificate is created
to manage the sites local certificates.</li>
<li>The site local certificate is created automatically during update or
site creation.</li>
<li>The sites local CA and certificates are stored in 'etc/ssl'. The CA
certificate is always located at 'etc/ssl/ca.pem'.</li>
<li>The keys are 2048 bit RSA keys and the certificates are signed using
SHA512.</li>
<li>The CA certificate is valid for 10 years, the site certificates are
valid for 3 years.</li>
<li>Check_MK / OMD code may use 'omdlib.certs.SiteLocalCA(site_id)' to
use the local CA</li>
<li>stunnel is introduced as site internal daemon that serves the TLS
wrapped socket once it has been enabled through 'omd config'.
</ul>
ID: 7058
Title: netscaler_vserver: the check is now cluster aware
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
The check can now be used together with Check_MK clusters.
The cluster behaviour can be defined via the corresponding
WATO rule.
ID: 7057
Title: Allow "coding" comment in notification scripts
Component: Notifications
Level: 1
Class: Bug fix
Version: 1.6.0i1
Notification scripts can contain the name of the notification
script as a comment after the shebang and the optional encoding
comment. When the encoding comment contained only the word
"coding" but not "encoding" the encoding comment was accidentally
used as the title of the notification script. Now the regular
expression from https://docs.python.org/2.7/reference/lexical_analysis.html
is used to recognize encoding comments. Therefore, "coding" and
"encoding" can now be used.
ID: 7080
Title: Management board: Continue when firmware information can not be fetched
Component: Core & setup
Level: 1
Class: Bug fix
Version: 1.6.0i1
The management board monitoring currently tries to fetch two types of information
from the boards: Sensor states and information about the firmware version. In
case the later could not be fetched the processing of the management board data
was terminated. This has now been changed to continue with the data that could
be fetched.
ID: 6940
Title: Fix OnlyFrom entry in check_mk agent section
Component: agents
Level: 1
Class: Bug fix
Version: 1.6.0i1
Previously, the OnlyFrom entry, that represents the list of
only-from IP entries within the xinetd-configuration,
rendered empty for baked agents.
The cause for this was that the agent was looking for
the service name "check_mk", that only is used by the
raw agent.
The agent is now looking for the right service name set
from the agent bakery, i.e. "check-mk-agent" or a user-specified
name coming from the "name of agent packages" rule.
ID: 7136
Title: mk_jolokia: connection timeout is now configurable
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
Previously the connection timeout was hardcoded to 1 second, based on the assumption that the jolokia server is most likely the local host.
This assumption has been dropped, and the timeout can now be configured using the agent bakery or by adding (e.g.) "timeout=23.0" to your configuration file.
ID: 7137
Title: mem.win: Titles of rule are more consistent
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0i1
Some of the titles and rules still referred to the commit charge as 'page file'.