1. Einleitung
Das Update von Checkmk auf eine neue Version läuft etwas anders als bei anderer Software. Warum?
Grund ist, dass Checkmk 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 Sie als Beispiel folgende Situation auf einem fiktiven Server:

Hier verwendet die Instanz mysite1
die Version 1.6.0p13.cee
,
die Instanzen mysite2
und mysite3
die
Version 1.6.0p10.cre
. Die Checkmk-Version 1.6.0p2.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 Checkmk auf dem Server bedeuten kann. Vielmehr braucht es dazu noch einen weiteren Schritt. Nehmen Sie nun als Beispiel folgende Situation:

Hier soll die Instanz mysite
auf die Checkmk-Version
1.6.0p13.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.6.0p10.cre
auf 1.6.0p13.cee
. Dies geschieht durch den Befehl omd update
,
welchen Sie weiter unten im Detail kennenlernen:

Nach dem Update können Sie die (eventuell) nicht mehr benötigte Version
1.6.0p10.cre
durch das Deinstallieren des entsprechenden Pakets
entfernen.
2. Vorbemerkung
Da es uns nicht möglich ist Ihre lokalen Anpassungen und jede von einem Drittanbieter hergestellte Erweiterung für Checkmk bei einem Update abzufangen und zu behandeln, sollten Sie Ihre Checkmk-Instanz vor einem Update auf deren Verwendung hin prüfen. Geben Sie den folgenden Befehl ein, um sich eine Übersicht über die sogenannte Local-Struktur zu verschaffen:
OMD[mysite]:~$ find ~/local -follow -type f
In einer frischen Installation von Checkmk würden Sie mit diesem Befehl derzeit
nur eine Datei namens README.TXT
finden. Alles was darüber hinaus
angezeigt wird, sollte - bei einem etwaigen Problem beim Update - bei Ihrer
Fehlerdiagnose berücksichtigt werden.
3. Update von Checkmk im Detail
3.1. Installationen neuer Versionen
Wie in der Einleitung beschrieben, ist der erste Schritt beim Update die Installation der gewünschten neuen Version von Checkmk. 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 20.04 (Focal Fossa):
root@linux# gdebi check-mk-enterprise-1.6.0p13_0.focal_amd64.deb
Die Liste der installierten Checkmk-Versionen können Sie jederzeit mit
dem Befehl omd versions
abrufen:
root@linux# omd versions
1.5.0p20.cre
1.5.0p24.cee
1.6.0p13.cee (default)
2020.06.10.cee
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 Defaultversion können Sie mit omd version
abfragen und
mit omd setversion
ändern:
root@linux# omd version
1.5.0p20.cre
root@linux# omd setversion 1.6.0p13.cee
root@linux# omd version
1.6.0p13.cee
Beim Akualisieren oder Verwalten von bestehenden Instanzen spielt die Defaultversion
keine Rolle. Der omd
-Befehl startet immer automatisch in der zur angegebenen
Instanz passenden Version.
Eine Auflistung der aktuellen Instanzen und welche Versionen diese verwenden
liefert der Befehl omd sites
:
root@linux# omd sites
SITE VERSION COMMENTS
mysite 1.5.0p24.cre
test 1.6.0p13.cee default version
3.2. Durchführen des Updates
Nachdem die gewünschte neue Version installiert ist, können Sie das
Update der Instanz durchführen. Dazu sind keine root
-Rechte
erforderlich. Machen Sie das Update am besten als Instanzbenutzer:
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:

Beim Update von einer Raw Edition auf die Checkmk Enterprise Standard Edition werden Sie sicherheitshalber noch
einmal auf diesen Umstand hingewiesen:

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:
2020-06-16 14:25:20 - Updating site 'mysite' from version 1.6.0p10.cre to 1.6.0p13.cee...
* Installed dir var/check_mk/rrd
* Installed dir var/check_mk/reports
* Installed dir var/check_mk/reports/archive
* Installed file etc/logrotate.d/cmc
* Installed file etc/logrotate.d/mknotifyd
* Installed file etc/logrotate.d/liveproxyd
Executing update-pre-hooks script "cmk.update-pre-hooks"...OK
Output: Initializing application...
Loading GUI plugins...
Updating Checkmk configuration...
+ Rewriting WATO tags...
+ Rewriting WATO hosts and folders...
+ Rewriting WATO rulesets...
+ Rewriting autochecks...
+ Cleanup version specific caches...
Done
Finished update.
Wenn alles erfolgreich durchgelaufen ist, ist die Instanz auf die neue Version umgeschaltet …
OMD[mysite]:~$ omd version
1.6.0p13.cee
… und kann gestartet werden:
OMD[mysite]:~$ omd start
3.3. Inkompatible Änderungen
Softwareentwicklung bedeutet Änderung. Und da wir immer daran arbeiten, Checkmk 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 Check-Plugins, 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 Checkmk inklusive einer Suchfunktion finden Sie online in unseren Werks. Noch praktischer ist aber die in Checkmk eingebaute Funktion zur Recherche in den Versionshinweisen. Zu diesen gelangen Sie mit einem Klick auf die Versionsnummer links oben in der Seitenleiste:

