Update auf Version 2.2.0

Wie vor jedem Update einer produktiven Software sollten Sie auch vor dem von Checkmk die Aktualität Ihrer Backups prüfen.

Betrifft Sie das? Ja.

Was müssen Sie tun? Wenn Sie Ihre Backups automatisiert über Setup > Maintenance > Backups erstellen, prüfen Sie dort, ob die letzten Backup-Aufträge fehlerfrei durchgelaufen sind.

Weitere Informationen finden Sie in den Artikeln zu Backups und zum Thema Instanzen sichern und wiederherstellen.

Die Checkmk-Editionsfamilie hat Zuwachs bekommen mit der brandneuen Checkmk Cloud Edition. Was diese zu bieten hat, können Sie im Artikel zur Cloud Edition nachlesen. Dafür heißt es Abschied nehmen von der Checkmk Enterprise Free Edition, die es in der 2.2.0 nicht mehr gibt.

Die Möglichkeiten der Free Edition leben aber weiter in der Cloud Edition: das zeitlich begrenzte Ausprobieren und das dauerhafte Nutzen einer der kommerziellen Editionen in kleinem Rahmen. Eine Änderung gibt es allerdings bei der Limitierung zur dauerhaften Nutzung: Während Sie in der Free Edition Edition bis zu 25 Hosts in einer Instanz überwachen können, sind es in der Cloud Edition 750 Services in einer Instanz.

Betrifft Sie das? Falls Sie in der Version 2.1.0 die Free Edition nutzen, müssen Sie sich in der 2.2.0 eine neue Edition suchen. Eine Kurzvorstellung der Checkmk-Editionen finden Sie hier.

Was müssen Sie tun? Sollte in Ihrem Fall die Limitierung auf 25 Hosts der Free Edition ausreichend gewesen sein, die 750 kostenlosen Services der Cloud Edition aber nicht, so können Sie entweder eine Subskription erwerben und das Upgrade auf eine der kommerziellen Editionen durchführen — oder Sie entscheiden sich für das Downgrade auf die kostenlose Raw Edition. Führen Sie das Upgrade oder das Downgrade der Edition vor dem Update auf die Version 2.2.0 durch. Beachten Sie die dabei auch die Hinweise im Artikel zu Updates und Upgrades, insbesondere beim Downgrade auf die Raw Edition.

Sollten Sie mit der neuen Grenze von 750 Services keine Probleme haben, dann bietet sich der Upgrade der Free Edition auf die neue Cloud Edition an, so wie er weiter unten beschrieben ist.

In der Checkmk Version 2.2.0 werden einige veraltete Distributionen nicht mehr unterstützt werden.

Betrifft Sie das? Das betrifft Sie, wenn auf Ihrem Checkmk-Server eine der folgenden – in der 2.1.0 noch unterstützten – Linux-Distributionen installiert ist:

Was müssen Sie tun? Führen Sie vor dem Update von Checkmk zuerst ein Versions-Upgrade der Linux-Distribution durch. Achten Sie darauf, dass die Zielversion der Linux-Distribution von Checkmk 2.1.0 und 2.2.0 unterstützt wird. Welche Linux-Distributionsversionen Checkmk unterstützt, erfahren Sie in der Update-Matrix für 2.2.0 und auf der Download-Seite nachdem Sie die Checkmk-Version und Ihre Linux-Distribution ausgewählt haben.

Neuere Ubuntu STS-Versionen erhalten nicht mehr über den gesamten Produkt-Lifecycle von Checkmk 2.2.0 Unterstützung. Nutzern dieser Versionen geben wir jedoch die Möglichkeit, nahtlos auf die nächste LTS 24.04 zu aktualisieren. Details können Sie in der Richtlinie zur Betriebssystemunterstützung (OS Support Policy) nachlesen.

Checkmk 2.2.0 nutzt neue JavaScript-Funktionen, die in älteren Browsern nicht zur Verfügung stehen. Welche Browser in welchen Versionen unterstützt werden, steht in den Release notes.

Betrifft Sie das? In der Regel werden Sie auf Desktop-Systemen automatische Updates auf die neueste Version aktiviert haben.

