Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 discussions

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.

7 years, 12 months

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

Check_MK Werk 3844: Fixed validation of host IPv4, IPv6 and management host address attributes

by Lars Michelsen

ID: 3844 Title: Fixed validation of host IPv4, IPv6 and management host address attributes Component: WATO Level: 2 Class: Bug Fix Version: 1.4.0i1 The values inserted in the WATO host address fields were not validated strictly enough. This has now been changed so that the IPv4 address field allows IPv4 addresses and host- or DNS names and the IPv6 address field allos IPv6 address and host- or DNS names.

8 years

Check_MK Werk 3646: Fixed Livestatus output formats

by Sven Panne

ID: 3646 Title: Fixed Livestatus output formats Component: Livestatus Level: 2 Class: Bug Fix Version: 1.4.0i1 All Livestatus output formats handle special characters correctly now, including non-ASCII characters, quotes, and backslashes. There is one exception: To avoid compatibility problems, the default <tt>csv</tt> format has been left unchanged and is still broken. A new format <tt>CSV</tt> (note the uppercase) has been added which is fully functional and therefore ignores the <tt>Separators:</tt> header/hack. Furthermore, a new <tt>python3</tt> format has been added to handle the changed default string type in Python 3, where bytestrings and Unicode strings have basically swapped their roles.

8 years, 1 month

Check_MK Werk 3785: WATO rulesets: now able to set a negate option for services and items

by Andreas Boesl

ID: 3785 Title: WATO rulesets: now able to set a negate option for services and items Component: WATO Level: 2 Class: New Feature Version: 1.4.0i1 You can now set a <i>negate</i> checkbox for services, just like the negate host checkbox.

8 years, 1 month

Check_MK Werk 3752: Fixed loosing site configuration when editing hosts in WATO slave sites

by Lars Michelsen

ID: 3752 Title: Fixed loosing site configuration when editing hosts in WATO slave sites Component: WATO Level: 2 Class: Bug Fix Version: 1.2.8p9 When having a distributed setup where WATO is enabled on slaves and hosts were editied, the hosts in the folder of that host were resetting the site attribute so that they are being monitored by the remote site, even when they were configured to be monitored on another site. The slave sites are now checking for the configured unknown sites and warning you about that fact. To override the configured site attributes, you have to explicitly change the value of the site attribute.

8 years, 1 month

Check_MK Werk 3726: Web API: Fixed default output format - using JSON as intended

by Lars Michelsen

ID: 3726 Title: Web API: Fixed default output format - using JSON as intended Component: WATO Level: 2 Class: Bug Fix Version: 1.4.0i1 The WATO Web API was using Python as default output format since version 1.2.8b8 and commit 36142e6d, which was not intended. The Web API is able to output JSON and Python formated data, which can be toggled using the variable <tt>output_format=json</tt> or <tt>output_format=python</tt>. The default has now been changed back to be JSON. In case you created scripts against this API since 1.2.8b8, did not use a JSON parser to load the data and used something like <tt>eval()</tt> in Python instead, you will have to change your scripts. You can either add the variable <tt>output_format=python</tt> or replace your <tt>eval()</tt> with <tt>json.loads()</tt> in Python.

8 years, 1 month

Check_MK Werk 3720: The Event Console views are now supporting distributed setups

by Lars Michelsen

ID: 3720 Title: The Event Console views are now supporting distributed setups Component: Event Console Level: 2 Class: New Feature Version: 1.4.0i1 The Event Console was not really supporting distributed setups in the past. In case you have a setup of multiple sites you always had to decide whether or not to setup a single, central, EC or one EC per site and how to handle and configure monitoring and notifications. The Event Console can now be integrated into distributed setups more easily. The standard setup should now be a single Event Console per site which receives the events of all hosts monitoringed with this site. In case you have a central view site, the Event Console views show up the events of all Event Console instances configured in the central site. You can manage all the events of the remote Event Console just like managing hosts and services of the remote site.

8 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2