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):

# 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.

# 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.

3.6 KiB Raw Blame History Unescape Escape