Checkmk werks level2

checkmk-werks-lvl2@lists.checkmk.com

1 participants
1349 discussions

Checkmk Werk 13600: Custom Windows agent port was not respected during update

by Sergey Kipnis

ID: 13600 Title: Custom Windows agent port was not respected during update Component: Checks & agents Level: 2 Class: Bug fix Version: 2.1.0i1 Previously, during <tt>update</tt> Windows agent always opened default port, 6556, in the firewall, even if the TCP port had been changed by WATO With this release the problem had been eliminated.

2 years, 7 months

Checkmk Werk 13633: The password store is now storing passwords obfuscated

by Lars Michelsen

ID: 13633 Title: The password store is now storing passwords obfuscated Component: Core & setup Level: 2 Class: New feature Version: 2.1.0i1 The password stores primary use is to centralize stored credentials. Instead of spreading the credentials in the whole configuration, we have this as a central place for sensitive information. We are a monitoring system. We definitely need credentials in clear text to contact remote some systems all the time. And we also need to be able do this after restarting the whole system without user interaction (for providing some kind of master key). This means the secrets need to be available to the site user on disk in clear text. To underline this fact, we kept the password store file in clear text on disk for a long time. This approach made the situation clearly visible to everyone. We are faced with the requirement that no credential shall be stored in clear text on disk, they need to be encrypted. We'd love to have that too. But since securing is not possible, we are now "obfuscating". In fact it's encryption, but we are doing it with a secret that is stored in the same context as the password store itself - this is why we call it obfuscation. The best we can do in this case. With the development of Checkmk 2.2 we will evaluate the usage of HSMs as well as vault solutions in the future which may be helpful in some use cases. The password store file <tt>var/check_mk/stored_passwords</tt> is now encrypted using the new password store key (<tt>etc/password_store.secret</tt>). This key is created during update to Checkmk 2.1 automatically. You are free to replace the secret with what ever text you want. But please note that the password store needs to be initialized again after changing the secret. All existing passwords stores will be obfuscated automatically during update to Checkmk 2.1.

2 years, 7 months

Checkmk Werk 13659: New SMS notification script for IP modems

by Ronny Bruska

ID: 13659 Title: New SMS notification script for IP modems Component: Notifications Level: 2 Class: New feature Version: 2.1.0i1 Until now, it was only possible to use SMS modems that support smstools. With this werk a new notification option "SMS (using modem API)" was added as notification method. The script uses the API of IP modems, currenly supporting the model "Teltonika TRB140" and outputs SMS in the same format as the notification method "SMS (using smstools)".

2 years, 7 months

Checkmk Werk 13610: Notification spooler connections can now be encrypted

by Tom Baerwinkel

ID: 13610 Title: Notification spooler connections can now be encrypted Component: Notifications Level: 2 Class: New feature Version: 2.1.0i1 Notification spooler (mknotifyd) connections communicated via a plain text procotol since its introduction. This is ok for local connections or in secure networks. To secure the connections users had the choice to use TLS (e.g. via stunnel), SSH, VPN or another solution that encrypts the communication in their local setup. To improve the security for all users it is now possible to configure the encryption via TLS directly in Checkmk. An analyze configuration test will create a CRITICAL message about unencrypted mknotifyd connections. After an update from Checkmk version 2.0 the encryption setting for existing, outgoing connections is "Use unverified TLS encryption, fall back to plain text" and "Plain text communication" for existing, incoming connections. This way mknotifyd connections remain functional after an update and may be migrated gradually to encrypted connections in larger setups. To encrypt mknotifyd connections between two sites, you have to update both sites to Checkmk version 2.1. Afterwards you have to adapt the "Notification spooler configuration" in the "Global settings". For incoming and outgoing connections you have to set the "Encryption" to "Encrypt communication with TLS". After an activate changes the communication is encrypted. For new incoming and ougoing connections "Encrypt communication with TLS" is the default. Internally, mknotifyd connections use the internal CA that is used by livestatus as well. To support outgoing connections from a remote site to a central site, the CA of the central site is added to the "Trusted certificate authorities for SSL" in the "Global settings" for new sites and during an update from version 2.0.

2 years, 8 months

Checkmk Werk 13325: Two-factor authentication via FIDO2/WebAuthn

by Lars Michelsen

