2026-08-15 12:00:00 +00:00
parent df8dcad8e1
commit 51c05edb2d
9 changed files with 122 additions and 24 deletions
@@ -2,9 +2,9 @@
<!-- Generated by scripts/gen_status.py — do not edit. -->
## Issues (31 open, 15 closed)
## Issues (30 open, 16 closed)
Verteilung: M1 6 · M2 19 · M4 2 · M5 4
Verteilung: M1 6 · M2 18 · M4 2 · M5 4
| Issue | Status | Meilenstein | Priorität | Title |
|---|---|---|---|---|
@@ -12,13 +12,13 @@ Verteilung: M1 6 · M2 19 · M4 2 · M5 4
| [0004](docs/issues/0004-overmind-02-e1000e-nic-hang-beobachtung-nach.md) | waiting | M1 | low | OVERMIND-02: e1000e-NIC-Hang — Beobachtung nach EEE-Fix + Firmware-Update |
| [0008](docs/issues/0008-cfgmon-03-prometheus-remote-write-und-loki.md) | waiting | M1 | medium | CFGMON-03: Prometheus-Remote-Write und Loki öffentlich ohne Auth — Weg A, nachgelagerte Prüfung |
| [0009](docs/issues/0009-cfgmon-04-grafana-admin-credentials-aus-env.md) | open | M2 | low | CFGMON-04: Grafana-Admin-Credentials aus .env gelten nicht für die HTTP-API |
| [0014](docs/issues/0014-cfgmon-14-root-zugang-ueber-die-docker-gruppe.md) | waiting | M2 | low | CFGMON-14: Root-Zugang über die docker-Gruppe umgeht sudo und hinterlässt keine Spur |
| [0014](docs/issues/0014-cfgmon-14-root-zugang-ueber-die-docker-gruppe.md) | open | M2 | low | CFGMON-14: Root-Zugang über die docker-Gruppe umgeht sudo und hinterlässt keine Spur |
| [0015](docs/issues/0015-cfgmon-15-token-hygiene-einmal-tokens-der.md) | next | M2 | medium | CFGMON-15: Token-Hygiene — Einmal-Tokens der LABNET-02-Nacht widerrufen |
| [0018](docs/issues/0018-doc-01-wiki-rollout-abschliessen-ci-freigaben.md) | open | M2 | low | DOC-01: Wiki-Rollout abschließen — CI-Freigaben, Zeitplan, Dokploy-Stack, wiki.lab |
| [0019](docs/issues/0019-doc-02-veralteten-wiki-branch-im-gitops-repo.md) | open | M2 | low | DOC-02: Veralteten `wiki`-Branch im gitops-Repo entfernen? |
| [0021](docs/issues/0021-overmind-03-windows-build-vm-verschwindet-ci.md) | waiting | M2 | medium | OVERMIND-03: Windows-Build-VM verschwindet — CI kann sie nur starten, nicht anlegen |
| [0022](docs/issues/0022-build-01-macos-client-reproduzierbar-bauen.md) | open | M4 | low | BUILD-01: macOS-Client reproduzierbar bauen — aktuell nur manuell auf sorbs Mac |
| [0027](docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md) | waiting | M2 | medium | AUDIT-01: Acht Widersprüche aus dem LABNET-02-Nachlauf (Selbst-Audit CFGMON-Session) |
| [0027](docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md) | open | M2 | medium | AUDIT-01: Acht Widersprüche aus dem LABNET-02-Nachlauf (Selbst-Audit CFGMON-Session) |
| [0028](docs/issues/0028-mirror-01-ein-ausfall-der-push-mirrors-bleibt.md) | open | M2 | low | MIRROR-01: Ein Ausfall der Push-Mirrors bleibt unbemerkt — Produktion friert still ein |
| [0029](docs/issues/0029-ui-harmonisieren-gleiche-farben-und-formen.md) | open | M4 | medium | UI harmonisieren: gleiche Farben und Formen über alle Oberflächen |
| [0030](docs/issues/0030-der-restore-ist-nie-geprobt-sicherungen-sind.md) | in-progress | M1 | medium | Der Restore ist nie geprobt — Sicherungen sind bisher eine Vermutung |
@@ -32,7 +32,6 @@ Verteilung: M1 6 · M2 19 · M4 2 · M5 4
| [0038](docs/issues/0038-rollout-agents-pointer-thread-net-git.md) | open | M2 | medium | Rollout Gruppenregeln-Pointer: `thread-net-git` |
| [0039](docs/issues/0039-rollout-agents-pointer-threadnet-operating.md) | open | M2 | medium | Rollout Gruppenregeln-Pointer: `threadnet-operating` |
| [0040](docs/issues/0040-neckbeard-rueckmeldungen-einreichen.md) | open | M2 | low | neckbeard-Rückmeldungen aus dem Feldtest einreichen |
| [0041](docs/issues/0041-wartegrund-der-importierten-waiting-issues.md) | open | M2 | low | wartegrund der 7 importierten waiting-Issues präzisieren |
| [0042](docs/issues/0042-migration-in-betrieb-nehmen-push-spiegel-schedule.md) | open | M2 | high | Migration in Betrieb nehmen: Push, erster Spiegel-Lauf, CI-Schedule |
| [0043](docs/issues/0043-invitation-flow-eindeutigkeit-case-insensitiv.md) | open | M5 | medium | Invitation-Flow: case-insensitive Eindeutigkeitsprüfung im Prompt-Stage |
| [0044](docs/issues/0044-sops-secret-aenderung-startet-dienst-nicht-neu.md) | open | M5 | low | SOPS-Values-Secret-Änderung startet den konsumierenden Dienst nicht neu |
 
