Laufen check_fds.sh und die API auf verschiedenen Rechnern, erreicht der
Legacy-Import die API nie: SystemController::index() liest MONITOR_STATUS_FILE
als lokale Datei, waehrend status.txt auf dem Ping-Host liegt. Der
LegacyStatusFileReader liefert dann stillschweigend ein leeres Array und der
System-Monitor zeigt dauerhaft "Keine Systeme gemeldet" - ohne Fehlermeldung,
die auf die Ursache hinweisen wuerde.
check_fds.sh meldet die Ping-Ergebnisse jetzt zusaetzlich per
POST /api/v1/systems/{id}/status (online -> ok, offline -> error) und schreibt
status.txt unveraendert weiter. Die Zugangsdaten stehen in monitor-api.conf
(Vorlage: monitor-api-sample.conf); fehlt die Datei, bleibt das Verhalten
unveraendert. Eine unerreichbare API bricht den Check nicht ab, sondern
protokolliert nur eine Warnung.
Die System-ID wird aus dem Hostnamen slugifiziert, weil der Router auf dem
rohen, nicht dekodierten Pfad matcht - "Nextcloud(intern)" landete sonst
prozentkodiert in der Datenbank. Der lesbare Name geht im Feld "name" mit.
Das README beschreibt den kombinierten Weg als "Weg 3" und weist bei Weg 1
darauf hin, dass der Legacy-Import eine lokale Datei erwartet.
Ausserdem zwei Fehler im selben Skript behoben:
- Pfade werden relativ zum Skript statt zum Arbeitsverzeichnis aufgeloest.
- Die letzte Zeile der hosts.conf wurde ohne abschliessenden Zeilenumbruch
stillschweigend verschluckt, ein zuletzt angehaengter Host also nie geprueft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
README erklaert jetzt beide Wege (hosts.conf-Ping-Ueberwachung und
direkte Statusmeldung per REST-API), damit neue Systeme im
System-Monitor auftauchen. hosts-sample.conf bekommt dazu einen
Format-Hinweis; check_fds.sh ueberspringt dafuer Kommentar-/Leerzeilen
in hosts.conf, statt sie faelschlich als Host misszuinterpretieren.
