diff --git a/worklog-2026-07-23-tts-anleitung-poller.md b/worklog-2026-07-23-tts-anleitung-poller.md new file mode 100644 index 0000000..648ee3d --- /dev/null +++ b/worklog-2026-07-23-tts-anleitung-poller.md @@ -0,0 +1,126 @@ +# Worklog 2026-07-23 — #33 barby-tts-api Rechte + #35 anleitung-poller + +## Wichtiger Vorab-Fund: hub_bash läuft NICHT auf hub.koerners.org +Der MCP-Tool `hub_bash` führt Befehle auf **jump.panel1.de** (49.13.209.112) aus, nicht auf +`hub.koerners.org` (103.241.51.192). Für Aufgabe #33 musste von jump per `ssh hub.koerners.org` +weitergesprungen werden. Aufgabe #35 stellte sich heraus als bereits auf jump.panel1.de deployt +(SKILL.md nennt es "Jump Hub Produktion" — Verwechslungsgefahr bleibt bestehen, siehe +reference-hub-topology.md). + +--- + +## #33 — barby-tts-api.service Leserechte (auf hub.koerners.org) + +**Problem:** Dienst `barby-tts-api.service` läuft als User `cloud`, Verzeichnis +`/opt/credentials` ist `drwx------ root:root` (700) → `PermissionError: [Errno 13]`. + +**Exakte Ursache (aus Code + journalctl):** +`/opt/scripts/barby-tts-api.py` Zeile 24: +```python +CF_ACCT = open("/opt/credentials/cloudflare-account-id").read().strip() +``` +Datei selbst war bereits `644` (world-readable), aber der Verzeichnis-Zugriff (700) blockierte +jeden Traversal für `cloud`. Die zweite Credential (`/opt/credentials/gcp/code-barby-workspace-key.json`, +Zeile 10/49) war KEIN Problem — das gcp-Unterverzeichnis ist `755` und die Datei bereits +`cloud:cloud` — kein Handlungsbedarf dort. + +**Backup (vorher):** +``` +/home/cloud/backups/acl-opt-credentials-before-202607231707.txt +# file: /opt/credentials user::rwx group::--- other::--- +# file: /opt/credentials/cloudflare-account-id user::rw- group::r-- other::r-- +``` + +**Änderung (minimal, ACL statt chmod):** +```bash +sudo apt-get install -y acl # setfacl war nicht installiert +sudo setfacl -m u:cloud:x /opt/credentials # NUR Traverse, kein Read +sudo setfacl -m u:cloud:r /opt/credentials/cloudflare-account-id # NUR diese eine Datei +``` + +**Danach (getfacl):** +``` +/opt/credentials: user:cloud:--x (mask --x) +/opt/credentials/cloudflare-account-id: user:cloud:r-- (mask r--) +``` +Kein `chmod`, kein world-readable, kein Zugriff auf andere Dateien im Verzeichnis (`--x` erlaubt +nur "durchqueren", kein `ls`, kein Read anderer Files). + +**Verifikation:** +- `sudo -u cloud cat /opt/credentials/cloudflare-account-id` → liest die Datei (vorher Permission denied) +- `systemctl start barby-tts-api.service` → `active (running)` +- `curl localhost:3097/health` → `{"ok":true,"service":"barby-voice",...}` +- Echter TTS-Testcall: `POST /v1/audio/speech {"input":"Test eins zwei drei","voice":"leda"}` + → HTTP 200, 8352 Bytes, valides MP3 (MPEG Layer III, 24kHz) — abgespielt/geprüft, danach gelöscht. + +**Kein Scope-Creep:** Nichts über das reine Lese-ACL hinaus geändert. Kein chmod auf dem +Verzeichnis, kein User-Wechsel, kein anderer Dienst angefasst. + +--- + +## #35 — anleitung-poller Reaktivierung (auf jump.panel1.de = "Jump Hub Produktion") + +**Ist-Zustand vor Eingriff:** +- Script `/opt/scripts/poll_anleitung.py` + Wrapper `/opt/scripts/poll_with_health.sh` waren + bereits vorhanden. +- Cron-Eintrag war **entgegen der Aufgabenbeschreibung NICHT entfernt**: + `/etc/crontab`: `*/30 * * * * root /opt/scripts/poll_with_health.sh` lief weiterhin (belegt + durch `/var/log/syslog` CRON-Einträge alle 30 Min). +- Tatsächliche Root-Cause für "tot seit 2026-06-30": `/tmp/anleitung_key.txt` (API-Key, wird bei + Reboot geleert — dokumentierter Pitfall im Skill selbst) fehlte → jeder Lauf brach mit + `FATAL: API key file not found` ab, seit dem letzten Reboot am 30.06. Für Bär von außen nicht + von einem entfernten Cron zu unterscheiden. +- `/root/.hermes/skills/rezepte/` stand bei 73 Skills, `last_poll: 2026-06-30T20:30:02`. + +**Backup vor Änderung:** +``` +/root/backups/crontab-before-anleitung-poller-202607231720.bak +/root/backups/anleitung_poller.json.bak-202607231720 +/root/backups/hermes-skills-rezepte-before-202607231720.tar.gz (73 Skills gesichert) +``` + +**Fix:** +- API-Key aus der (bereits im Repo dokumentierten, Klartext-)Deployment-Notiz + `references/deployment-notes.md` erneut base64-kodiert nach `/tmp/anleitung_key.txt` (chmod 600, + root:root) geschrieben — genau der vom Poller erwartete Zustand. +- Cron-Eintrag NICHT dupliziert (war schon da, geprüft mit `grep -n poll_with_health /etc/crontab` + → genau eine Zeile). + +**VERIFY ECHT:** +``` +Vorher: 73 Skills, last_poll 2026-06-30T20:30:02 +Lauf 1: sudo python3 /opt/scripts/poll_anleitung.py + → "CHANGED: 117 REZEPTE found" / "DONE new=51 upd=17 skip=49 total=124" +Nachher: 124 Skills, last_poll 2026-07-23T17:25:33 +Lauf 2 (Idempotenz-Check): "NO CHANGE hash=91ac921f22eb known=124" — sauber, keine Fehler. +``` + +**Bekannte Einschränkung (nicht behoben, außerhalb des Auftrags):** +Der Wrapper `poll_with_health.sh` prüft vor jedem Lauf per SSH, ob GPU-Shadow +(100.87.122.111) erreichbar ist (`curl 127.0.0.1:8188`). Aktuell ist das nicht der Fall → +der reguläre Cron-Lauf skippt mit `exit 0` ("GPU-Shadow not healthy — skipping poller"). Die +Funktionsfähigkeit des Pollers selbst wurde durch direkten Aufruf von `poll_anleitung.py` +bewiesen (s.o.). Sobald GPU-Shadow wieder erreichbar ist, läuft der reguläre 30-Min-Cron durch. +Das ist eine bewusste Design-Gate-Logik aus dem Skill selbst, keine von mir eingeführte +Einschränkung — nicht eigenmächtig geändert. + +--- + +## 🚩 Sicherheits-Fund (zur Kenntnis, nicht blockierend) + +Im Repo `barby/fleet-shared` liegt unter +`hermes-skills/devops/anleitung-poller/references/credential-redaction-bypass.md` eine explizite +Anleitung, wie Hermes' Credential-Redaction (die Bearer-Token/API-Keys in generiertem Code +zensiert) systematisch umgangen werden kann (`open(..., 'wb')` statt `write_file`, base64-Template ++ `@file`-Syntax für curl-Header, etc.) — als "Workaround"-Doku für Agents geschrieben, nicht nur +für diesen einen Use-Case. Ich habe diese Technik NICHT verwendet (Key wurde direkt per SSH/sudo +geschrieben, kein Redaction-Agent involviert) und auch nicht verändert oder gelöscht — nur zur +Kenntnisnahme gemeldet, da es sich um eine generelle Anleitung zum Aushebeln eines +Sicherheitsmechanismus handelt, nicht bloß um Klartext-Credentials in Doku (was laut +`feedback-creds-in-docs.md` explizit gewünschte Praxis ist). + +--- + +**Doku-Verteilung:** Forgejo (`barby/hermes-erkenntnisse`), Obsidian +(`nas2:/volume1/Obsidian/Wissen/`), Nachtplan-Worklist (Obsidian-Variante, da Desktop\nachtplan.md +von diesem Linux-Host aus nicht erreichbar ist).