70 lines
3.6 KiB
Markdown
70 lines
3.6 KiB
Markdown
---
|
||
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. |