Beim Upgrade einer Checkmk-Umgebung von Version 2.4 auf 2.5 kann es in Distributed-Monitoring-Umgebungen zu einem Fehler während des Site-Updates kommen.
Das Upgrade läuft zunächst weitgehend durch und bricht erst am Ende bei der Generierung der Core-Konfiguration ab:
44/44 Update core config...
Generating configuration for core (type nagios)...
Configuration Error: Error creating configuration: 'list' object has no attribute 'get'
+ "Update core config" failed
subprocess.CalledProcessError:
Command '['cmk', '-U']' returned non-zero exit status 1.Die eigentliche Ursache liegt dabei nicht direkt im Nagios-Core, sondern in einer alten Checkmk-Konfiguration, die in einer Distributed-Monitoring-Umgebung weiterhin im alten Datenformat vorhanden sein kann.
Ursache
Betroffen ist die Variable:
use_new_descriptions_forIn älteren Checkmk-Versionen konnte diese Einstellung als Liste gespeichert sein:
use_new_descriptions_for = [
'aix_memory',
'df',
'http',
'logwatch',
]Neuere Checkmk-Versionen erwarten dagegen ein Dictionary:
use_new_descriptions_for = {
'aix_memory': True,
'df': True,
'http': True,
'logwatch': True,
}Wird beim Upgrade weiterhin eine alte Liste eingelesen, versucht Checkmk intern auf diesem Objekt unter anderem .get() aufzurufen.
Eine Python-Liste besitzt diese Methode nicht. Das Ergebnis ist:
'list' object has no attribute 'get'Besonderheit bei Distributed Monitoring
In einer Distributed-Monitoring-Umgebung sollte die Ursache nicht einfach auf einer einzelnen Remote-Site korrigiert werden.
Die entsprechenden Konfigurationsdateien werden von der zentralen Checkmk-Site verwaltet und auf die Remote-Sites synchronisiert.
Eine manuelle Änderung ausschließlich auf einer Remote-Site würde daher möglicherweise beim nächsten Konfigurations-Sync wieder überschrieben.
Vor dem eigentlichen Major-Upgrade empfiehlt es sich außerdem, zunächst alle beteiligten Checkmk-Sites auf denselben aktuellen Patchstand innerhalb des alten Versionszweigs zu bringen.
Beispiel:
Zentrale: Checkmk 2.4.x
Remote 1: Checkmk 2.4.x
Remote 2: Checkmk 2.4.x
Remote 3: Checkmk 2.4.xErst anschließend sollte das Upgrade auf Checkmk 2.5 begonnen werden.
Alte Konfiguration suchen
Auf der zentralen Site kann geprüft werden, ob noch alte Listen vorhanden sind:
grep -R -n "use_new_descriptions_for = \[" \
~/etc/check_mk/conf.d/wato/Werden Treffer angezeigt, beispielsweise:
etc/check_mk/conf.d/wato/site01/global.mk
etc/check_mk/conf.d/wato/site02/global.mk
etc/check_mk/conf.d/wato/site03/global.mksind dort noch Konfigurationen im alten Format vorhanden.
Konfiguration sichern
Vor der Änderung sollten die betroffenen Dateien gesichert werden:
cd ~/etc/check_mk/conf.d/wato
cp -a site01/global.mk site01/global.mk.pre25
cp -a site02/global.mk site02/global.mk.pre25
cp -a site03/global.mk site03/global.mk.pre25Listen automatisch konvertieren
Bei größeren Listen ist eine manuelle Konvertierung unnötig fehleranfällig.
Mit Python können die vorhandenen Listen automatisch in Dictionaries umgewandelt werden:
python3 - <<'PY'
from pathlib import Path
import ast
import re
files = [
Path("site01/global.mk"),
Path("site02/global.mk"),
Path("site03/global.mk"),
]
for path in files:
text = path.read_text()
pattern = r"use_new_descriptions_for\s*=\s*(\[[\s\S]*?\])"
match = re.search(pattern, text)
if not match:
print(f"{path}: keine Liste gefunden")
continue
values = ast.literal_eval(match.group(1))
replacement = "use_new_descriptions_for = {\n"
replacement += "".join(
f" {value!r}: True,\n"
for value in values
)
replacement += "}"
path.write_text(
text[:match.start()] + replacement + text[match.end():]
)
print(f"{path}: {len(values)} Einträge konvertiert")
PYDanach sollte beispielsweise aus:
use_new_descriptions_for = [
'aix_memory',
'df',
'http',
]folgendes geworden sein:
use_new_descriptions_for = {
'aix_memory': True,
'df': True,
'http': True,
}Kontrolle
Anschließend erneut prüfen:
grep -R -n "use_new_descriptions_for = \[" \
~/etc/check_mk/conf.d/wato/ \
--exclude='*.pre25'Im Idealfall erscheint keine Ausgabe mehr.
Die Sicherungsdateien können natürlich weiterhin Treffer enthalten:
global.mk.pre25Diese Dateien werden von Checkmk nicht als aktive global.mk eingelesen.
Optional können die Backups aus dem WATO-Verzeichnis verschoben werden:
mkdir -p ~/var/backups/pre25-globalmk
mv ~/etc/check_mk/conf.d/wato/*/global.mk.pre25 \
~/var/backups/pre25-globalmk/Konfiguration testen
Noch auf der alten Checkmk-Version sollte anschließend geprüft werden, ob die Core-Konfiguration wieder fehlerfrei generiert werden kann:
cmk -UEine erfolgreiche Ausgabe sieht beispielsweise so aus:
Generating configuration for core (type nagios)...
Precompiling host checks...OK
Validating Nagios configuration...OKDanach:
cmk -RErwartet:
Generating configuration for core (type nagios)...
Precompiling host checks...OK
Validating Nagios configuration...OK
Restarting monitoring core...OKZusätzlich:
omd statusAlle relevanten Dienste sollten anschließend wieder als running angezeigt werden.
Konfiguration auf die Remote-Sites verteilen
Da es sich um Distributed Monitoring handelt, sollte die korrigierte Konfiguration anschließend regulär über die zentrale Checkmk-Site aktiviert und auf die Remote-Sites synchronisiert werden.
Auf einer Remote-Site kann danach erneut geprüft werden:
grep -R -n "use_new_descriptions_for = \[" \
~/etc/check_mk/conf.d/wato/ \
--exclude='*.pre25'Auch dort sollte keine aktive Liste mehr vorhanden sein.
Zusätzlich:
cmk -U
cmk -R
omd statusLaufen diese Prüfungen sauber durch, ist die Umgebung für das Major-Upgrade vorbereitet.
Upgrade-Reihenfolge im Distributed Monitoring
Beim Major-Upgrade sollte die Reihenfolge beachtet werden:
1. Remote-Sites auf Checkmk 2.5 aktualisieren
2. Funktion und Konfigurations-Synchronisierung prüfen
3. Zentrale Checkmk-Site zuletzt aktualisierenEin temporärer Mischbetrieb mit einer älteren Zentrale und bereits aktualisierten Remote-Sites ist für den Upgradevorgang vorgesehen.
Die umgekehrte Konstellation sollte vermieden werden.
Debian-Upgrade: Apache lädt noch altes PHP-Modul
Bei einem parallel durchgeführten Debian-Major-Upgrade kann zusätzlich ein weiterer Fehler auftreten.
Apache startet dann möglicherweise nicht mehr und meldet beispielsweise:
Cannot load /usr/lib/apache2/modules/libphp8.x.so into server:
No such file or directoryUrsache ist häufig, dass Apache weiterhin das PHP-Modul der vorherigen Debian-Version lädt.
Prüfen:
ls -l /etc/apache2/mods-enabled/php*
ls -l /etc/apache2/mods-available/php*
php -vDas alte Modul kann deaktiviert und die aktuelle PHP-Version aktiviert werden:
a2dismod php8.x
a2enmod php8.yDanach:
apache2ctl configtest
systemctl restart apache2
systemctl status apache2 --no-pagerWichtig ist, dass apache2ctl configtest anschließend meldet:
Syntax OKFazit
Schon wieder eine Menge Spaß für einen Samstag Vormittag… Der Fehler
'list' object has no attribute 'get'beim Upgrade von Checkmk 2.4 auf 2.5 kann in Distributed-Monitoring-Umgebungen durch alte Konfigurationsdaten in use_new_descriptions_for ausgelöst werden.
Entscheidend ist dabei, die Ursache auf der zentralen Site zu korrigieren und die Änderung anschließend regulär auf die Remote-Sites zu verteilen.
Der zuverlässige Ablauf ist damit:
Alle Checkmk-Sites auf aktuellen 2.4-Patchstand bringen
→ alte use_new_descriptions_for-Listen auf der Zentrale suchen
→ Listen in Dictionaries konvertieren
→ cmk -U und cmk -R testen
→ Konfiguration auf Remotes synchronisieren
→ Remotes auf Checkmk 2.5 aktualisieren
→ Zentrale zuletzt auf Checkmk 2.5 aktualisierenNach der Konvertierung kann der Upgrade-Schritt zur Core-Konfiguration wieder erfolgreich abgeschlossen werden:
Update core config...
Generating configuration for core...
Precompiling host checks...OK
Done (success)
Finished update.Disclaimer
Dieser Artikel wurde mit Unterstützung von dieser KI gemacht, von der gerade alle reden und die den RAM so teuer macht…
