Versionsupdate von Check_MK

Letzte Aktualisierung: 12. Oktober 2016


1. Einleitung

Das Update von Check_MK auf eine neue Version läuft etwas anders als bei anderer Software. Warum?

Grund ist, dass Check_MK nicht nur mehrere unabhängige Instanzen (Sites) auf einem Server erlaubt, sondern auch mehrere gleichzeitig installierte Softwareversionen. Dabei ist jede Instanz einer installierten Version zugeordnet. Nehmen wir als Beispiel folgende Situation auf einem fiktiven Server:

Hier verwendet die Instanz mysite1 die Version 1.2.8p11.cee, die Instanzen mysite2 und mysite3 die Version 1.2.6p10.cre. Die Check_MK-Version 1.2.6p10.demo ist zwar installiert, wird aber aktuell nicht verwendet.

Dieses Beispiel macht klar, dass ein Update nicht einfach nur die Installation eines neuen RPM/DEB-Pakets von Check_MK auf dem Server bedeuten kann. Vielmehr braucht es dazu noch einen weiteren Schritt. Nehmen wir als Beispiel folgende Situation:

Hier soll die Instanz mysite auf die Check_MK-Version 1.2.8p11.cee aktualisiert werden. Der erste Schritt ist das Herunterladen und Installieren des passenden RPM/DEB-Pakets. Dies geschieht genauso wie bei der ersten Installation. Die neu installierte Version wird zunächst noch von keiner Instanz verwendet und das sieht dann so aus:

Als zweiter Schritt erfolgt nun ein Update der Instanz von 1.2.6p10.cre auf 1.2.8p11.cee. Dies geschieht durch den Befehl omd update, welchen wir weiter unten im Detail besprechen:

Nach dem Update können Sie die (eventuell) nicht mehr benötigte Version 1.2.6p10.cre durch das Deinstallieren des entsprechenden Pakets entfernen. Es ist aber keine schlechte Idee, diese noch installiert zu lassen. So können Sie mit einem erneuten omd update sehr schnell wieder auf diese zurück wechseln, falls das nötig sein sollte.

2. Update von Check_MK im Detail

2.1. Installationen neuer Versionen

Wie in der Einleitung beschrieben, ist der erste Schritt beim Update die Installation der gewünschten neuen Version von Check_MK. Dies erfolgt genau wie bei der ersten Installation – allerdings wird es wohl etwas schneller gehen, weil die meisten abhängigen Pakete jetzt schon installiert sind. In folgendem Beispiel installieren wir das Paket für Ubuntu 14.04 (Codename Trusty):

root@linux# gdebi omd-1.2.8p11.cee_0.trusty_amd64.deb

Die Liste der installierten Check_MK-Versionen können Sie jederzeit mit dem Befehl omd versions abrufen:

root@linux# omd versions
2016.12.18.cee
1.2.8p11.cee
1.2.6p10.cre (default)

Eine dieser Versionen ist mit (default) markiert. Diese Defaultversion wird automatisch beim Anlegen von neuen Sites verwendet, sofern Sie nicht mit omd -V myversion create mysite eine andere angeben. Bei der Arbeit mit bestehenden Sites ist sie nicht relevant. Die aktuelle Default­version können Sie mit omd version abfragen und mit omd setversion ändern:

root@linux# omd version
1.2.6p10.cre
root@linux# omd setversion 1.2.8p11.cee
root@linux# omd version
1.2.8p11.cee

Beim Update oder Managen von bestehenden Instanzen spielt die Defaultversion keine Rolle. Der Befehl omd startet sich selbst immer automatisch in der zur Instanz passenden Version.

Eine Auflistung der aktuellen Instanzen und welche Versionen diese verwenden liefert der Befehl omd sites:

root@linux# omd sites
SITE             VERSION
mysite           1.2.6p10.cre
test             2016.12.18.cee

2.2. Durchführen des Updates

Nachdem die gewünschte neue Version installiert ist, können Sie das Update der Instanz durch­führen. Dazu sind keine root-Rechte erforderlich. Machen Sie das Update am besten als Instanz­benutzer:

root@linux# su - mysite

Stellen Sie sicher, dass die Instanz gestoppt ist:

