Initial: Mesh-Configs vom 03.09.2026 01:23

2026-09-03 01:23:55 +02:00
commit 4b65134f8c
797 changed files with 146197 additions and 0 deletions
@@ -0,0 +1,70 @@
+---
+name: hermes-fleet-maintenance
+description: "Update/maintain Hermes agents in the mesh (weekly sync)."
+version: 1.0.0
+author: Hermes Agent
+platforms: [linux]
+related_skills: [multi-agent-mesh, hermes-agent]
+---
+
+# Hermes-Fleet-Maintenance
+
+Wöchentliche bzw. bei Bedarf ad-hoc Wartung ALLER Hermes-Agenten im Mesh (VPS/Master + Unraid + Switch + Laptop) auf denselben Stand bringen. Ergänzt `multi-agent-mesh` (Orchestrierung) um den konkreten **Update-Ablauf und den Cadence-Entscheid**.
+
+## Entscheid (NUTZERWUNSCH 2026-08-06)
+
+- **Wöchentlich** (Montag) alle Agenten synchron updaten — NICHT täglich (Overhead 7×, kein Gewinn).
+- 🔥 **Sicherheits-Hotfixes** (SSH, Auth, Keys, ZeroTier) SOFORT ziehen, keine Wochen-Frist.
+- Vor dem Durchziehen Changelog kurz auf **Breaking-Changes** prüfen.
+- Sync-Rhythmus hält das Mesh kompatibel (keine Versions-Drift zwischen Agenten).
+- Agenten updaten **nur** auf Anweisung des Masters (passt zu multi-agent-mesh Update-Kontrollpolitik).
+
+## Ablauf: Versions-Check + Update
+
+### 1. Ist-Stand erfassen
+Alle vier parallel abfragen (pro Agent tauschen IP/Name):
+
+```bash
+# Master lokal:
+hermes --version | head -1
+# Remotes (Passwort-Auth — Key-Auth ist im Mesh NICHT eingerichtet):
+sshpass -p 'PW' ssh -o ConnectTimeout=8 -o StrictHostKeyChecking=no mehlzoerwer@<ZT-IP> \
+  '~/.local/bin/hermes --version 2>/dev/null | head -1; ~/.local/bin/hermes update --check 2>&1 | tail -2'
+```
+
+Notizen:
+- Hermes liegt auf ALLEN Remotes unter `~/.local/bin/hermes` (nicht `/usr/local/bin`).
+- `hermes update --check` antwortet `⚕ Update available` oder `✓ Already up to date`.
+- **Key-Auth (BatchMode) schlägt fehl → `Permission denied (publickey,password)`.** Immer Passwort via `sshpass` nutzen (Passwort ist im Mesh einheitlich).
+
+### 2. Update durchziehen (parallel, `--yes`)
+`--yes` überspringt interaktive Prompts (Config-Migration/Stash) — nötig für non-interaktives SSH.
+
+```bash
+# Master lokal:
+hermes update --yes 2>&1 | tail -15
+# Je Remote:
+timeout 240 sshpass -p 'PW' ssh -o ConnectTimeout=10 -o StrictHostKeyChecking=no mehlzoerwer@<ZT-IP> \
+  '~/.local/bin/hermes update --yes 2>&1' 2>&1 | grep -vi warning | tail -8
+```
+
+Erfolgsmarker: `✓ Update complete!` und `✓ Configuration is up to date`. (3 Hosts parallel + Master = ~30-60s.)
+
+### 3. Verifizieren
+`hermes --version` auf allen 4 erneut — Ziel: identische Version (z.B. `v0.20.0`). Differenz = Versions-Drift → nachziehen.
+
+## Automatisierung: Wochen-Watchdog (no_agent + Telegram)
+
+Bewährtes Muster für den Montags-Rhythmus: **ein re-runnable Script** + **`no_agent`-Cron** (kein LLM-Tokenverbrauch), das sich nur meldet wenn etwas zu tun/melden war.
+
+- Script im Repo: `scripts/update_fleet.sh` (fertiges Vorlage-Script — Werte: IPs, `PW`, Pfad anpassen).
+- Cron: `no_agent=true` (Script-STDOUT = Nachricht), `deliver=telegram`, z.B. `0 6 * * 1`.
+- **Silent-Watchdog-Semantik:** leeres STDOUT = still (nichts senden); nicht-leer = Nachricht an Nutzer.
+
+## ⚠️ Fallstricke
+
+- **Cron `script`-Pfad MUSS relativ zu `~/.hermes/scripts/` sein** — nur den Dateinamen angeben (`update_fleet.sh`), nicht `/root/.hermes/scripts/...` → sonst Fehler `Script path must be relative to ~/.hermes/scripts/`. Script dort ablegen + `chmod +x`.
+- Cron **immer erst manuell testen** (`/root/.hermes/scripts/update_fleet.sh`) bevor man ihn plant.
+- `hermes update` **killt laufende Agenten/Gateway** — nicht mitten in kritischer Arbeit auf dem Ziel-Host ziehen.
+- Ausgabe mit `grep -vi warning` bereinigen — sshpass-Meldungen (Warnung vor Passwort auf Kommandozeile) sind Lärm.
+- `timeout` vorbehalten, falls ein Remote hängt — verhindert dass ein Host den ganzen Batch blockiert.