Fuer den Betrieb fehlte bisher eine Rolle: "user" meldet zwar Daten, bleibt in der Buero-Visualisierung aber unsichtbar, weil sie nie einen Schreibtisch bekommt. Der Ping-Check aus check_fds.sh (Weg 3 im README) lief deshalb als "user" und tauchte im Buero nicht auf. "ops" fuellt die Luecke: die Schreibtischvergabe in AgentRepository::register() greift automatisch, sobald die Rolle erlaubt ist - nur "user" bleibt ohne Platz. Der CHECK-Constraint auf agents.role braucht dafuer eine eigene Migration. Ein Edit von 001_initial.sql wuerde nur frische Datenbanken erreichen: bestehende Installationen haben die Migration laut schema_migrations laengst angewandt und wuerden bei role='ops' weiterhin abbrechen. SQLite kann CHECK nicht per ALTER TABLE aendern, 004 baut die Tabelle deshalb neu (Verfahren aus der SQLite-Doku, foreign_keys kurz aus, weil tickets.assignee_agent_id auf agents zeigt). Im Frontend bekommt die Rolle Label "OPs", eine Akzentfarbe und ein Zahnrad als Schreibtisch-Deko - ohne Eintrag in der ROLES-Map rendert der Avatar grau und ohne Label. Neu ist ausserdem register-ops-agent.sh neben der docker-compose.yml: es liest Admin-Key und Basis-URL aus der .env, registriert den lokalen OPs-Agenten und schreibt den nur einmalig ausgegebenen API-Key mit chmod 600 nach monitor-api.conf - also genau die beiden Schritte aus Weg 3, die hosts.conf und credentials.conf nicht abdecken. Eine vorhandene monitor-api.conf ueberschreibt es nicht, und ein zweiter Agent gleichen Namens (der einen weiteren der acht Schreibtische belegen wuerde) wird vorher abgefangen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
21 lines
1 KiB
Text
21 lines
1 KiB
Text
# Zugangsdaten, mit denen check_fds.sh die Ping-Ergebnisse zusaetzlich per REST an die
|
|
# monitor-API meldet (POST /api/v1/systems/{id}/status, siehe API.md Abschnitt "Systeme").
|
|
#
|
|
# Noetig ist das, wenn check_fds.sh auf einem anderen Rechner laeuft als die API: der
|
|
# Legacy-Import liest status.txt als lokale Datei und erreicht sie dann nicht.
|
|
#
|
|
# Diese Datei nach "monitor-api.conf" neben check_fds.sh kopieren und ausfuellen. Fehlt sie
|
|
# oder bleibt ein Wert leer, meldet check_fds.sh wie bisher nur nach status.txt und per Mail.
|
|
#
|
|
# Der Key gehoert einem eigens registrierten Agenten der Rolle "ops" (Issue #66), der in der
|
|
# Buero-Visualisierung als "OPs" an einem Schreibtisch sitzt. Am einfachsten legt
|
|
# register-ops-agent.sh beides an - Agent und diese Datei; der Key wird nur bei der
|
|
# Registrierung einmalig ausgegeben.
|
|
#
|
|
# Enthaelt ein Secret: chmod 600 monitor-api.conf
|
|
|
|
# Basis-URL der API, ohne abschliessenden Slash (Host-Port des api-Service)
|
|
MONITOR_API_BASE="http://monitor.example.lan:8091"
|
|
|
|
# API-Key des registrierten Agenten
|
|
MONITOR_API_KEY=""
|