Checkmk werks level1 February 2019

checkmk-werks-lvl1@lists.checkmk.com

12 participants
71 discussions

Check_MK Werk 7082: Fixed "omd create" when fstab has 0 bytes

by Lars Michelsen

ID: 7082 Title: Fixed "omd create" when fstab has 0 bytes Component: Site Management Level: 1 Class: Bug fix Version: 1.6.0i1 The "omd create" command failed with a "IndexError: string index out of range" in case a /etc/fstab file existed but was empty. While regular systems most likely have entries in there, this can often happen for containers.

5 years, 7 months

Check_MK Werk 7140: postgres_instance: go to state CRIT if psql has been stopped

by Moritz Kiemer

ID: 7140 Title: postgres_instance: go to state CRIT if psql has been stopped Component: Checks & agents Level: 1 Class: Bug fix Version: 1.6.0i1

5 years, 7 months

Check_MK Werk 7032: logwatch: Optional shared log pointer for several ip addresses

by Florian Kromer

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)".

5 years, 7 months

Check_MK Werk 7017: Livestatus via TCP can now be encrypted

by Lars Michelsen

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>

5 years, 7 months

Check_MK Werk 7058: netscaler_vserver: the check is now cluster aware

by Tom Baerwinkel

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.

5 years, 7 months

Check_MK Werk 7091: brocade_optical: Fixed KeyError caused by incomplete agent data

by Simon Betz

ID: 7091 Title: brocade_optical: Fixed KeyError caused by incomplete agent data Component: Checks & agents Level: 1 Class: Bug fix Version: 1.6.0i1

5 years, 7 months

Check_MK Werk 7057: Allow "coding" comment in notification scripts

by Tom Baerwinkel

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.

5 years, 7 months

Check_MK Werk 7139: cisco_ip_sla: Don't crash upon vanished IP SLA

by Moritz Kiemer

ID: 7139 Title: cisco_ip_sla: Don't crash upon vanished IP SLA Component: Checks & agents Level: 1 Class: Bug fix Version: 1.6.0i1

5 years, 7 months

Check_MK Werk 7080: Management board: Continue when firmware information can not be fetched

by Lars Michelsen

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.

5 years, 7 months

Check_MK Werk 6940: Fix OnlyFrom entry in check_mk agent section

by Andreas Umbreit

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.

5 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 February 2019