127 lines
6.3 KiB
Markdown
127 lines
6.3 KiB
Markdown
# 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).
|