Was müssen Sie tun? Prüfen Sie die verwendete Browser-Version und installieren Sie gegebenenfalls einen aktuelleren Browser. Wenn Sie für die Anzeige von Dashboards Single Board Computer, Smart TVs oder Digital Signage Lösungen verwenden, auf deren Systembrowser Sie keinen Einfluss haben, testen Sie vor dem Update, ob benötigte Dashboards korrekt angezeigt werden. Kontaktieren Sie gegebenenfalls den Hardware-Hersteller für Updates.

In Checkmk 2.2.0 unterstützt der Linux-Agent nicht länger Python 2.6 für Plugins.

Betrifft Sie das? Nur, wenn bei Ihnen sehr alte Linux-Systeme im Einsatz sind (Python 2.6 ist von Oktober 2008 und wurde ab Juli 2010 von Python 2.7 abgelöst) und Sie auf diesen in Python geschriebene Agentenplugins nutzen.

Was müssen Sie tun? Identifizieren Sie die betroffenen Systeme und aktualisieren Sie die installierten Agenten auf die letzte verfügbare Patch-Version der 2.1.0. Falls automatische Agenten-Updates konfiguriert sind, deaktivieren Sie diese vor dem Update der Checkmk-Instanz. Sie können dann die einzelnen Komponenten Agentenskript, Plugins und lokale Checks – nach Kompatibilitätstests – manuell aktualisieren.

In Checkmk 2.2.0 unterstützt der Windows-Agent nicht länger Windows 6.0 (Vista und Server 2008 R1). Auf betroffenen Systemen kann der Agent von 2.1.0 aber weiter genutzt werden.

Betrifft Sie das? Nur, wenn bei Ihnen diese antiquierten Windows-Systeme (Support-Ende 11. April 2017 respektive 14. Januar 2020) noch im Einsatz sind.

Was müssen Sie tun? Identifizieren Sie die betroffenen Systeme und aktualisieren Sie die installierten Agenten auf die letzte verfügbare Patch-Version der 2.1.0. Falls automatische Agenten-Updates konfiguriert sind, deaktivieren Sie diese vor dem Update der Checkmk-Instanz.

Bakery Plugins binden Funktionen in die Agentenpakete der Agentenbäckerei (Agent Bakery) ein. Mit Werk #14648 wird in der Version 2.2.0 die Unterstützung für alte Bakery Plugins eingestellt. Dabei handelt es sich um benutzerdefinierte Plugins, die in der Version 1.6.0 und früher verwendet wurden, und noch nicht auf die in der 2.0.0 eingeführte Bakery-API migriert wurden.

Betrifft Sie das? Die Agentenbäckerei und damit auch die Bakery-API sind nur für Benutzer der kommerziellen Editionen relevant.