OMD[mysite]:~$ omd stop

Das Updaten – also eigentlich das Umschalten auf eine andere Version – geschieht nun einfach mit dem Befehl omd update:

OMD[mysite]:~$ omd update

Falls es mehr als eine mögliche Zielversion gibt, bekommen Sie diese zur Auswahl:

Ein wichtiger Teil des Updates ist das Aktualisieren von mitausgelieferten Konfigurationsdateien. Dabei werden von Ihnen evtl. vorgenommene Änderungen in diesen Dateien nicht einfach verworfen, sondern zusammengeführt. Dies funktioniert sehr ähnlich zu Versionskontrollsystemen, die versuchen, gleichzeitige Änderungen mehrerer Entwickler in der gleichen Datei automatisch zusammenzuführen.

Manchmal – wenn die Änderungen die gleiche Stelle der Datei betreffen – funktioniert das nicht und es kommt zu einem Konflikt. Wie Sie diesen lösen können, zeigen wir weiter unten.

Das Update zeigt eine Liste aller angepassten Dateien und Verzeichnisse:

2016-10-11 18:27:07 - Updating site 'mysite' from version 1.2.6p10.cre to 1.2.8p11.cee...

 * Unwanted       var/log/nagios.log (unchanged, deleted by you)
 * Updated        etc/nagvis/nagvis.ini.php
 * Updated        etc/mk-livestatus/nagios.cfg
 * Updated        etc/check_mk/defaults
 * Updated        etc/apache/conf.d/02_fcgid.conf
Finished update.

Wenn alles erfolgreich durchgelaufen ist, ist die Instanz auf die neue Version umgeschaltet …

OMD[mysite]:~$ omd version
1.2.8p11.cee

… und kann gestartet werden:

OMD[mysite]:~$ omd start

2.3. Inkompatible Änderungen

Softwareentwicklung bedeutet Änderung. Und da wir immer daran arbeiten, Check_MK modern zu halten, kommen wir manchmal nicht drumherum, alte Zöpfe abzuschneiden und Änderungen zu machen, die inkompatibel sind. Das bedeutet, dass Sie nach einem Update eventuell Ihre Konfiguration anpassen oder wenigstens überprüfen sollten.

Ein typisches Beispiel dafür sind neue Checkplugins, welche bestehende Plugins ersetzen. Falls Sie eines der betroffenen Plugins einsetzen, ist nach dem Update eine erneute Serviceerkennung auf den betroffenen Hosts notwendig.

Eine Übersicht über alle Änderungen in Check_MK inklusive einer Suchfunktion finden Sie online hier Noch praktischer ist aber die in Check_MK eingebaute Funktion zur Recherche in den Versionshinweisen. Zu diesen gelangen Sie mit einem Klick auf die Versionsnummer links oben in der Seitenleiste:

Check_MK verfolgt dabei automatisch neue inkompatible Änderungen und warnt Sie entsprechend:

Sie können diese „Werks“ dann ansehen und mit einem Mausklick bestätigen. Außerdem finden Sie eine komplette Auflistung über die komplette Historie der Änderungen inklusive einer Suchfunktion:

2.4. Downgrade – zurück zur alten Version

Der Prozess zum Umschalten auf eine alte Version läuft völlig analog zum Update. Genau genommen ist es omd update völlig egal, ob die Zielversion neuer oder älter ist als die aktuelle Version. Somit können Sie hin- und herschalten wie Sie möchten.

Bitte bedenken Sie aber auch, dass selbst wenn ein Downgrade zu einer alten Version wunderbar funktioniert, Check_MK mit bestehenden Daten aus neueren Versionen nicht immer umgehen kann. Eine neue Check_MK-Version legt Daten und Konfiguration eventuell in einem erweiterten Format an, das eine alte Version nicht versteht.

Eine Konfiguration, die mit WATO gepflegt wird, wird erst dann auf ein eventuell neues Format umgebaut, sobald Sie WATO aktiv verwenden und Änderungen speichern. Solange Sie das nicht getan haben, ist ein Wechsel zurück zur alten Version in der Regel unproblematisch.