@@ -6,7 +6,7 @@ created: 2026-08-01
milestone: M1
priority: medium
host: game
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
wartegrund: "Wartet auf Aufnahme des GAME-Hosts in den Hetzner-vSwitch (Handgriff sorb in der Cloud-Console); erst danach lassen sich die Scrape-Targets auf die private Adresse umstellen."
gitlab_iid: "2"
related: []
---
@@ -39,3 +39,15 @@ Quelle: [hosts/game.md](https://git.lab/axion1337.chat/management/-/blob/main/ho
---
*Übernommen aus dem Backlogs-Markdown beim Framework-Umbau 2026-08-01 (voller Wortlaut: Git-Historie der Datei).*
## Nachgeprüft 2026-08-15
Exporter weiterhin **nicht erreichbar** (Messung vom Mac, öffentliche IP):
`157.90.155.206:8080` und `:9100` laufen in den Timeout, während `:443` sofort antwortet —
die Signatur eines Paketfilters davor, also unverändert das im Issue beschriebene Bild.
Nichts hat sich von allein gelöst.
⚠️ **Alert-Nebenwirkung:** Die beiden Silences liefen am **2026-08-04** ab; seither meldet
`TargetDown` für beide Targets alle 4 h. Das läuft nun seit rund zwei Wochen und stumpft die
Alarmwege ab. Bis der vSwitch-Umzug erfolgt, entweder neu silencen (mit Ablaufdatum) oder den
Umzug vorziehen — Dauerfeuer ohne Adressat ist schlimmer als kein Alarm.
 
@@ -6,7 +6,7 @@ created: 2026-08-01
milestone: M1
priority: low
host: overmind
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
wartegrund: "Beobachtungsfenster nach EEE-Abschaltung + NIC-Firmware 2.5.2.0: ohne erneuten Hang bis ca. 2026-08-28 (vier Wochen ab Fix) schließen; bei Wiederauftreten gezielter ASPM-Fix."
gitlab_iid: "4"
related: []
---
@@ -27,3 +27,10 @@ Volle Zeitleiste: [hosts/overmind.md](https://git.lab/axion1337.chat/management/
---
*Übernommen aus dem Backlogs-Markdown beim Framework-Umbau 2026-08-01 (voller Wortlaut: Git-Historie der Datei).*
## Zwischenstand 2026-08-15
Rund zwei Wochen des vierwöchigen Beobachtungsfensters sind um (Fix: 2026-08-01, Vorfall:
2026-07-31). Kein Handlungsbedarf bis ca. **2026-08-28** — dann entweder schließen oder,
falls der Hang wiederkehrt, auf den gezielten ASPM-Fix gehen. Bewusst kein Aktionismus:
Das Issue *ist* das Warten.
 
@@ -7,7 +7,7 @@ milestone: M1
priority: medium
host: cfgmon
area: security
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
wartegrund: "Wartet auf den gemeinsamen Blick in die Hetzner-Cloud-Console mit sorb: welche Firewall-Regeln existieren real (das Backlog-Bild wich davon ab). Von außen sind 9090/3100 bereits dicht — es geht um die bewusste, dokumentierte Regel, nicht mehr um akute Exposition."
gitlab_iid: "8"
related: []
---
@@ -32,3 +32,16 @@ Quelle: [hosts/cfgmon.md](https://git.lab/axion1337.chat/management/-/blob/main/
---
*Übernommen aus dem Backlogs-Markdown beim Framework-Umbau 2026-08-01 (voller Wortlaut: Git-Historie der Datei).*
## Nachgeprüft 2026-08-15 — akute Exposition besteht nicht
Messung vom Mac gegen die öffentliche CFGMON-IP: **9090 (Prometheus remote-write) und 3100
(Loki) antworten nicht**, während `:443` sofort antwortet (Gegenprobe, Messmethode also
gültig). Das bestätigt die im Issue vermerkte Beobachtung: die Ports sind zu, **ohne** dass
der Console-Klick je gemacht wurde.
Damit verschiebt sich der Charakter des Issues: Es geht **nicht mehr um akutes Risiko**,
sondern darum, dass der Ist-Zustand nicht bewusst hergestellt und nicht dokumentiert ist —
was heute zufällig zu ist, kann bei der nächsten Änderung unbemerkt aufgehen. Zu klären
bleibt: welche Regeln greifen tatsächlich, und trägt das den GAME-Push (#0002) nach dessen
vSwitch-Umzug noch?
 
@@ -1,15 +1,14 @@
---
type: issue
id: "0014"
status: waiting
status: open
created: 2026-08-01
milestone: M2
priority: low
host: cfgmon
area: security
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
gitlab_iid: "14"
related: []
related: [docs/adr/0008-agenten-sessions-root-aequivalent.md]
---
# CFGMON-14: Root-Zugang über die docker-Gruppe umgeht sudo und hinterlässt keine Spur
@@ -27,3 +26,19 @@ Aus dem [CFGMON-AAR](https://git.lab/axion1337.chat/management/-/blob/main/verfa
- **C — getrenntes Konto** für Agenten-Sessions mit definierter, protokollierter Rechteerhöhung
Vor einer Entscheidung zu klären: Welche anderen Konten sind in der docker-Gruppe, und gilt dasselbe auf MATRIX?
## Entscheidung liegt vor (ADR-0008) — Restaufgabe 2026-08-15
Die im Issue offene Wahl zwischen A/B/C ist **entschieden**: **ADR-0008** (2026-08-06,
Struktur-Workshop) wählt ausdrücklich **Option A** — Agenten-Sessions laufen auf CFGMON
root-äquivalent über die docker-Gruppe, und „sudo mit Passwort" gilt dort ausdrücklich
**nicht** als Kontrollmechanismus. Option C bleibt Ziel, aber erst wenn ein zweiter Mensch
mitarbeitet. Das Issue wartet also auf nichts mehr → `open` statt `waiting`.
**Von der Vorfrage ist eine Hälfte beantwortet:** *„Gilt dasselbe auf MATRIX?"* → **Nein.**
`getent group docker` auf MATRIX liefert nichts — dort läuft k3s ohne Docker-Daemon, die
Root-Äquivalenz über die docker-Gruppe existiert also gar nicht. (Geprüft 2026-08-15 per SSH.)
**Rest:** Auf **CFGMON** prüfen, welche Konten in der docker-Gruppe sind (`getent group docker`)
und ob sie alle dorthin gehören — braucht eine Host-Session, vom Mac nicht einsehbar. Danach
kann das Issue geschlossen werden; die Entscheidung selbst steht in ADR-0008.
 
@@ -6,7 +6,7 @@ created: 2026-08-02
milestone: M2
priority: medium
area: infrastructure
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
wartegrund: "Wartet auf Go von sorb für Variante C (Fehlermeldung des CI-Jobs um den Hinweis 'Stack in Dokploy neu deployen' ergänzen); Variante A erst, wenn der Fall ein drittes Mal auftritt."
gitlab_iid: "21"
related: []
---
@@ -24,3 +24,10 @@ sorb hat ihn manuell neu gestartet, danach lief der Build. Der Fall wiederholt s
- **C** — so lassen, aber die Fehlermeldung im Job um den Hinweis „Stack in Dokploy neu deployen" ergänzen (billigste Variante).
Empfehlung: **C jetzt, A wenn es ein drittes Mal passiert.**
## Präzisierung 2026-08-15
Kein technischer Blocker — das Issue enthält bereits die Empfehlung (**C jetzt, A beim dritten
Auftreten**) und wartet nur auf das Go. C ist ein Einzeiler in der Job-Definition und macht den
Fall selbsterklärend, statt die nächste Session wieder raten zu lassen. Bislang ist der Fall
**einmal** aufgetreten (2026-08-02, Job 498).
 
@@ -63,10 +63,12 @@ stand, obwohl der Deploy längst live ist. Nachgeprüft:
| Keine 502-Retry-Schleife | `alertmanager_notifications_failed_total` = **0** über 80 Serien aller Integrationen |
| Not-Aus nicht mehr nötig | Die `room="security"`-Route auf den Null-Receiver existiert nicht mehr; `alertmanager.yml` hat nur die Default-Route auf den `matrix`-Receiver |
**Was NICHT direkt beobachtet wurde:** ob im Security-Raum tatsächlich einmal aggregierte
🔴-Nachrichten eingetrudelt sind (Kriterium 2 der Übergabe, „gezählt ≤ 29"). Das lässt sich
nur im Raum bzw. in `docker compose logs matrix-alerts` sehen. Der Fehlzähler bei 0 belegt,
dass **keine Zustellung gescheitert** ist — er belegt nicht, dass welche stattfand.
**Kriterium 2 nachträglich belegt (Screenshots sorb, 2026-08-15):** Im Security-Raum liegen
die aggregierten 🔴-Meldungen — **eine pro Image**, Format „Image X: N CRITICAL-CVEs" mit
Dashboard-Link, alle im selben Sendefenster (1:42). **24 Nachrichten**, also unter der
Obergrenze von 29; keine Pro-CVE-Flut, keine Wiederholungen. Die Summe der gemeldeten
CRITICALs ergibt 126 und deckt sich exakt mit dem bekannten Report-Stand — die
`trivy_vuln_info`-Serien kommen also vollständig an.
Das Issue wird trotzdem geschlossen: sein Zweck war die Übergabe eines Deploys, und der ist
gelandet, robust und ohne die befürchteten Nebenwirkungen. Die Zustellung ist seit
@@ -74,10 +76,8 @@ gelandet, robust und ohne die befürchteten Nebenwirkungen. Die Zustellung ist s
`alertmanager_notifications_failed_total`) — ein künftiger Zustellfehler meldet sich von
selbst, statt auf eine manuelle Sichtprüfung zu warten.
**Kleiner Folgepunkt (kein Blocker):** Falls `TrivyCriticalVulns` derzeit `inactive` ist,
obwohl CRITICAL-Funde bekannt sind (#0051), wäre das ein eigener Hinweis — dann kämen die
`trivy_vuln_info`-Serien nicht (mehr) an. Einmal im Grafana-Dashboard `cve-overview`
gegenschauen; gehört fachlich zu #0051.
**Folgepunkt erledigt:** `TrivyCriticalVulns` feuert nachweislich (s.o.) — der Verdacht,
die `trivy_vuln_info`-Serien kämen nicht mehr an, ist ausgeräumt.
**Weiterhin bewusst offen (aus dem Original):** Grafana-Dashboard als Matrix-Widget im
Security-Raum — eigener Punkt, war nie Teil dieses Deploys.
 
@@ -1,14 +1,13 @@
---
type: issue
id: "0027"
status: waiting
status: open
created: 2026-08-02
milestone: M2
priority: medium
area: infrastructure
wartegrund: Grund im GitLab-Verlauf benannt (Import 2026-08-11); im nächsten Refinement präzisieren
gitlab_iid: "27"
related: []
related: [docs/adr/0008-agenten-sessions-root-aequivalent.md]
---
# AUDIT-01: Acht Widersprüche aus dem LABNET-02-Nachlauf (Selbst-Audit CFGMON-Session)
@@ -51,3 +50,28 @@ Für die Fehlersuche wurde SSH auf der UDM aktiviert (`root@10.58.73.1`, eigenes
---
**Konform befunden** (der Vollständigkeit halber): AAR-Pflicht nach Deploy mit Übergabe ✓ (beide AARs), Kanonisierungs-Weg statt Gitea-Push ✓ (alle vier CFGMON-Commits über git.lab, Mirror verifiziert), Redlichkeits-Regeln ✓ (Verifiziert/Vermutet getrennt, eigene Fehlannahme per Nachtrag korrigiert statt geglättet), chirurgische Config-Edits ✓ (sed + `wg-quick strip`-Validierung), Übergabe-Ausnahme auf Gitea während der Nacht ✓ (durch ADR-0002 gedeckt, seit heute per #13 migriert und zurückgebaut).
## Blocker entfallen 2026-08-15 — Workshop hat stattgefunden
Das Issue wartete auf die Auflösung „im Struktur-Workshop (#17)". Der **hat stattgefunden**
(2026-08-06) und drei ADRs hervorgebracht: **0008** (Agenten-Sessions root-äquivalent — löst
den zu W-gehörenden Teil und damit #0014), **0009** (Commit-Konventionen) und **0010**
(Härtung als eigener Meilenstein M5). Damit ist der Wartegrund hinfällig → `open`.
**Die Widersprüche sind damit aber nicht alle abgeräumt.** Zwei stichprobenartig gegengeprüft,
beide bestehen fort:
- **W1 offen:** `docs/adr/0004-*` nennt weiterhin *„Split-DNS nur `~lab` → 10.58.73.1"*. Die
  real konfigurierten **vier** Zonen (`~lab`, `~lab.de`, `~axion1337.de`, `~axionlabs.de`)
  stehen dort nicht — inklusive der im Issue benannten Brisanz, dass `~axion1337.de` auch
  `rohana.axion1337.de` (Gitea-Mirror, Flux-Quelle!) über den Lab-Resolver zieht.
- **W3 offen:** `docs/wiki/admin/cfgmon.md` listet in der Dienste-Tabelle (Zeile 33) weiterhin
  `runner | gitea/act_runner:0.6.1` als laufend — obwohl dieselbe Datei ihn als am 2026-07-31
  entfernt meldet.
**W4/W5** (Rotationspflicht nach der Secrets-Regel) haben mit **#0015** teilweise ein Zuhause;
ob damit alle dort genannten Schlüssel abgedeckt sind, gehört zur Auflösung.
**Nächster Schritt:** W1–W8 einzeln durchgehen und je Punkt entweder auflösen (ADR/Doku
nachziehen) oder bewusst verwerfen — die Regel des Issues („dokumentieren, nicht still
auflösen") bleibt dabei gültig.
 
@@ -1,7 +1,7 @@
---
type: issue
id: "0041"
status: open
status: done
created: 2026-08-11
milestone: M2
priority: low
@@ -17,3 +17,24 @@ related: []
Import-`wartegrund` „Grund im GitLab-Verlauf". Im nächsten Refinement
je Issue den echten Grund eintragen (alte Regel: `wartet` nur mit
benanntem Grund).
## Erledigt 2026-08-15 — alle sieben durchgegangen
Alle im Issue genannten Import-`wartegrund`e sind ersetzt; die generische Formel
„Grund im GitLab-Verlauf" kommt nicht mehr vor. Ergebnis des Durchgangs:
| Issue | Ergebnis |
|---|---|
| #0002 GAME-01 | bleibt `waiting` — wartet auf vSwitch-Aufnahme (sorb). Nachgemessen: Exporter weiterhin dicht; ⚠️ Silences seit 2026-08-04 abgelaufen → `TargetDown` feuert seither alle 4 h |
| #0004 OVERMIND-02 | bleibt `waiting` — datiertes Beobachtungsfenster bis ca. 2026-08-28 |
| #0008 CFGMON-03 | bleibt `waiting` — wartet auf gemeinsamen Console-Blick. Nachgemessen: 9090/3100 von außen **dicht**, akute Exposition besteht nicht |
| #0014 CFGMON-14 | → **`open`**: Entscheidung liegt längst als **ADR-0008** vor (Option A). Vorfrage zur Hälfte beantwortet: **MATRIX hat keine docker-Gruppe** |
| #0021 OVERMIND-03 | bleibt `waiting` — wartet nur auf das Go für Variante C |
| #0025 Deploy-Übergabe | → **`done`** (separat geschlossen, Deploy live und verifiziert) |
| #0027 AUDIT-01 | → **`open`**: der blockierende Struktur-Workshop **hat 2026-08-06 stattgefunden**; W1 und W3 aber stichprobenartig als **weiterhin offen** nachgewiesen |
**Erkenntnis über den Auftrag hinaus:** Bei drei der sieben war der `waiting`-Zustand nicht
nur unpräzise, sondern **sachlich falsch** — der Blocker war längst weg (#0014, #0027) oder
die Aufgabe erledigt (#0025). Ein pauschal importierter Wartegrund verdeckt genau das. Die
verbliebenen vier warten nachweislich auf eine benannte Handlung von sorb, nicht auf
Unbekanntes.