Checkmk werks level2 September 2016

checkmk-werks-lvl2@lists.checkmk.com

3 participants
5 discussions

Check_MK Werk 3648: Fixed log file parsing of host states

by Sven Panne

ID: 3648 Title: Fixed log file parsing of host states Component: Core & Setup Level: 2 Class: Bug Fix Version: 1.4.0i2 When parsing log/history files, the host state 'DOWN' was incorrectly handled. This has been fixed.

8 years

Check_MK Werk 3737: Fixed slow activation of changes due to loss of IP address cache

by Mathias Kettner

ID: 3737 Title: Fixed slow activation of changes due to loss of IP address cache Component: Core & Setup Level: 2 Class: Bug Fix Version: 1.4.0i1 In some situations Check_MK would loose the cached IP addresses in <tt>var/check_mk/ipaddresses.cache</tt>. The results in the next activation of changes being very slow - depending on your DNS. The problem seems to happen (especially) if you have activated periodic service discovery with automatic activation of changes. This has been fixed.

8 years

Check_MK Werk 3887: Event contact groups are now handled in notifications (optionally)

by Lars Michelsen

ID: 3887 Title: Event contact groups are now handled in notifications (optionally) Component: Event Console Level: 2 Class: New Feature Version: 1.4.0i1 Previously you could already configure contact groups in Event Console rules, but those groups were only used to control the visibility of the events in the GUI. Now these groups can be used to control the visibility and also make them relevant for the notifications created by the Event Console. Besides adding the groups to the rule, you can configure whether or not to add the contact groups to the notifications and also configure the precedence of the groups in case there are host contact groups configured and event contact groups in the rule. Existing rules are treated as before. The contact groups of the rule will not be added to the notifications until you open the rule, tick the checkbox and save the rule again.

8 years

Check_MK Werk 3861: Introduced open event limit mechanism for protecting against message storms

by Lars Michelsen

ID: 3861 Title: Introduced open event limit mechanism for protecting against message storms Component: Event Console Level: 3 Class: New Feature Version: 1.4.0i1 The Event Console has been extended to be able to protect agains message storms which can either result in too high load and also in out of memory situations. Because there can be multiple kind of message storms like one device which sends a lot of messages or many different devices sending equal messages, we introduced different limits to match them. There are the following limits: <ul> <li>Limit by host: You can limit the number of open events created by a single host . This is meant to prevent you from message storms created by one device. Once the limit is reached, the Event Console will block all future incoming messages sent by this host until the number of open events has been reduced to be below this limit. In the moment the limit is reached, the Event Console will notify the configured contacts of the host.</li> <li>Limit by rule: You can limit the number of open events created by a single rule here. This is meant to prevent you from too generous rules creating a lot of events. Once the limit is reached, the Event Console will stop the rule creating new open events until the number of open events has been reduced to be below this limit. In the moment the limit is reached, the Event Console will notify the configured contacts of the rule or create a notification with empty contact information.</li> <li>Overall limit: To protect you against a continously growing list of open events created by different hosts or rules, you can configure this overall limit of open events. All currently open events are counted and once the limit is reached, no further events will be opened which means that new incoming messages will be dropped. In the moment the limit is reached, the Event Console will create a notification with empty contact information. </li> </ul> Each of those limits can be configured to different values. By default the limit is set to 1000 for the host and rule based limit and 10000 for the overall limit. Please check carefully whether or not these defaults are OK for you. But they should be way enough for most environments since you really should never have so many open events in the Event Console open. But if you need to change those limits, you can change them in the global settings of the Event Console to fit your needs. Additionally, you can configure the actions the Event Console should perform once the limit is reached instead of the overflow event and notification creation as described above. Another action is for example delete the oldest event (of a host, rule or overall).

8 years

Check_MK Werk 3855: Fixed possible command injection by privileged WATO users

by Lars Michelsen

ID: 3855 Title: Fixed possible command injection by privileged WATO users Component: WATO Level: 2 Class: Security Fix Version: 1.4.0i1 In all previous 1.2.8 versions authenticated and privileged WATO users, the ones which are able to add or edit hosts, were able to inject shell commands to Check_MK which are then executed in the context of the monitoring site user. The user was able to configure a host address in a specific format to inject such shell commands to the configuration. Once the configuration was activated and loaded into the monitoring core, the command was executed in context of the monitoring site user in the moment a parent scan was started for that host. Thanks for analyzing and reporting this issue to Christian Fünfhaus!

8 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 September 2016