Falls Sie also noch nicht sicher sind, ob Sie zu einer früheren Version zurück müssen, empfehlen wir:

  • Machen Sie vor dem Update eine Datensicherung.
  • Probieren Sie die neue Version erst in Ruhe aus, bevor Sie Änderungen via WATO machen.

2.5. Das Update im Detail

Sind Sie neugierig, was beim Update genau „unter der Haube abläuft“? Oder haben Sie beim Durchlauf von omd update Konflikte in Dateien bekommen? Dann sollten Sie hier weiterlesen.

Bei omd update geschehen drei Dinge:

  1. Aktualisieren von Vorgabedateien unter etc/ und var/, also solchen Dateien, die bei omd create erzeugt wurden.
  2. Umschalten der Version auf die Zielversion durch Ändern des symbolischen Links version, welcher sich im Site-Verzeichnis befindet.
  3. Nachbearbeitungen durch verschiedene Pakete (z. B. Check_MK). Insbesondere wird automatisch ein Activate Changes durchgeführt, um eine valide Konfiguration für den Kern zu erzeugen.

Aktualisieren von Dateien, Zusammenführen von Änderungen

Der erste Schritt ist der bei weitem umfangreichste. Hier zeigt sich ein großer Vorteil von Check_MK gegenüber klassischen Software-Installationen: Check_MK hilft Ihnen, alle Standard-Konfigurations­dateien an die Erfordernisse der neuen Version anzupassen. Dies ähnelt dem Vorgang beim Update einer Linux-Distribution, geht aber in der Umsetzung darüber hinaus. So behandelt Check_MK eine Vielzahl von Fällen, zum Beispiel:

  • Zusammenführen von Dateiänderungen mit lokalen Änderungen des Benutzers.
  • Dateien, Verzeichnisse und symbolische Links, die in der neuen Version obsolet sind oder vom Benutzer gelöscht wurden.
  • Änderungen an den Berechtigungen.
  • Änderungen des Dateityps (aus Verzeichnis oder Datei wird symbolischer Link oder umgekehrt).
  • Änderungen des Ziels von symbolischen Links.

Dabei achtet Check_MK stets darauf, dass Ihre lokalen Änderungen erhalten bleiben, gleichzeitig aber alle für die neue Version notwendigen Änderungen umgesetzt werden.

Zusammenführen und Konflikte

Falls die neue Version eine Änderung an einer Konfigurationsdatei vorsieht, an der Sie inzwischen selbst Änderungen vorgenommen haben, versucht Check_MK, beide Änderungen automatisch zusammenzuführen (mergen). Dies geschieht mit den gleichen Methoden, die auch Versions­kontrollsysteme verwenden.

Am wenigsten Probleme gibt es immer dann, wenn Ihre und Check_MKs Änderungen räumlich weit genug auseinander liegen (mindestens ein paar Zeilen). Dann geschieht das Mergen automatisch und ohne Ihre Hilfe.

Wenn zwei Änderungen kollidieren, weil sie die gleiche Stelle der Datei betreffen, kann und will Check_MK nicht entscheiden, welche der beiden Änderungen wichtiger ist. In diesem Fall werden Sie als Benutzer eingeschaltet und können den Konflikt interaktiv auflösen:

Sie haben nun folgende Möglichkeiten:

dDies zeigt Ihnen die Unterschiede zwischen der neuen Defaultversion der Datei und Ihrer Version in Form eines "unified diff" (diff -u).
yDies ist ähnlich, zeigt aber ausgehend von der früheren Defaultversion, welche Änderungen Sie an der Datei gemacht haben.
nDiese dritte Option schließt quasi das Dreieck und zeigt die Änderungen, welche Check_MK an der Datei vornehmen möchte.
tDrücken Sie t, so wird Ihre Originaldatei – ohne den bereits erfolgreich gemergten Änderungen – in einem Editor geöffnet. Editieren Sie nun die Datei, um eventuellen Konflikten aus dem Weg zu gehen. Nach dem Schließen des Editors probiert Check_MK das Mergen erneut.
kHier entscheiden Sie sich dafür, die Datei so zu übernehmen, wie sie jetzt ist. Die erfolgreich eingebauten Änderungen bleiben. Ansonsten bleibt die Datei so, wie von Ihnen angepasst.
rSo stellen Sie Ihre Datei im Ausgangszustand wieder her und verzichten auf das Update von Check_MK für diese Datei. Möglicherweise notwendige Anpassung müssen Sie selbst vornehmen.
iInstallieren der neuen Defaultdatei: Ihre Änderungen an der Datei gehen verloren.
sWenn Sie unsicher sind, können Sie mit s eine Shell öffnen. Sie befinden sich im Verzeichnis, in der die betroffene Datei liegt, und können sich ein Bild von der Lage machen. Beenden Sie die Shell mit Strg-D, um das Update fortzusetzen.
aAbbruch des Updates. Die Instanz bleibt auf der alten Version. Die bereits geänderten Dateien bleiben aber geändert! Sie können jederzeit einen neuen Update-Versuch starten.