Checkmk 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 Auflistung über die komplette Historie der Änderungen inklusive einer Suchfunktion:

3.4. 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:
Aktualisieren von Vorgabedateien unter
etc/
undvar/
, also solchen Dateien, die beiomd create
erzeugt wurden.Umschalten der Version auf die Zielversion durch Ändern des symbolischen Links
version
, welcher sich im Site-Verzeichnis befindet.Nachbearbeitungen durch verschiedene Pakete (z.B. Checkmk). 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 Checkmk gegenüber klassischen Software-Installationen: Checkmk hilft Ihnen, alle Standard-Konfigurationsdateien 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 Checkmk 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 Checkmk 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 Checkmk, beide Änderungen automatisch zusammenzuführen (mergen). Dies geschieht mit den gleichen Methoden, die auch Versionskontrollsysteme verwenden.
Am wenigsten Probleme gibt es immer dann, wenn Ihre und Checkmks Ä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 Checkmk 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:
d | Dies zeigt Ihnen die Unterschiede zwischen der neuen Defaultversion der Datei und Ihrer Version in Form eines "unified diff" ( |
y | Dies ist ähnlich, zeigt aber ausgehend von der früheren Defaultversion, welche Änderungen Sie an der Datei gemacht haben. |
n | Diese dritte Option schließt quasi das Dreieck und zeigt die Änderungen, welche Checkmk an der Datei vornehmen möchte. |
t | Drü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 Checkmk das Mergen erneut. |
k | Hier 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. |
r | So stellen Sie Ihre Datei im Ausgangszustand wieder her und verzichten auf das Update von Checkmk für diese Datei. Möglicherweise notwendige Anpassung müssen Sie selbst vornehmen. |
i | Installieren der neuen Defaultdatei: Ihre Änderungen an der Datei gehen verloren. |
s | Wenn 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. |
a | Abbruch 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 Checkmk Ihre Entscheidung braucht. Dies sind teils sehr ungewöhnliche Situationen, die aber trotzdem korrekte Behandlung brauchen. Checkmk 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 Checkmk 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. Checkmk 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. Checkmk 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 Checkmk dabei, dass die Datei fehlt. |
Missing | Sie haben eine Datei gelöscht, an der sich in der neuen Version Änderungen ergeben haben. Checkmk legt die Datei nicht neu an, warnt Sie aber durch diese Ausgabe. |
Permissions | Checkmk hat die Berechtigungen einer Datei aktualisiert, da in der neuen Version andere Rechte gesetzt sind. |
3.5. Update ohne Benutzerinteraktion
Möchten Sie das Softwareupdate von Checkmk 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 nachomd
verhindert alle Fragen vom Typ „Sind Sie sicher…“.Die Option
--conflict=
direkt nachupdate
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 Checkmk 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.6.0p13.cee
:
root@linux# omd stop mysite ; omd -f -V 1.6.0p13.cee update --conflict=install mysite && 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 versuchen wollen.
Falls Sie sicher sind, dass Sie nur eine einzige Checkmk-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:
#!/bin/bash
SITE=$(omd sites --bare)
VERSION=1.6.0p13.cee
omd stop $SITE
omd -f -V $VERSION update --conflict=install $SITE && omd start $SITE
4. Docker-Container aktualisieren
Die Aktualisierung von Checkmk ab Version VERSION[1.5.0p13] lässt sich ebenfalls sehr einfach bewerkstelligen und wird in dem Artikel Checkmk-Server im Docker-Container beschrieben.
Sollten sie einen Checkmk-Container vor Version VERSION[1.5.0p13] updaten wollen, sind einige zusätzliche Schritte notwendig die in Detailliertes Update für frühere Checkmk-Images beschrieben werden.
5. Upgrade der Free Edition auf die Vollversion
Haben Sie Ihre erste Installation von Checkmk mit der Free Edition gemacht? Sobald Sie eine Subskription der Standard Edition oder Managed Services Edition haben, können Sie Ihre bestehende Instanz einfach auf die Vollversion upgraden.
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
upgraden. 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
Free Edition völlig identisch mit der Vollversion. Daher ergeben sich durch das
Upgrade 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 Checkmk.
5.1. Upgrade der Checkmk-Appliance
Auch eine Demo-Appliance können Sie ohne Datenverlust auf eine Vollversion mit einer der Enterprise Editions upgraden:
Spielen Sie auf der Appliance über deren Web-GUI eine aktuelle Firmware der Vollversion ein.
Installieren Sie in der Versionsverwaltung der Appliance eine Vollversion einer der Enterprise Editions.
Stellen Sie in der Instanzverwaltung der Appliance die Instanzen auf diese Version um.
6. Upgrade der Raw Edition auf eine der Enterprise Editions
6.1. Einleitung
Auch ein Upgrade der Checkmk Raw Edition auf eine der Enterprise Editions ist möglich. Auch hier ist das
Vorgehen wie gehabt: Gewünschtes Paket installieren und Instanzen
mit
omd update
umstellen.
Da der Raw Edition etliche Module und Features der Enterprise Editions fehlen, gibt es allerdings nach der Umstellung ein paar Dinge zu beachten. Der entscheidende Punkt ist, dass beim Anlegen von neuen Instanzen der Raw Edition bzw. Enterprise Editions unterschiedliche Defaulteinstellungen gesetzt werden.
6.2. Nagios vs. CMC
Da die Raw Edition nur Nagios als Kern unterstützt, ist dieser bei Instanzen,
die mit der Raw Edition erstellt wurden voreingestellt. Diese Einstellung bleibt
beim Upgrade auf die Checkmk Enterprise Standard Edition erhalten. Das bedeutet, dass Sie nach einem Upgrade
zunächst weiterhin mit Nagios als Kern fahren. Eine Umstellung auf den CMC
erfolgt mit
omd config
und wird in einem
eigenen Artikel beschrieben.
6.3. RRD-Format
Die Enterprise Editions unterstützen ein alternatives Format für die Speicherung historischer Messdaten, welches deutlich weniger Platten-I/O erzeugt. Bei neuen Enterprise Editions-Instanzen ist dies automatisch voreingestellt. Raw Edition-Instanzen werden auch hier beim Upgrade nicht automatisch umgestellt. Wie das Umstellen geht, beschreibt ein eigener Abschnitt im Artikel über Messwerte und Graphen.
6.4. Alarmspooler
Die Raw Edition hat keinen Alarmspooler. Deswegen ist dieser nach dem Umstieg auf eine der Enterprise Editions ausgeschaltet. Wie dieser eingeschaltet werden kann, erfahren Sie hier.
7. Deinstallieren von Checkmk
7.1. Übersicht
Das Deinstallieren von nicht mehr benötigten Checkmk-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 Checkmk-Versionen, die von keiner Instanz mehr verwendet werden!
Nicht mehr benötigte Checkmk-Instanzen können Sie einfach mit omd rm
entfernen (und dabei alle Daten löschen!):
root@linux# omd rm mysite
7.2. SLES, RedHat, CentOS
So finden Sie bei RPM-basierten Systemen heraus, welche Checkmk-Pakete installiert sind:
root@linux# rpm -qa | grep check-mk
check-mk-enterprise-1.5.0p24-el7-38.x86_64
check-mk-enterprise-1.6.0p13-el7-38.x86_64
check-mk-enterprise-2020.06.10-el7-38.x86_64
check-mk-raw-1.5.0p20-el7-38.x86_64
Das Löschen geschieht mit rpm -e
:
root@linux# rpm -e check-mk-enterprise-1.5.0p24-el7-38.x86_64
7.3. Debian, Ubuntu
So finden Sie heraus, welche Pakete installiert sind:
root@linux# dpkg -l | grep check-mk
ii check-mk-enterprise-1.5.0p24 0.bionic amd64 Check_MK is a full featured system monitoring
ii check-mk-enterprise-1.6.0p13 0.bionic amd64 Checkmk - Best-in-class infrastructure & application monitoring
ii check-mk-enterprise-2020.06.10 0.bionic amd64 Checkmk - Best-in-class infrastructure & application monitoring
ii check-mk-raw-1.5.0p20 0.bionic amd64 Check_MK is a full featured system monitoring
Die Deinstallation geschieht mit dpkg --purge
:
root@linux# dpkg --purge check-mk-enterprise-1.5.0p24
(Lese Datenbank ... 174744 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von check-mk-enterprise-1.5.0p24 (0.bionic) ...
Löschen der Konfigurationsdateien von check-mk-enterprise-1.5.0p24 (0.bionic) ...
8. Diagnosemöglichkeiten
Sollte es beim Update von Checkmk mal zu einem Fehler kommen, liegt diesem zumeist eine der folgenden drei Ursachen zugrunde:
Sie haben eine inkompatible Erweiterung installiert.
Es befinden sich inkompatible Skripte in der Local-Struktur von Checkmk.
Der durch ein inkompatibles Werk notwendige manuelle Eingriff wurde nicht vorgenommen.
Eine Liste aller in installierten Erweiterungspakete und auch nicht paketierter Dateien zeigt Ihnen Checkmk nach der Eingabe der folgenden beiden Befehle an:
OMD[mysite]:~$ mkp list
OMD[mysite]:~$ mkp find
Überprüfen Sie die Ausgaben dieser Befehle auf Erweiterungen und Dateien, die eventuell schon lange in Ihrer Checkmk-Site liegen und gar nicht mehr benötigt werden (weil deren Funktion bspw. inzwischen direkt von Checkmk erbracht wird) oder die Sie gar nicht mehr zuordnen können. Um deren Einfluss auf das Update zu prüfen, können Sie Kopien dieser Erweiterungen und Dateien anlegen und zumindest vorübergehend aus Ihrer Check-Instanz entfernen.
9. 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 Checkmk-Version. |
/omd/versions | Unterhalb dieses Verzeichnisses existiert für jede installierte Checkmk-Version ein Unterverzeichnis. Die Dateien gehören |
/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 Checkmk-Instanzen. Dies ist ein symbolischer Link in das |