Thore CimbalandClaude Fable 5
2be5fb6f60
Schliesst die Doku-Luecke "Runner-Setup nur im Chat": Linux-Runner-Stolpersteine (Docker-DNS/extra_hosts, CA-Pfad im Config-Volume), Windows-Runner-Plan mit Image-Pin und Runbook-Verweis, Repo-Topologie-Kontext (git.lab kanonisch fuer die 5 gespiegelten Repos). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4.8 KiB
Backlogs
Zentrale Sammlung offener Punkte über alle Hosts und Dienste hinweg. Ein Eintrag landet hier, wenn er bewusst nicht sofort erledigt wurde — damit er nicht in einer Chat-Historie oder einem Kopf verschwindet.
Aufbau
hosts/ ein File pro Host, benannt nach dem Hostnamen
shared/ Themen, die mehrere Hosts betreffen (DNS-Zone, Mail-Policy)
Faustregel für die Einordnung: Der Eintrag gehört dorthin, wo die Arbeit
stattfindet, nicht dorthin, wo das Symptom auftritt. Ein down-Target in Prometheus
auf CFGMON, dessen Ursache ein blockierter Port auf dem Gameserver ist, gehört nach
hosts/game.md — mit Querverweis von CFGMON.
Hosts
| Host | Adressen | Rolle | Backlog |
|---|---|---|---|
| CFGMON | 188.245.193.243, 2a01:4f8:c17:93eb::1, privat 10.0.0.3 |
Monitoring-Stack, Gitea, Traefik | hosts/cfgmon.md |
| game | 157.90.155.206 (game.axion1337.de) |
Pterodactyl / Gameserver | hosts/game.md |
| matrix | 49.13.132.245 (matrix.axion1337.de) |
Matrix-Homeserver | hosts/matrix.md |
| Overmind | 10.58.73.17 (git.lab, nur im Homelab auflösbar) |
GitLab + CI-Runner (Lab) | hosts/overmind.md |
Übergreifend
| Thema | Backlog |
|---|---|
DNS-Zone axion1337.de und Mail-Policy (IONOS) |
shared/zone-axion1337.md |
Konventionen
IDs sind pro Datei fortlaufend mit einem Präfix, das den Ort benennt:
CFGMON-01, GAME-01, MATRIX-01, ZONE-01 — ein Präfix pro Datei in hosts/
bzw. shared/, keine Liste losgelöst vom tatsächlichen Datei-Bestand. IDs werden
nicht wiederverwendet — ein erledigter Punkt behält seine Nummer, damit
Querverweise und Commit-Messages dauerhaft stimmen. Auch wenn eine ganze Datei
entfällt (siehe hosts/k3s.md, entfernt 2026-07-30), wird ihr Präfix nicht für
etwas anderes wiederverwendet.
Das Präfix für DNS-Themen ist bewusst ZONE- und nicht DNS-: DNS-01 ist der
Name eines ACME-Challenge-Typs und käme in genau diesen Backlogs ständig als
Fachbegriff vor.
Status:
| Wert | Bedeutung |
|---|---|
offen |
noch nicht angefasst |
in Arbeit |
läuft gerade |
wartet auf … |
blockiert, mit Angabe worauf |
erledigt |
fertig, mit Datum — Eintrag bleibt stehen, siehe unten |
verworfen |
bewusst nicht umgesetzt, mit Datum und Begründung — nicht dasselbe wie erledigt: es ist nichts passiert, sondern es wurde entschieden, es zu lassen |
Erledigte und verworfene Punkte werden nicht gelöscht, sondern nach unten in den Abschnitt „Erledigt" verschoben (verworfene Punkte darin klar als solche kennzeichnen). Der Grund: bei mehreren Hosts ist die Frage „haben wir das damals eigentlich gemacht, und warum so — oder haben wir es bewusst gelassen?" häufiger als die Frage „was ist noch offen".
Jeder Eintrag braucht einen Status, eine Beschreibung des tatsächlichen Zustands, und einen konkreten nächsten Schritt. Wenn eine Aussage nicht direkt verifiziert ist (aus einer Konsole, einer Doku, einer Ableitung statt einer Messung von dem betroffenen System selbst), wird kurz dazugeschrieben, woher sie stammt — eine unbestätigte Vermutung, die wie ein Befund aussieht, kostet beim nächsten Mal mehr Zeit als sie spart.
Zeitkritisches bekommt ein Datum in der Statuszeile, nicht nur „bald".
Gegenstücke in anderen Host-Dateien (z. B. ein Punkt, der von zwei Seiten
beschrieben wird, wie ein Push von matrix auf einen offenen Port bei CFGMON)
werden beim Schließen einer Seite auf der anderen Seite mitaktualisiert, nicht
nur verlinkt und stehen gelassen — sonst bleibt eine Seite unbemerkt veraltet.
Verhältnis zu den Projekt-Repos
Dieses Repo hält die offenen Punkte. Die Konfiguration liegt weiter in den
jeweiligen Projekt-Repos, z. B. sorb/threadnet-operating für den
Monitoring-Stack auf CFGMON. Damit nichts doppelt geführt wird, verweisen die
Projekt-Repos hierher statt eigene Backlog-Dateien zu pflegen.
Verhältnis zu Gitea-Issues
Manche Projekt-Repos (z. B. sorb/axion1337.chat-gitops) führen ihren eigenen
Feature-/Fix-Backlog als Gitea-Issues — das bleibt dort, wird hier nicht
dupliziert. Faustregel für die Abgrenzung:
- Reiner Projekt-Scope (eine Funktion in einem Repo, ein Bug in einem Service): Gitea-Issue im jeweiligen Projekt-Repo, kein Eintrag hier.
- Host-/Infrastruktur-Scope (betrifft einen Host direkt, oder eine Entscheidung über mehrere Hosts/Repos hinweg, z. B. wo ein CI-Runner laufen soll): Eintrag hier, mit Verweis auf betroffene Issues statt deren Inhalt zu wiederholen.
- Beides zugleich (ein Host-Thema hat ein konkretes Gegenstück als Issue, z. B. ein fehlender Gitea-Runner blockiert CI in mehreren Repos): kurzer Eintrag hier mit Link zum führenden Issue, statt den Issue-Inhalt hierher zu kopieren.