Weitere Konfliktsituationen

Neben dem inhaltlichen Zusammenführen von Dateien gibt es noch eine ganze Reihe weiterer Fälle, in denen Check_MK Ihre Entscheidung braucht. Dies sind teils sehr ungewöhnliche Situationen, die aber trotzdem korrekte Behandlung brauchen. Check_MK wird Ihnen in diesen Fällen stets die Auswahl geben, Ihre Version beizubehalten oder die neue Defaultversion zu übernehmen. Außerdem haben Sie immer die Möglichkeit eines Abbruchs oder können eine Shell öffnen. Beispiele für solche Fälle sind:

  • Kollidierende Änderungen des Dateityps (z. B. wenn eine Datei durch einen symbolischen Link ersetzt wird).
  • Kollidierende Änderungen an den Dateirechten.
  • Geänderte Dateien, die in der neuen Version entfallen.
  • Von Ihnen angelegte Dateien, Verzeichnisse oder Links, die mit neuen Dateien/Verzeichnissen/Links kollidieren.

Erklärung der Ausgaben beim Update

Immer wenn der Updatevorgang automatisch Änderungen an Dateien macht, gibt er eine Zeile zur Erklärung aus. Dabei gibt es folgende Möglichkeiten (wenn von Datei die Rede ist, gilt dies analog auch für Links und Verzeichnisse):

Updated Eine Datei hat sich in der neuen Version geändert. Da Sie keine Änderungen an der Datei gemacht haben, setzt Check_MK einfach die neue Defaultversion der Datei ein.
Merged Eine Datei hat sich in der neuen Version geändert, während Sie gleichzeitig andere Änderungen an der Datei gemacht haben. Beide konnten konfliktfrei zusammengeführt werden.
Identical Eine Datei hat sich in der neuen Version geändert. Gleichzeitig haben Sie die Datei selbst schon in genau der gleichen Art geändert. Check_MK muss nichts unternehmen.
Installed Die neue Version bringt eine neue Konfigurationsdatei mit, welche soeben installiert wurde.
Identical new Die neue Version bringt eine Datei mit, inzwischen haben Sie selbst die gleiche Datei mit dem gleichen Inhalt angelegt.
Obsolete In der neuen Version ist eine Datei (Link, Verzeichnis) weggefallen. Sie haben diese Datei sowieso schon gelöscht. Nicht passiert.
Vanished Auch hier ist eine Datei weggefallen, welche Sie aber weder gelöscht noch verändert haben. Check_MK entfernt diese Datei automatisch.
Unwanted Sie haben eine Datei gelöscht, die normalerweise vorhanden ist. Da sich in der neuen Version keine Änderung in der Datei ergeben hat, belässt es Check_MK dabei, dass die Datei fehlt.
Missing Sie haben eine Datei gelöscht, an der sich in der neuen Version Änderungen ergeben haben. Check_MK legt die Datei nicht neu an, warnt Sie aber durch diese Ausgabe.
Permissions Check_MK hat die Berechtigungen einer Datei aktualisiert, da in der neuen Version andere Rechte gesetzt sind.

2.6. Update ohne Benutzerinteraktion