ID: 13325 Title: Two-factor authentication via FIDO2/WebAuthn Component: Multisite Level: 2 Class: New feature Version: 2.1.0i1 With this change users of the Checkmk user interface can now configure Checkmk to ask for a second factor during user authentication. The new two-factor authentication is based on FIDO2/WebAuthn. You can use authenticators such as the YubiKey, a USB token, a smart phone, Apple’s Touch ID, and Windows Hello. To enable the new feature, login to the GUI and open the "User" mega menu on the bottom left of the screen. Then select "Two-factor authentication". On the opened page, you first need to click on "Add credential". Once you click that, your browser will ask you to activate your authenticator. Once done, the registration with your user account should be complete and a new registered credential is displayed. With this step you have enabled the two-factor authentication for your user account. Future logins will only be possible with the activated authenticator. If you don't have your authenticator at hand, you can use backup codes. It is recommended to generate these backup codes right away by clicking on "Regenerate backup codes". The resulting page will show you a list of 10 backup codes. Store them in a save place. Administrators can see that a user has the two-factor authentication enabled in the users list of the Setup. The Authentication column displays "Password (+2FA)" for these users. Admins can disable two-factor authentication for users to help them in case they don't have access to their second factor. This can be done via "Setup > Users > Edit user > Disable two-factor authentication". Please note that the WebAuthn standard makes this feature only usable in case you access the GUI using HTTPS. The WebAuthn two-factor authentication is also restrictive on the type of host address you use to access the GUI. It will be used as relying party identifier (https://www.w3.org/TR/webauthn-2/#relying-party-identifier) and has to be a valid domain string (https://url.spec.whatwg.org/#valid-domain-string). You will have to either use a simple host name or a full qualified domain name. Please note that you need to be consistent in the domain you use for the two-factor authentication to work.

2 years, 8 months

Checkmk Werk 13091: Fixed event console time filters

by Sven Panne

ID: 13091 Title: Fixed event console time filters Component: Event Console Level: 2 Class: Bug fix Version: 2.1.0i1 The event console contains logic to quickly skip history files which are not relevant for a given query. This logic was broken from day one, often resulting in superfluous processing of irrelevant history files, which in turn could lead to e.g. timeouts in the GUI. This has been fixed now.

2 years, 8 months

Checkmk Werk 13334: Drop support for Internet Explorer 11 (IE11)

by Tom Baerwinkel

ID: 13334 Title: Drop support for Internet Explorer 11 (IE11) Component: Multisite Level: 2 Class: New feature Version: 2.1.0i1 The support for IE11 is dropped beginning with version 2.1 of Checkmk. Since some of our dependencies already dropped the support and we don't want to ship old/outdated versions we are dropping support for IE11 as well, prior to the official end of life at 2022-06-15.

2 years, 9 months

Checkmk Werk 13320: omd update: Add version compatibility barrier

by Lars Michelsen

ID: 13320 Title: omd update: Add version compatibility barrier Component: Site Management Level: 2 Class: New feature Version: 2.1.0i1 For some time now, we have been recommending that, in the case of major updates over several versions, the updates to the individual versions should be made in stages, e.g. in the case of a migration from 1.5 to 2.0, the version 1.5 should first be updated to 1.6 and then to 2.0. Furthermore, <tt>omd update</tt> does support downgrades to older major versions. However, a lot of manual adjustments are necessary to make the configuration and runtime data of the site compatible to an older major version again. So we don't recommend to do this step either. This change now introduces a hard barrier in the <tt>omd update</tt> command, which forces the above recommendations. Examples: <ul> <li>1.6 to 2.0 is allowed</li> <li>1.6 to 2.1 is blocked</li> <li>2.0 to 2.1 is allowed</li> <li>2.0 to 2.2 is blocked</li> <li>2.0 to 3.0 is allowed</li> <li>2.1 to 3.1 is allowed</li> </ul> You can disable this new check by using the <tt>omd -f update [site]</tt> command. However, sites that have been updated this way will no longer be supported by us.

2 years, 9 months

Checkmk Werk 13076: REST API missing and duplicated hosts problem

by Christoph Rauch

ID: 13076 Title: REST API missing and duplicated hosts problem Component: Core & setup Level: 3 Class: Bug fix Version: 2.1.0i1 This Werk fixes a very severe data inconsistency problem in the REST API. Previously, only the actual working code of the individual endpoints were locked, but the validation logic which gets executed before the endpoints didn't fall into that locking scope. This logic could then trigger a cache load which could lead to data inconsistency and even data loss when using the REST API highly concurrently. The observed effects were: * when moving hosts concurrently, some hosts may disappear * when moving hosts concurrently, some hosts may end up in multiple folders * when editing hosts, spurious 421 or 401 responses could appear The locks have now been modified to encompass also the validation logic. This Werk fixes the afore mentioned problems. There are no further actions to be taken.

2 years, 10 months

Checkmk Werk 13331: Performance improvements for the mknotifyd

by Tom Baerwinkel

ID: 13331 Title: Performance improvements for the mknotifyd Component: Notifications Level: 2 Class: Bug fix Version: 2.1.0i1 This werk fixes some performance regressions in the mknotifyd and can increase (depending on the setup) the throughput of the mknotifyd. The changes are most benificial if you use notification plugins with a short running time or if you forward notifications from remote to central sites. The fixed regressions are: In distributed setups forwarded messages were always processed in one subprocess before the actual notification plugins were executed. I.e. even if you used the option "Maximum concurrent executions" for a notification plugin, it may not have the desired effect if the processing of forwarded messages was the limiting factor. You can now use the option "Maximum concurrent executions for forwarded messages" in the "notification spooler configuration" of the "global settings" to configure the number of processes. Ideally, the number of processes should roughly match the concurrent executions of the notification plugins of the incoming messages. If no value is specified, a default of 1 is used. Note that higher values lead to a higher CPU load. If e.g. a value of 2 is used and a notification plugin uses 2 concurrent executions, 4 subprocesses can be started simultaneously. The mknotifyd polls for new data with a timeout of 1s. Previously, output of executed notification plugins was not recognized in the poll. I.e. if no data was present on a connection or no forwarding was used, the timeout of 1s was always hit. Now, the mknotifyd recignizes new output of notification plugins and the poll exits before the 1s timeout is hit. Incoming connections used blocking sockets and outgoing connections could occasionally end up with a blocking socket. This degraded the performance of the mknotifyd if a lot of notifications had to be sent to a remote site and the TCP queue was already full. It also may lead to occasional disconnects if heartbeats were missed due to a blocking call and could in the worst case lead to a deadlock if two sites are in a blocking call. If a connection had a lot of outgoing data the mknotifyd only sent data and did not read data from the socket which could leat to missed heartbeats and disconnects as well. Before this werk all spoolfiles in the spool and deferred directory were always processed. If a lot of spoolfiles were present in these directories, this could lead to up to 2s spent processing these directories per cycle. Finally, this werk increases the amount of data collected per cycle from a connection. This resolves the issue of TCP queues when a lot of notifications had to be forwarded to a remote site.

2 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2