Skip to content

Releases: ITkub/co37

CO-37 0.45.1

Choose a tag to compare

@mike-139 mike-139 released this 24 Sep 05:33

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

Choose a tag to compare

@mike-139 mike-139 released this 24 Sep 05:06

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

Choose a tag to compare

@mike-139 mike-139 released this 24 Sep 04:39

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

Choose a tag to compare

@mike-139 mike-139 released this 24 Sep 04:28

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

Choose a tag to compare

@mike-139 mike-139 released this 24 Sep 04:15

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

Choose a tag to compare

@mike-139 mike-139 released this 23 Sep 15:31

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

Choose a tag to compare

@mike-139 mike-139 released this 23 Sep 15:08

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.
  • Anleitung CHECKMK-MONITORING.md.

Einrichtung: siehe CHECKMK-MONITORING.md. Am laufenden Betrieb ändert sich
ohne diese Schritte nichts.

CO-37 0.39.0

Choose a tag to compare

@mike-139 mike-139 released this 21 Sep 06:56

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

Choose a tag to compare

@mike-139 mike-139 released this 10 Sep 15:10

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

Choose a tag to compare

@mike-139 mike-139 released this 10 Sep 10:06

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.