Repository navigation
Releases: ITkub/co37
Release list
CO-37 0.45.1
CO-37 0.45.1
Fix: Hosts mit "Downtime auf alle Checkmk-Hosts" bekamen kein Piggyback,
weil ihre Checkmk-Host-Liste dabei leer bleibt. Der Server-Check nimmt in
diesem Fall jetzt den eigenen Hostnamen als Piggyback-Ziel (Annahme:
Checkmk-Host = CO-37-Hostname). Der Endpunkt /api/v1/monitoring gibt dafuer
checkmk_downtime_all mit aus.
CO-37 0.45.0
CO-37 0.45.0
Fix: Der Checkmk-Dienst "CO-37 Agent Version" ging auf UNKNOWN, sobald
der Agent aktuell war - das Skript gab die Zeile nur bei veralteter
Version aus. Jetzt meldet er OK ("aktuell") bzw. WARN ("veraltet") und
liefert immer Daten.
CO-37 0.44.0
CO-37 0.44.0
Die Piggyback-Dienste (Host-Sicht je Agent-Host) tragen jetzt den Praefix
"CO-37 Agent": CO-37 Agent Kontakt, CO-37 Agent Updates, CO-37 Agent
Neustart, CO-37 Agent Version. Damit heben sie sich am Checkmk-Host von
den CO-37-Server-Diensten ab - besonders wenn der CO-37-Server selbst ein
ueberwachter Host ist.
CO-37 0.43.0
CO-37 0.43.0
Fix: Das Checkmk-Piggyback haengte die Sicht eines CO-37-Hosts an ALLE
seine Checkmk-Zuordnungen. Bei Hosts, die mehrere Checkmk-Hosts betreffen
(z. B. ein Hypervisor, der seine VMs beim Patchen in Downtime setzt),
landeten dessen Dienste auf fremden Hosts und kollidierten mit deren
eigenen Agenten. Piggyback geht jetzt nur an den Checkmk-Host, der dem
CO-37-Host selbst entspricht (namensgleicher Eintrag, sonst der einzige).
Mehrdeutige Faelle werden am CO-37-Host als WARN gemeldet und
uebersprungen. Die Downtime-Zuordnung bleibt unveraendert.
CO-37 0.42.0
CO-37 0.42.0
Fix: Der Checkmk-Local-Check (co37_monitoring) lief bei aktivem
HTTPS-Zwang auf 403. Der Check spricht das Backend unverschluesselt
ueber 127.0.0.1 an - CO-37 nimmt selbst kein TLS an -, und der
HTTPS-Zwang wies das ab. /api/v1/monitoring ist jetzt, wie /api/health,
ueber Loopback ausgenommen. Der Endpunkt bleibt durch Loopback UND
lokales Token abgesichert (sonst 404).
CO-37 0.41.0
CO-37 0.41.0
Neu: Checkmk-Überwachung von CO-37 selbst — die Gegenrichtung zur
bestehenden Downtime-Anbindung. Checkmk sieht jetzt den Zustand von
CO-37 und ob die Agenten auf den Zielhosts laufen.
Drei Bausteine, einzeln nutzbar:
- CO-37-Server: ein Local-Check meldet Backend, Flotte und Lizenz.
- Agent-Hosts: ein kleiner Check je Host meldet direkt, ob der
CO-37-Agent läuft — auch dann, wenn der CO-37-Server gerade steht
(Linux und Windows). - Piggyback (optional): Zusatzsicht je Host aus CO-37 (Kontakt,
Updates, Neustart), über die in CO-37 hinterlegte Checkmk-Verknüpfung.
Absicherung: neuer, rein lokaler Endpunkt GET /api/v1/monitoring. Er
verlangt Loopback UND ein lokales Token (data/monitor.token, 600);
sonst 404. In der Antwort steht kein Geheimnis — keine Agent-Tokens,
kein Lizenzschlüssel, kein Kundenname.
Auslieferung: Die Skripte liegen unter packaging/checkmk/ und werden mit
jedem Update automatisch mitgeliefert. Nach dem Update auf 0.41.0 nur
noch den install-Befehl je Check ausführen.
Installation und Schwellen: siehe CHECKMK-MONITORING.md.
CO-37 0.40.0
CO-37 0.40.0 — Checkmk-Überwachung
Checkmk kann CO-37 jetzt selbst überwachen (Gegenrichtung zur bisherigen
Downtime-Anbindung).
Neu:
- Rein lokaler Endpunkt /api/v1/monitoring als Datenquelle für Checkmk.
Nur über Loopback erreichbar UND durch ein lokales Token geschützt
(data/monitor.token, wird beim Start automatisch erzeugt). Von außen —
auch über einen Reverse Proxy auf demselben Host — nicht erreichbar
(404). Die Antwort enthält keine Geheimnisse. - Mitgelieferte Checkmk-Checks unter checkmk/:
- co37_monitoring: Self-Health, Agents online, offene/sicherheits-
relevante Updates, Neustart nötig, veraltete Agents, Lizenz, eigenes
Update. Plus optionale Piggyback-Sicht je verwaltetem Host. - co37_agent (Linux) / co37_agent.ps1 (Windows): prüfen direkt auf dem
Zielhost, ob der Agent läuft — unabhängig vom CO-37-Server.
- co37_monitoring: Self-Health, Agents online, offene/sicherheits-
- Anleitung CHECKMK-MONITORING.md.
Einrichtung: siehe CHECKMK-MONITORING.md. Am laufenden Betrieb ändert sich
ohne diese Schritte nichts.
CO-37 0.39.0
0.39.0 — Mehr Freibetrag, Reload-Balken-Fix
Freikontingent ohne Schlüssel von 10 auf 15 Hosts erhöht (Additional Use
Grant in der Lizenz entsprechend angepasst). Damit sind Homelabs und
kleine Umgebungen großzügiger abgedeckt.
Fehlerbehebung: Der orange „Neu laden"-Balken erschien fälschlich nach
einer abgelaufenen Sitzung („updated to undefined"), weil /api/health die
Version nur an Angemeldete herausgibt. Er wird jetzt nur noch bei einer
echten Versionsänderung angezeigt.
Keine Schema-Änderung.
Installation / Update
Über die Oberfläche: ZIP + .sig unter Einstellungen → Update einspielen.
Mit aktivem GitHub-Update-Bezug: „Update suchen" → „Holen" → auslösen.
CO-37 0.38.4
0.38.4 — Kernel-Neustart auf Proxmox/Debian erkennen
Fehlerbehebung. Nach einem Kernel-Update auf Proxmox VE (und knappen
Debian-Systemen ohne update-notifier-common) meldete der Agent keinen
ausstehenden Neustart, weil dort weder /var/run/reboot-required noch ein
anderes Standardwerkzeug antwortet. Der Agent vergleicht jetzt zusätzlich
den laufenden Kernel mit den in /boot installierten und meldet einen
Neustart, sobald ein neuerer Kernel installiert, aber noch nicht gebootet
ist.
Reiner Agent-Fix, keine Schema-Änderung.
Installation / Update
Über die Oberfläche: ZIP + .sig unter Einstellungen → Update einspielen.
Mit aktivem GitHub-Update-Bezug: „Update suchen" → „Holen" → auslösen.
CO-37 0.38.3
0.38.3 — Unterbereiche
Bereiche lassen sich jetzt unter einem Bereich anlegen (eine Ebene tief).
In der Übersicht erscheinen die Unterbereiche eingerückt unter ihrem
Oberbereich. Ein Host gehört weiterhin zu genau einem Bereich – Ober-
oder Unterbereich; jeder Bereich behält seinen eigenen Sammel-Zeitplan
ohne Vererbung. Ein Oberbereich lässt sich erst löschen, wenn keine
Unterbereiche mehr daran hängen.
Schema 23: Die Datenbank wird beim ersten Start automatisch migriert.
Installation / Update
Über die Oberfläche: ZIP + .sig unter Einstellungen → Update einspielen.
Mit aktivem GitHub-Update-Bezug: „Update suchen" → „Holen" → auslösen.
Die .sig-Datei wird zur Signaturprüfung gebraucht, die .sha256 nur zum
Abgleich von Hand.