Möchten Sie das Softwareupdate von Check_MK automatisieren? Dann werden Sie vielleicht erstmal an den interaktiven Rückfragen von omd update gescheitert sein. Dafür gibt es eine einfache Lösung: Der Befehl kennt nämlich Optionen, die speziell für den Einsatz in Skripten gedacht sind:

  • Die Option -f oder --force direkt nach omd verhindert alle Fragen vom Typ „Sind Sie sicher...“.
  • Die Option --conflict= direkt nach update setzt das gewünschte Verhalten bei einem Dateikonflikt.

Mögliche Werte für --conflict= sind:

--conflict=keepold Behält im Konfliktfall Ihre eigene modifizierte Version der Datei. Eventuell ist Check_MK dann aber nicht lauffähig und ein manuelles Nacharbeiten erforderlich.
--conflict=install Installiert im Konfliktfall die neue Standardversion der Datei. Damit gehen lokale Änderungen in der Datei zumindest teilweise verloren.
--conflict=abort Bricht das Update im Konfliktfall ab. Das bedeutet aber nicht, dass alles auf den alten Stand zurückgerollt wird. Etliche Konfigurationsdateien sind eventuell schon umgestellt. Als Version ist aber noch die alte Version eingestellt.
--conflict=ask Dies ist das Standardverhalten, somit ist die Option in dieser Form eigentlich wirkungslos.

Ein Beispiel für den kompletten Befehl für ein automatisches Update der Instanz mysite auf die Version 1.2.8p11:

root@linux# omd stop mysite ; omd -f update --conflict=install mysite 1.2.8p11 && omd start

Durch das && vor dem omd start wird ein Starten der Instanz verhindert, falls das omd update mit einem Fehler abbricht. Ersetzen Sie das && durch ein Semikolon (;), falls Sie einen Start auch in diesem Fall unbedingt versucht wollen.

Falls Sie sicher sind, dass Sie nur eine einzige Check_MK-Instanz auf dem Server haben, können Sie deren Namen zur Verwendung in einem Shellskript einfach in einer Variable einfangen:

root@linux# omd sites --bare
mysite
root@linux# SITENAME=$(omd sites --bare)
root@linux# echo $SITENAME
mysite

Das ermöglicht Ihnen, obige Zeile vom Namen der Instanz unabhängig zu machen. Ein kleines Shellskript könnte z. B. so aussehen:

update.sh
#!/bin/bash
SITE=$(omd sites --bare)
VERSION=1.2.8p11

omd stop $SITE
omd -f update --conflict=install $SITE $VERSION && omd start $SITE

3. Update der Demo- auf die Vollversion

Haben Sie Ihre erste Installation von Check_MK mit der Demoversion gemacht? Sobald Sie eine Subskription der  Check_MK Enterprise Edition haben, können Sie Ihre bestehende Instanz einfach auf die Vollversion updaten.

Das Vorgehen ist exakt wie beim „normalen“ Update. Der einzige Unterschied ist, dass Sie von einer Version mit der Endung .demo auf eine Version mit der Endung .cee updaten. Installieren Sie einfach das gewünschte Paket der Vollversion und schalten Sie dann die bestehende Instanz mit omd update auf diese um.

Am einfachsten geht das, wenn beide Versionen bis auf das Suffix .demo bzw. .cee identisch sind. Was die Funktionalität betrifft, ist die Demoversion bis auf die zufälligen WARN-Zustände völlig identisch mit der Vollversion. Daher ergeben sich durch das Update keinerlei Unterschiede.

Ein gleichzeitiger Wechsel der eigentlichen Version ist aber durchaus möglich. Dabei gelten die gleichen Grundsätze wie bei einem normalen Update von Check_MK.

4. Update der Raw auf die Enterprise Edition

Auch ein Update der  Check_MK Raw Edition auf die  Check_MK Enterprise Edition ist möglich. Auch hier ist das Vorgehen wie gehabt: Gewünschtes Paket installieren und Instanzen mit omd update umstellen.

Da der CRE etliche Module und Features der CEE fehlen, gibt es allerdings nach der Umstellung ein paar Dinge zu beachten. Der entscheidende Punkt ist, dass beim Anlegen von neuen Instanzen der CRE bzw. CEE unterschiedliche Defaulteinstellungen gesetzt werden.

Nagios vs. CMC

