ID: 7174
Title: Apache: Disable TRACE and OPTIONS methods
Component: Site Management
Level: 1
Class: Security fix
Version: 1.6.0i1
The HTTP method TRACE makes some kind of reflection attacks possible and is not
used at all. It has been enabled for the site apache using the option
<tt>TraceEnable Off</tt> in etc/apache/conf.d/security.conf.
The similar TRACK method is not supported by the site apache at all, so it does
not have to be disabled.
A lot of guides recommend to also disable the OPTIONS method for production
servers. This HTTP method basically reports which HTTP Methods that are
allowed on the web server. In reality, this is rarely used for legitimate
purposes, but it may grant a potential attacker a little bit of help and it
can be considered a shortcut to find another hole. For this reason we also
disabled the OPTIONS method.
ID: 6760
Title: gude_temo, gude_humidity: Added support for Gude Sensor Box 7213
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
Check_MK is now able to monitor also the Gude Sensor Box 7213 beginning with
this werk release.
ID: 6706
Title: BI availability no longer creates N/A periods if an element within the BI was not known at the time
Component: Multisite
Level: 1
Class: Bug fix
Version: 1.6.0i1
WK:4202 introduced some special handling for BI aggregations:
<tt>
When computing the availability of a BI aggregation for a time range during which new hosts or services were added to the monitoring the state of these objects would be displayed as PEND before point of time they were added. But this is not correct. These objects where not pending but simply not yet existing and thus not contained in the aggregation tree at all at that time.
</tt>
This introduced an side effect, so that some availability reports of an aggregation still shows N/A even when the
user has explicitly switched off <tt>Include unmonitored time</tt>.
ID: 7035
Title: lnx_thermal: Fixed crash caused to unusual outputs
Component: Checks & agents
Level: 1
Class: Bug fix
Version: 1.6.0i1
Previously the check crashed in case the agent delivered thermal zone data with
various degrees of details. This werk takes into account that these
heterogeneous formats can occur and prevents the check additionally to crash
due to invalid or currently unknown data formats.
CMK-1506
Commit ab8068a5a45
ID: 7090
Title: Automatically lock users after 10 subsequent logon failures
Component: Multisite
Level: 1
Class: Security fix
Version: 1.6.0i1
Sites created with Check_MK 1.6 will be configured to automatically lock user
accounts that fail to log in 10 times in a row. Existing sites will not be
affected by this change.
Check_MK already had the option to configure this feature for a long time. It
can be customized using the global setting "Lock user accounts after N logon
failures". If you have configured this in your setup, your setting is left
untouched.
To unlock automatically locked users, you need to login as administrative user
and disable the option "Disable password" for this user. In case your
administrative account was locked out, you will have to reset the password
of your account (using <tt>htpasswd -m ~/etc/htpasswd [user-id]</tt>).
ID: 7059
Title: Add an option to reduce the logging in the notify.log
Component: Notifications
Level: 1
Class: New feature
Version: 1.6.0i1
By default two lines are added for every notification rule in the
notify.log. They contain a short description of the rule and
information why the rule does or does not match. In setups with
a large number of notification rules this may result in up to
hundreds of lines in the notify.log for every incoming raw
notification. To optionally reduce the amount of logging this
werk introduces a new log level that only adds lines for matching
rules. The new option can be selected in the Global Settings under
"Notification log level". Be aware that with this option the
notify.log does not conain information about rules which do not
match which makes it much harder to analyze why a certain rule
did not match retrospectively.
ID: 7145
Title: jolokia_info: Also discover if server is not responding
Component: Checks & agents
Level: 1
Class: New feature
Version: 1.6.0i1
Every instance that is contacted has been explicitly configured by the user.
We can assume they want to monitor it, even if an error occurs at the time
of discovery.
ID: 7087
Title: Extension packages can now provide individual localizations
Component: Multisite
Level: 1
Class: New feature
Version: 1.6.0i1
Extension packages (MKPs) can now ship their own localization files in addition
to the standard localization file. With this change it is possible to split
different localization parts into separate files.
The GUI now recognizes the following localization file paths:
C+:
share/check_mk/locale/[LANG]/LC_MESSAGES/multisite.mo - Builtin, shipped with Check_MK.
local/share/check_mk/locale/[LANG]/LC_MESSAGES/multisite.mo - Site specific override, extension of builtin localization
local/share/check_mk/locale/packages/[PKG_NAME]/[LANG]/LC_MESSAGES/multisite.mo - Extension localization
C-:
The GUI searches these localization files from bottom to top when it searches for
a text to be localized.
ID: 7086
Title: Localizations now extend shipped localizations
Component: Multisite
Level: 1
Class: New feature
Version: 1.6.0i1
Locally installed localization files (local/share/check_mk/locale) may
now extend the builtin localizations instead of overriding them.
In previous versions the local locale file had to contain all texts that
we ship with our standard localizations, for example the german localization
in case one wanted to extend / change a single text.
Now both, the builtin and local localization files are loaded. All texts
are searched in the local file and looked up in the builtin file as fallback
in case the text can not be found in the local file.
ID: 7089
Title: Docker container: Simplified update procedure
Component: Site Management
Level: 2
Class: New feature
Version: 1.6.0i1
The update procedure of the official Check_MK containers was a bit complicated
compared to the update procedure on other servers. The root cause for this was
that the update always required both, the old and the new versions, while the
containers are only allowed to have one version installed. This made it
necessary to create an intermediate container for the update.
The werk #7088 made it possible to perform an update without having access to
the old version. Once we have this functionality it is now possible to replace
one container with a another container. In case the version has changed, the
container is performing the update during startup of the new container.