Anlass war die Frage, wozu CMK_IMAGE neben Edition und Version
ueberhaupt noch noetig ist. Antwort: es ist der einzige Wert, den
compose und die systemd-Units lesen. Edition und Version sind reine
Vorgaben fuer den Downloader und wirken erst ueber "image pull".
Ableiten laesst sich CMK_IMAGE nicht, weil dieselbe Version je nach
Bezugsweg voellig anders heisst - docker.io/..., registry.checkmk.com/...
oder localhost/... bei einem aus dem Tarball geladenen Image.
Daraus folgt eine Falle, die bisher nirgends auffiel: wer Edition auf
"enterprise" stellt, CMK_IMAGE aber auf dem Raw-Image stehen laesst,
betreibt weiter Raw. Genau dieser Zustand kam in der Praxis vor.
image_consistency_check vergleicht deshalb Name und Tag von CMK_IMAGE
mit Edition und Version und meldet Abweichungen - in "image status",
im allgemeinen "status" und im Einstellungsmenue direkt nach dem
Aendern von Edition oder Version, dort gleich mit dem Angebot, das
Image zu holen. Aus Tarballs geladene Images (localhost/...) gelten
als stimmig, solange Name und Tag passen; die Editionsaliase werden
beruecksichtigt, "pro" passt also zu check-mk-enterprise.
Die Beschriftungen in den Einstellungen sagen jetzt, wer was tut:
CMK_IMAGE VERWENDETES Image - setzt "image pull"
CMK_EDITION Edition (nur Vorgabe, wirkt ueber "image pull")
CMK_VERSION Version (nur Vorgabe, wirkt ueber "image pull")
Vier Faelle geprueft: abweichende Edition, abweichende Version,
stimmiger Zustand und aus Tarball geladenes Image.
Dokumentiert als Abschnitt 8.7 in beiden Sprachfassungen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5
7a93dd5dbf