Vor der Einführung der Bakery-API wurden die Bakery Plugins im Instanzverzeichnis unter ~/local/share/check_mk/agents/bakery/ abgelegt. Um festzustellen, ob bei Ihnen alte Plugins vorhanden sind, können Sie hier nach der Zeichenkette bakery_info[ suchen.

Seit der 2.0.0 zeigt Checkmk außerdem beim Backen von Agentenpaketen mit alten Bakery Plugins eine Warnung an. Diese können Sie sich auch nachträglich anzeigen lassen unter Setup > Maintenance > Background jobs im Abschnitt Agent baking. Beim Backen per Kommandozeile mit cmk -A erfolgt die Warnung als Befehlsausgabe.

Was müssen Sie tun? Migrieren Sie alte Bakery Plugins auf die Bakery-API. Sie finden eine Einführung in die Nutzung der API im Artikel zur Bakery-API.

Checkmk 2.2.0 aktualisiert Python von 3.10 auf 3.11. Dies führt zu einer strengeren Interpretation regulärer Ausdrücke. Modifiers als „Inline Flags“ sind seit Python 3.6 als deprecated markiert und führten bislang beim Test im Python-Prompt zu einer Warnung. In Python 3.11 sind sie nur am Anfang eines regulären Ausdrucks zulässig.

Betrifft Sie das? Es betrifft Sie mit hoher Wahrscheinlichkeit, wenn Sie den Modifier (?i) benutzen, um anzugeben, dass der nachfolgende reguläre Ausdruck ohne Berücksichtigung von Groß- und Kleinschreibung ausgewertet werden soll. Da Checkmk aus Performance-Gründen an einigen Stellen mehrere reguläre Ausdrücke zu einem einzigen kombiniert, kann diese Änderung auch alleine betrachtet valide reguläre Ausdrücke (Modifier am Anfang) betreffen.

Was müssen Sie tun? Identifizieren Sie alle regulären Ausdrücke, welche Inline Flags nutzen. Hierfür genügt es in der Regel, auf die Zeichenkette (? zu untersuchen, beispielsweise mit diesem Befehl:

Passen Sie die betroffenen regulären Ausdrücke an. Da Modifier weiterhin gültig sind, wenn ihr Anwendungsbereich angegeben wird, können Sie einen vorhandenen regulären Ausdruck

äquivalent umschreiben auf:

Die Aktualisierung von Python von 3.10 auf 3.11 betrifft auch in einer Instanz nachinstallierte Module. In vielen Fällen sind nachinstallierte Module mit Python 3.11 inkompatibel. Schlimmstenfalls überschreiben veraltete Module Funktionalität der von Checkmk mitgelieferten Module.

Betrifft Sie das? Dies betrifft Sie nur, wenn Sie für selbst geschriebene oder aus der Exchange bezogene Spezialagenten oder agentenbasierte Check-Plugins explizit Python-Module nachinstalliert haben. Wenn Sie unsicher sind, führen Sie die im folgenden Schritt beschriebene Prüfung durch.

Was müssen Sie tun? Finden Sie zunächst heraus, ob und – wenn ja –, welche Python-Module in der Instanz installiert sind. Suchen Sie hierfür die Verzeichnisse dist-info und egg-info:

Notieren Sie die installierten Module und deinstallieren Sie diese anschließend:

Wie Sie mit deinstallierten Python-Modulen nach dem Update umgehen, erfahren Sie weiter unten.

Ab Version 2.2.0 ist die Verwendung bestimmter Sonderzeichen in Benutzernamen nicht mehr zulässig. Mit ungültigen Benutzernamen ist ein Update auf die 2.2.0 nicht möglich, da omd update mit einem Fehler abbricht.

Benutzernamen in Checkmk dürfen nur Buchstaben (im Sinne der Unicode-Datenbank), Ziffern und die folgenden Sonderzeichen enthalten: Bindestrich (-), Unterstrich (_), Punkt (.), At-Zeichen (@) und Dollarzeichen ($). Als erstes Zeichen erlaubt ist nur ein Buchstabe, eine Ziffer, ein Unterstrich oder ein Dollarzeichen.

Betrifft Sie das? Beim Erstellen lokaler Benutzer über Setup > Users hat Checkmk schon seit längerem, d.h. bereits vor der Version 1.6.0, ungültige Benutzernamen abgelehnt. Es sind also, wenn überhaupt, nur Benutzernamen aus externen Verbindungen wie LDAP betroffen. Mit dem Werk #14393 warnt Sie Checkmk seit Version 2.1.0p20 bei ungültigen Benutzernamen — zum einen bei der Ausführung von omd update und zum anderen in der Benutzerverwaltung, die Sie über Setup > Users aufrufen können. Die Benutzernamen werden in der Spalte ID angezeigt und bei ungültigen Benutzernamen steht dort eine Warnung.

Was müssen Sie tun? Ändern Sie alle gefundenen ungültigen Benutzernamen an der Quelle.

Ab Version 2.2.0 ist die Verwendung von unsicheren und veralteten Hashfunktionen für Passwörter nicht mehr erlaubt. Dies betrifft die Hashfunktionen DES-Crypt, MD5-Crypt, Apr MD5-Crypt und SHA-256 Crypt. Obwohl letztere für Passwörter immer noch als sicher gilt, sollen die Passwort-Hashes aller Benutzer auf die modernere bcrypt Hashfunktion umgestellt werden.

Ein lokaler Benutzer, dessen Passwort mit einer der genannten, veralteten Hashfunktionen umgewandelt wurde, kann sich in der Version 2.2.0 nicht mehr anmelden.

Betrifft Sie das? Checkmk warnt Sie seit Version 2.1.0p16 (siehe Werk #14391), wenn unsichere Passwort-Hashes in der Datei ~/etc/htpasswd des Instanzverzeichnisses gefunden wurden. Bei der Ausführung von omd update wird eine Warnmeldung mit allen betroffenen (lokalen) Benutzernamen angezeigt. Benutzer aus externen Verbindungen wie LDAP sind nicht betroffen.

In der 2.1.0 wurde dann jeder betroffene Benutzer entweder nach der Anmeldung aufgefordert, ein neues Passwort zu wählen, oder der Hash wurde automatisch bei der Anmeldung im Hintergrund aktualisiert. Wenn sich ein Benutzer seitdem jedoch überhaupt nicht mehr angemeldet hat, ist es möglich, dass immer noch der veraltete Passwort-Hash verwendet wird. Dieser Benutzer wird sich nach dem Update auf die Version 2.2.0 nicht mehr anmelden können.

Was müssen Sie tun? Um den Zugang für einen betroffenen Benutzer wiederherzustellen, müssen Sie dessen Passwort manuell zurücksetzen. Ein neues Passwort vergeben Sie entweder in der Benutzerverwaltung über Setup > Users oder auf der Kommandozeile mit dem Befehl cmk-passwd <username>. Verwenden Sie für Passwortänderungen nur den Befehl cmk-passwd und nicht länger htpasswd, der aus der Apache-Installation kommt und ohne zusätzliche Optionen veraltete Passwort-Hashes erzeugen würde.

Bei Systemen, die vor langer Zeit einmal von Checkmk 1.4.0 auf 1.5.0 aktualisiert wurden, kann es vorkommen, dass nach dem Update von 2.1.0 auf 2.2.0 Benachrichtigungen nicht mehr funktionieren.

Betrifft Sie das? Das Problem tritt nur auf Installationen auf, die von Checkmk 1.4.0 auf 1.5.0 vor p8 aktualisiert wurden. Und dort nur bei Benutzern, die zwischenzeitlich nicht mehr bearbeitet und gespeichert wurden. Bei Checkmk-Installationen, die von Checkmk 1.4.0 auf 1.5.0p8 oder später aktualisiert wurden, oder erst mit Checkmk 1.5.0 oder später installiert wurden, tritt es überhaupt nicht auf.

Was müssen Sie tun? Öffnen Sie die Nutzereinstellungen von Nutzern, die Nachrichten erhalten sollen und speichern Sie diese einmal – auch wenn vermeintlich korrekte Einstellungen angezeigt werden. Da dies bei einer großen Anzahl von Nutzern wenig praktikabel ist, können Sie die nötigen Änderungen/Überprüfungen auch in der Konfigurationsdatei ~/etc/check_mk/conf.d/wato/contacts.mk vornehmen. Details erklärt das Werk #6417.

Jede Checkmk-Instanz stellt ihre HTTP-Dienste (GUI, APIs) über einen eigenen instanzspezifischen Apache-Prozess bereit. Den globalen Zugriff auf diesen instanzspezifischen Apache stellt der System-Apache bereit, der je nach Systemkonfiguration die Ports 80 und 443 für externe Anfragen öffnet.

Um etwas über den instanzspezifischen Apache zu erfahren, liest der System-Apache eine vom Instanzbenutzer bereitgestellte Reverse-Proxy-Konfiguration. Ein böswilliger Instanzbenutzer könnte nun den System-Apache dazu bringen, Code als Root-Benutzer auszuführen, da der System-Apache normalerweise zunächst mit Root-Rechten gestartet wird.

Um diese Sicherheitslücke zu schließen, müssen wir die System-Apache-Konfiguration vom Zugriff des Instanzbenutzers trennen. Um die Erweiterung der Rechte zu beseitigen, muss für jede Instanz einmal der Befehl omd update-apache-config <sitename> ausgeführt werden.

Im Werk #14281 erhalten Sie weitere, ausführliche Informationen zu diesem Thema und zusätzliche Hinweise, die auch die Ausführung des Befehls omd update betreffen, wenn mit diesem bestimmte Optionen geändert werden.

Betrifft Sie das? Seit der Version 2.1.0p7 werden Sie bei der Ausführung von omd update dazu aufgefordert, zusätzlich omd update-apache-config <sitename> auszuführen. Falls Sie dies bereits bei einem Update der 2.1.0 getan haben, ist beim Update auf die 2.2.0 nichts weiter zu tun. Aus der bisherigen dringenden Empfehlung wird nun eine Voraussetzung beim Update auf die 2.2.0.

Was müssen Sie tun? Führen Sie als Root-Benutzer den Befehl omd update-apache-config <sitename> aus, wenn Sie bei der Ausführung von omd update dazu aufgefordert werden.

Wie bereits in der 2.1.0 angekündigt, ist die Web-API (auch HTTP-API genannt) in der Checkmk-Version 2.2.0 entfernt worden. Die Web-API wird durch die REST-API ersetzt.

Betrifft Sie das? Das betrifft Sie, falls Sie eigene Skripte geschrieben haben, die noch die Web-API nutzen.

Was müssen Sie tun? Migrieren Sie alle bestehenden Skripte, die die Web-API verwenden, auf die REST-API, bevor Sie auf die Checkmk-Version 2.2.0 umsteigen. Im Artikel zur REST-API finden Sie eine Übersicht, welche REST-API-Endpunkte die Web-API-Befehle ersetzen.

Den Checkmk 2.0.0 Spezialagenten und die zugehörigen Check-Plugins für das Kubernetes-Monitoring gibt es nicht mehr in der 2.2.0. Nutzen Sie stattdessen das in der Version 2.1.0 von Grund auf neu geschriebene und stark verbesserte Kubernetes-Monitoring.

Wie bereits in der Version 2.1.0 angekündigt, unterstützt Checkmk 2.2.0 nicht mehr den Nagios Service Check Acceptor (NSCA). NSCA ist ein Nagios Add-on, um Ergebnisse passiver Checks von fernen Hosts in einer verteilten Nagios-Konfiguration zu erhalten. Dieses veraltete Verfahren zum Aufbau eines verteilten Monitorings bietet gegenüber den Checkmk-eigenen Verfahren keine Vorteile. Details und Hinweise zum Ersatz finden Sie im Werk #13644.

Mit lokalen Dateien können Sie die von Checkmk bereitgestellte Funktionalität anpassen und erweitern. Diese Dateien befinden sich im lokalen Teil der Instanzverzeichnisstruktur, d.h. in ~/local. Lokale Dateien können bei einem Update Probleme bereiten, wenn sie nicht mehr zur neuen Checkmk-Version passen.

Betrifft Sie das? Da es für Checkmk bei einem Update nicht möglich ist, die Kompatibilität von lokalen Anpassungen vollständig sicherzustellen, sollten Sie Ihre Checkmk-Instanz vor einem Update daraufhin überprüfen, ob lokale Dateien bei Ihnen verwendet werden und gegebenenfalls welche.

Was müssen Sie tun? Verschaffen Sie sich einen Überblick über nicht paketierte lokale Dateien Ihrer Checkmk-Instanz, indem Sie als Instanzbenutzer das folgende Kommando ausführen:

Werden hier Dateien aufgeführt, sollten Sie zusammen gehörende in Erweiterungspaketen (MKPs) zusammenfassen. Dies erleichtert später die Deaktivierung en bloc, sollten nach dem Update Inkompatibilitäten festgestellt werden.

In Checkmk 2.2.0 wurden einige intern genutzte Programmierschnittstellen (APIs) umgebaut.

Betrifft Sie das? Das Thema APIs kann Sie betreffen, wenn Sie die mit Checkmk ausgelieferten um Ihre eigenen, selbst geschriebenen Checks erweitert haben und/oder wenn Sie Plugins aus anderen Quellen nutzen. Da die neu strukturierten APIs als intern gelten und auch für Plugins aus der Checkmk Exchange nicht verfügbar sind, sollte die Zahl betroffener Erweiterungen gering sein.

Was müssen Sie tun? Überprüfen Sie Erweiterungen von Drittanbietern auf ihre Funktionsfähigkeit und nehmen Sie gegebenenfalls die notwendigen Anpassungen der Import-Pfade vor.

Betroffen sind:

Über die Checkmk-Erweiterungspakete (MKPs) lässt sich Ihr Monitoring-System recht einfach und bequem erweitern. Auf der einen Seite kommt es dabei vor, dass solche MKPs nicht weiter gepflegt werden und dann ggf. mit neuen Versionen von Checkmk nicht mehr kompatibel sind. Auf der anderen Seite nehmen wir immer wieder neue Plugins und Funktionserweiterungen in Checkmk auf, weshalb MKPs mitunter obsolet werden. Ihre Funktionalität wird schlicht von Checkmk selbst sichergestellt.

Betrifft Sie das? Falls Sie MKPs installiert haben, ist aus diesem Grund eine Prüfung dieser MKPs dringend geboten — besonders vor einem umfangreichen Update. So verhindern Sie, dass inkompatible Pakete das Update behindern oder im Anschluss an das Update doppelte oder zumindest sehr ähnliche Services entstehen.

Was müssen Sie tun? Prüfen Sie hierzu Ihre installierten MKPs gegen unseren Katalog der Check-Plugins und entfernen Sie Pakete, welche inzwischen nativ von Checkmk bereitgestellt werden. Bei dieser Gelegenheit können Sie auch MKPs entfernen, die eventuell nur mal für einen Probelauf installiert worden sind. Eine Auflistung finden Sie in den kommerziellen Editionen über Setup > Maintenance > Extension packages.

Auf der Kommandozeile können Sie sich installierte Erweiterungen mit dem folgenden Befehl anzeigen lassen:

Zu jedem gelistetem MKP können Sie dann in der Folge auch die Dateien anzeigen lassen, die zu dem Paket gehören:

Sollten Sie über die Prüfung der installierten MKPs und dem Abgleich mit unserem Katalog nicht alle Pakete zuordnen können, empfiehlt sich der hiernach beschriebene Probelauf des Updates, um dabei Inkompatibilitäten zu identifizieren und dann in Ihrem produktiven Monitoring vor dem Update zu entfernen.

Wie in jeder Checkmk Version, so gibt es auch in der aktuellen Version 2.2.0 Änderungen der Software, die Rückwirkungen auf ihre Checkmk-Installation haben können. Eine sogenannte inkompatible Änderung erfordert, dass Sie manuelle Anpassungen durchführen, um bestehende Funktionen weiterhin wie gewohnt ablaufen zu lassen und/oder neue Funktionen nutzen zu können.

Betrifft Sie das? In aller Regel wird es inkompatible Änderungen geben, die auch Ihre Checkmk-Installation betreffen. Eine generelle Aussage ist aber leider unmöglich. In diesem Artikel haben wir diejenigen Themen zusammengetragen, die für alle oder die meisten Checkmk-Installationen zutreffen. Es kann aber sein, dass es darüber hinaus weitere, für Sie relevante Änderungen gibt, zum Beispiel bei Checks, die Sie in Ihrer Installation verwenden.

Was müssen Sie tun? Nachdem Sie das Update durchgeführt haben, werden Ihnen in der Checkmk-Oberfläche Anzahl und Inhalt der inkompatiblen Änderungen angezeigt, und Sie werden aufgefordert, diese zu prüfen und zur Kenntnis zu nehmen. Also werden Sie auf jeden Fall mit diesem Thema konfrontiert werden — allerdings erst, nachdem Sie das Update durchgeführt haben.

Es ist daher eine gute Idee, sich bereits vor dem Update einen Überblick über die inkompatiblen Änderungen zu verschaffen: Öffnen Sie die Liste der Werks. (Die Software-Entwicklung von Checkmk ist in sogenannten Werks organisiert.) In der Beschreibung eines Werks finden Sie Hinweise, was gegebenenfalls zu tun ist, um die Änderung kompatibel zu machen.

Die frustrierende Nachricht: Die Werkliste einer Version ist sehr, sehr lang — selbst wenn sie nur die inkompatiblen Änderungen enthält. Die tröstliche Nachricht: An der Anzahl der Änderungen können Sie sehen, wie groß unsere Anstrengungen sind, Checkmk für Sie zu verbessern.

Im Folgenden beschreiben wir bewährte Vorgehensweisen (best practices), welche wir selbst bei Updates von großen Checkmk-Umgebungen befolgen. Diese sind sicherlich nicht in jeder Umgebung Pflicht, Sie können Ihnen den Prozess des Updates jedoch erleichtern.

Es gibt zwei unterschiedliche Vorgehensweisen, um das Update aller in einem verteilten Monitoring beteiligten Instanzen durchzuführen:

Insbesondere, wenn Sie die Aktualisierung im laufenden Betrieb anstreben, sollten Sie die Hinweise im allgemeinen Artikel zu Updates und Upgrades lesen.

Am eigentlichen Update der Software hat sich in der Checkmk 2.2.0 nichts Grundlegendes geändert, d.h. Sie installieren die neue Version, führen das Update der Checkmk-Instanz durch, kümmern sich um Konflikte (falls es denn welche geben sollte) und überprüfen und bestätigen die inkompatiblen Änderungen.

Führen Sie die Update-Prozedur so aus, wie sie im Artikel zu Updates und Upgrades beschrieben ist.

Falls Sie in der Version 2.1.0 die Free Edition installiert haben, liegt es nahe, mit dem Update auf die 2.2.0 auch das Upgrade auf die Cloud Edition durchzuführen, da Sie diese Checkmk-Edition in der 2.2.0 zeitlich begrenzt ausprobieren und in in kleinem Rahmen dauerhaft nutzen können.

Hinweis: Das hier beschriebene direkte Crossgrade wird nur für den Wechsel von 2.1.0 Free Edition nach 2.2.0 Cloud Edition unterstützt. In allen anderen Fällen führen Sie zuerst das Update von Checkmk und dann das Upgrade der Edition durch. Bei verteilten Umgebungen ist hier wieder auf die Reihenfolge zu achten.

Die Eingabe eines Lizenzschlüssels nach spätestens 30 Tagen ist nur notwendig, falls Sie die Cloud Edition ohne Beschränkungen einsetzen möchten. Sofern Sie unterhalb der Grenze von 750 Services in einer Instanz bleiben, wechselt die Cloud Edition nach 30 Tagen in den Lizenzstatus „Free“.

Die Benutzeroberfläche (GUI) von Checkmk, die mit Version 2.0.0 komplett neu gestaltet wurde, hat sich auch in der 2.2.0 nicht grundlegend verändert. Die generellen Abläufe, die Sie aus der Version 2.0.0 und 2.1.0 kennen, können Sie auch in der 2.2.0 unverändert anwenden. Allerdings haben sich Menüs, Menüeinträge, Symbole und andere Details geändert, um neue Funktionen verfügbar zu machen — und bestehende zu verbessern.

In den Artikeln dieses Handbuchs stellen wir Ihnen diese Änderungen vor - und im Leitfaden für Einsteiger finden Sie eine ausführliche Einführung, unter anderem in die wichtigsten Elemente der Benutzeroberfläche.

Wie jede Hauptversion, so bringt auch Checkmk 2.2.0 eine ganze Reihe neuer Check-Plugins mit sich. Sollten Sie den "Discovery Check" nicht einsetzen, d.h. das automatische Update der Service-Konfiguration über die periodische Service-Erkennung, werden Sie auf einer ganzen Reihe von Hosts die Suche nach Services durchführen müssen.

Wenn Ihre Hosts entsprechend organisiert sind (z.B. in Ordnern), können Sie hierfür zumeist mit der Funktion Bulk discovery arbeiten. Diese finden Sie unter Setup > Hosts > Hosts und dann im Menü Hosts > Run bulk service discovery.

Seit Checkmk 2.1.0 benötigen Hosts zur Durchführung der TLS-Registrierung Zugriff auf folgende Ports des Checkmk-Servers: Port 443 (respektive 80) für REST-API-Anfragen und Port 8000 für den Agent Receiver. Sprechen Sicherheitsrichtlinien dagegen, diese Ports verfügbar zu machen, können Sie bei Nutzung des Pull-Modus eine Registrierung im Auftrag direkt auf dem Checkmk-Server durchführen.

Um den in der Checkmk 2.2.0 eingeführten Push-Modus der Cloud Edition nutzen zu können, muss Port 8000 des Checkmk-Servers vom überwachten Host aus erreichbar sein.

Checkmk 2.1.0 nutzte für den Aufbau der TLS-Verbindung Zertifikate mit de facto unbegrenzter Gültigkeit. In Checkmk 2.2.0 ist die Laufzeit der Zertifikate einstellbar und auf einen Standardwert von fünf Jahren gesetzt (siehe Werk #14964). Zudem kann eine eigene Certificate Authority verwendet werden. Vor dem Update auf 2.2.0 erstellte Zertifikate werden automatisch nach Ablauf der maximalen Laufzeit durch neu generierte Zertifikate ausgetauscht.

Aktualisieren Sie daher Checkmk 2.1.0 Agenten, welche den Agent Controller mit Verschlüsselung verwenden, zeitnah auf den 2.2.0 Agenten.

In den wenigen Fällen, wo ein Update des Agenten nicht möglich ist – zum Beispiel, weil die Betriebssystemversion vom 2.2.0 Agenten nicht mehr unterstützt wird –, müssen Sie betroffene Hosts nach Ablauf der Zertifikatslaufzeit manuell neu registrieren. Dasselbe gilt, wenn Hosts mit dem 2.2.0 Agenten längere Zeit inaktiv sind.

Betrifft Sie das? Dies betrifft Sie, wenn Sie von der Funktion Gebrauch gemacht haben, MKPs in verschiedenen Versionen vorzuhalten.

Was müssen Sie tun? Während des Updates werden inkompatible Pakete automatisch auf den Zustand Disabled gesetzt, aber nicht vollständig gelöscht. Zur neuen Checkmk-Version kompatible Pakete werden automatisch aktiviert, Sie erhalten den Zustand Enabled (active on this site).

Wenn die Funktionalität der neuen Pakete sichergestellt ist und die alten nicht mehr als Referenz benötigt werden, können Sie nach veralteten Paketen suchen:

Deinstallieren Sie diese dann mit mkp remove.

Betrifft Sie das? Dies betrifft Sie nur, wenn Sie für selbst geschriebene oder aus der Exchange bezogene Spezialagenten oder agentenbasierte Check-Plugins explizit Python-Module nachinstalliert hatten, und diese im Zuge der Vorbereitung des Updates entfernt haben.

Was müssen Sie tun? Finden Sie zunächst heraus, ob die zuvor deinstallierten Module bereits mit der neuen Checkmk-Version ausgeliefert werden, zum Beispiel:

Wird das Modul bereits gefunden, kennzeichnen Sie es in Ihren Notizen als nicht benötigt. Installieren Sie nicht mitgelieferte Module in Ihrer aktuellsten Version nach:

Testen Sie anschließend die Check-Plugins oder Spezialagenten, die auf in der Instanz installierte Python-Module angewiesen sind.

mod_auth_mellon ist ein Software-Modul für Apache, das Dienste zur Authentifizierung (authentication) über Secure Assertion Markup Language (SAML) bereitstellt. Bis zur Checkmk Version 2.1.0 war die Anmeldung bei Checkmk über SAML nur mit der Hilfe von mod_auth_mellon möglich. Ab der Version 2.2.0 ist die SAML-Authentifizierung in den kommerziellen Editionen von Checkmk eingebaut und die Konfiguration erfolgt über die Checkmk-Benutzeroberfläche, wie es im Artikel zu SAML beschrieben ist. Auch die SAML-Authentifizierung per mod_auth_mellon wird in der Version 2.2.0 noch unterstützt.

Das ändert sich jedoch ab der Version 2.3.0: mod_auth_mellon wird dann nicht mehr mit der Checkmk-Software ausgeliefert werden. Wenn Sie diesen Weg zur SAML-Authentifizierung ab der 2.3.0 weiterhin nutzen wollen, müssen Sie mod_auth_mellon manuell installieren. Allerdings gibt es von uns ab der Version 2.3.0 keinen Support mehr für dieses Verfahren.

In der Version 2.3.0 wird es nicht mehr möglich sein, Standardwerte von Check-Plugins oder andere globale Variablen mithilfe von mk-Dateien zu überschreiben.

Dieser veraltete Weg, Plugins zu konfigurieren, ist seit langem nicht mehr dokumentiert — und funktioniert sowieso nicht mehr bei all jenen Plugins, die auf die in der 2.0.0 eingeführte Check-API umgestellt worden sind. Daher wird die Konfiguration von Check-Plugin-Standardwerten mit mk-Dateien beginnend mit der Version 2.3.0 nicht mehr unterstützt.

Details und Hinweise zur Umstellung finden Sie im Werk #15250.

Der Prometheus-Spezialagent bietet kube-state-metrics als Datenquelle, dessen Checks nicht mehr aktiv unterstützt werden. Diese wurden mittlerweile durch verbesserte Gegenstücke im Kubernetes-Agenten ersetzt (siehe Werk #14572). Zudem wird in den Regeln Prometheus und Alertmanager die Angabe von IP-Adresse/Host-Name, Port und Pfadpräfix durch ein einziges Eingabefeld Custom URL abgelöst (siehe Werk #14573).

In beiden Fällen funktioniert das alte Verfahren weiterhin in 2.2.0. Zur Verwendung in 2.3.0 müssen Sie jedoch Ihre Konfiguration auf das neue Verfahren umgestellt haben.