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>
99 lines
4.8 KiB
Markdown
99 lines
4.8 KiB
Markdown
# 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](hosts/cfgmon.md) |
|
|
| **game** | `157.90.155.206` (`game.axion1337.de`) | Pterodactyl / Gameserver | [hosts/game.md](hosts/game.md) |
|
|
| **matrix** | `49.13.132.245` (`matrix.axion1337.de`) | Matrix-Homeserver | [hosts/matrix.md](hosts/matrix.md) |
|
|
| **Overmind** | `10.58.73.17` (`git.lab`, **nur im Homelab auflösbar**) | GitLab + CI-Runner (Lab) | [hosts/overmind.md](hosts/overmind.md) |
|
|
|
|
## Übergreifend
|
|
|
|
| Thema | Backlog |
|
|
|---|---|
|
|
| DNS-Zone `axion1337.de` und Mail-Policy (IONOS) | [shared/zone-axion1337.md](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.
|