Da die CRE nur Nagios als Kern unterstützt, ist dieser bei Instanzen, die mit der CRE erstellt wurden voreingestellt. Diese Einstellung bleibt beim Update auf die CEE erhalten. Das bedeutet, dass Sie nach einem Update zunächst weiterhin mit Nagios als Kern fahren. Eine Umstellung auf den CMC erfolgt mit omd config und wird in einem eigenen Artikel beschrieben.

RRD-Format

Die CEE unterstützt ein alternatives Format für die Speicherung historischer Messdaten, welches deutlich weniger Platten-I/O erzeugt. Bei neuen CEE-Instanzen ist dies automatisch voreingestellt. CRE-Instanzen werden auch hier beim Update nicht automatisch umgestellt. Wie das Umstellen geht, beschreibt ein eigener Abschnitt im Titel über Messwerte und Graphen.

Alarmspooler

Die CRE hat keinen Alarmspooler. Deswegen ist dieser nach dem Umstieg auf die CEE ausgeschaltet. Wie dieser eingeschaltet werden kann, erfahren Sie hier.

5. Deinstallieren von Check_MK

Das Deinstallieren von nicht mehr benötigten Check_MK-Versionen geschieht mit dem Paketmanager des Betriebssystems. Geben Sie hier den Namen des installierten Pakets an, nicht den Dateinamen der ursprünglichen RPM/DEB-Datei. Wichtig: Löschen Sie nur solche Check_MK-Versionen, die von keiner Instanz mehr verwendet werden!

Nicht mehr benötigte Check_MK-Instanzen können Sie einfach mit omd rm entfernen (und dabei alle Daten löschen!):

root@linux# omd rm mysite

SLES, RedHat, CentOS

So finden Sie bei RPM-basierten Systemen heraus, welche Check_MK-Pakete installiert sind:

root@linux# rpm -qa | grep check-mk
check-mk-enterprise-2016.05.19.0
check-mk-enterprise-2016.10.11.0
check-mk-raw-1.2.8b9.0
check-mk-raw-1.2.8p11.0

Das Löschen geschieht mit rpm -e:

root@linux# rpm -e check-mk-raw-1.2.8b9.0

Debian, Ubuntu

So finden Sie heraus, welche Pakete installiert sind:

root@linux# dpkg -l | grep check-mk
ii  check-mk-enterprise-2016.05.19  0.trusty  amd64  Check_MK is a full featured system monitoring
ii  check-mk-enterprise-2016.10.11  0.trusty  amd64  Check_MK is a full featured system monitoring
ii  check-mk-raw-1.2.8b9            0.trusty  amd64  Check_MK is a full featured system monitoring
ii  check-mk-raw-1.2.8p11           0.trusty  amd64  Check_MK is a full featured system monitoring

Die Deinstallation geschieht mit dpkg --purge:

root@linux# dpkg --purge check-mk-raw-1.2.8b9
(Lese Datenbank ... 505719 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von check-mk-raw-1.2.8b9 (0.trusty) ...
Löschen der Konfigurationsdateien von check-mk-raw-1.2.8b9 (0.trusty) ...

6. Dateien und Verzeichnisse

Hier finden Sie für diesen Artikel relevante Dateien und Verzeichnisse. Pfade, die nicht mit einem / beginnen, gelten wie immer ab dem Homeverzeichnis der Instanz (/omd/sites/mysite):

Pfad Bedeutung
version Symbolischer Link auf die Installation der von dieser Instanz verwendeten Check_MK-Version.
/omd/versions Unterhalb dieses Verzeichnisses existiert für jede installierte Check_MK-Version ein Unterverzeichnis. Die Dateien gehören root und werden niemals geändert.
/omd/sites Unterhalb liegt für jede Instanz dessen Homeverzeichnis mit den Konfigurationsdateien und den variablen Daten. Die Datene gehören dem Instanzbenutzer und werden durch Konfiguration und Betrieb geändert.
/usr/bin/omd Verwaltungsbefehl für Check_MK-Instanzen. Dies ist ein symbolischer Link in das bin-Verzeichnis der Defaultversion. Sobald auf eine bestimmte Instanz zugegriffen wird, ersetzt sich der omd-Befehl selbst durch denjenigen der passenden Version.