diff --git a/STATUS.md b/STATUS.md index 9c941d6..227f29a 100644 --- a/STATUS.md +++ b/STATUS.md @@ -54,7 +54,7 @@ Verteilung: M1 10 · M2 23 · M4 6 · M5 2 _none active_ -## ADRs (14) +## ADRs (15) | ADR | Status | Title | |---|---|---| @@ -72,6 +72,7 @@ _none active_ | [0012](docs/adr/0012-issues-im-repo-gitlab-als-spiegel.md) | accepted | ADR-0012: Issues leben im Repo; GitLab wird deterministisch bespiegelt | | [0013](docs/adr/0013-gruppenregeln-kanonisch-mit-pruefung.md) | accepted | ADR-0013: Gruppenregeln kanonisch im management-Repo, Komponenten zeigen und werden geprüft | | [0014](docs/adr/0014-wikijs-loest-docusaurus-ab.md) | accepted | 0014 — Wiki.js löst Docusaurus ab: abgeschottete Betriebs-/Anwenderdoku, docs-as-code | +| [0015](docs/adr/0015-wiki-git-storage-ueber-gitea-kanonisieren.md) | proposed | 0015 — Wiki.js Git-Storage: Inhalt fließt Cluster→Gitea→kanonisiert nach git.lab | ## Open AARs (2) diff --git a/docs/adr/0015-wiki-git-storage-ueber-gitea-kanonisieren.md b/docs/adr/0015-wiki-git-storage-ueber-gitea-kanonisieren.md new file mode 100644 index 0000000..9033990 --- /dev/null +++ b/docs/adr/0015-wiki-git-storage-ueber-gitea-kanonisieren.md @@ -0,0 +1,57 @@ +--- +type: adr +id: "0015" +status: proposed +date: 2026-08-13 +supersedes: null +superseded_by: null +related: [docs/issues/0048-wikijs-in-der-suite-deployen.md, docs/adr/0014-wikijs-loest-docusaurus-ab.md, docs/adr/0001-gitlab-kanonisch-push-mirror.md] +--- + +# 0015 — Wiki.js Git-Storage: Inhalt fließt Cluster→Gitea→kanonisiert nach git.lab + +## Kontext + +ADR-0014 macht docs-as-code zur harten Anforderung: der Wiki-Inhalt liegt in git. +#0048 hielt dafür fest, ein **git.lab**-`wiki`-Repo anzulegen, „gespiegelt wie die +übrigen", und es als Wiki.js-Git-Storage mit bidirektionalem Sync einzubinden. + +Beim Bau (2026-08-13) zeigt sich: das ist so **nicht machbar**. Wiki.js läuft im +Hetzner-Cluster, und der erreicht git.lab bewusst **nicht** — `git.lab` löst aus dem +Pod nicht auf; nur Gitea (`rohana.axion1337.de`) ist per HTTPS erreichbar (verifiziert). +Diese Lab-Unabhängigkeit ist Absicht (ADR-0001, ADR-0004): die Produktion darf nicht +von einem Host abhängen, der nur im Lab antwortet. Der Schreiber des Inhalts sitzt also +im Cluster und kann git.lab nicht beschreiben. + +## Optionen + +- **A — Cluster→git.lab öffnen.** Verworfen: hebelt die bewusste Lab-Unabhängigkeit + aus (ADR-0001), koppelt die Produktion ans Lab. +- **B — Nur Gitea, kein git.lab-Kanon.** Wiki.js schreibt in ein Gitea-Repo, fertig. + Verworfen: der Inhalt hätte keinen kanonischen git.lab-Stand — widerspricht ADR-0001. +- **C — Wiki.js→Gitea, CI kanonisiert Gitea→git.lab.** Wiki.js pusht in ein + Gitea-Repo; ein geplanter CI-Job auf git.lab holt den Stand und schreibt ihn nach + git.lab. Das ist **dasselbe Muster**, das für den TURN-Rotations-CronJob bereits + akzeptiert ist (der einzige verbliebene Cluster-Schreibvorgang nach Gitea, siehe + gitops-CLAUDE.md / `canonize_rotation`). Gewählt. + +## Entscheidung + +Der Wiki.js-Git-Storage zielt auf ein **Gitea-Repo** (`sorb/wiki`) über HTTPS mit +einem **dedizierten Deploy-PAT**. Der Inhalt wird per geplantem CI-Job Gitea→git.lab +**kanonisiert**, analog zu `canonize_rotation`. Die Richtung ist gegenüber dem üblichen +Push-Mirror (git.lab→Gitea) **umgekehrt**, weil der Schreiber im Cluster sitzt — das ist +eine bewusste, dokumentierte Ausnahme zu ADR-0001, kein Regelbruch. + +## Konsequenzen + +- **Leichter:** reproduzierbar und lab-unabhängig; nutzt ein etabliertes Muster statt + eines neuen Sonderwegs; kein Netz-Umbau am Cluster. +- **Schwerer:** ein zweiter Cluster→Gitea-Schreibpfad, der gepflegt sein will; braucht + den Kanonisierungs-Job (Vorlage `canonize_rotation`); ein dedizierter PAT liegt im + Cluster-SOPS (eigene Rotation). +- **Voraussetzungen (sorb):** Gitea-Repo `sorb/wiki` (privat) anlegen; dedizierten + Deploy-PAT (write:repository) bereitstellen. Beides kann der Agent nicht selbst — der + vorhandene Push-Token darf keine Repos anlegen. +- **Später zu klären:** ob das Content-Repo unter eine Gruppe mit eigenem Mirror + gehört; ob echter bidirektionaler Sync (Edits in git) gewollt ist oder push-only genügt. diff --git a/docs/issues/0048-wikijs-in-der-suite-deployen.md b/docs/issues/0048-wikijs-in-der-suite-deployen.md index 83ba1b4..02c12b4 100644 --- a/docs/issues/0048-wikijs-in-der-suite-deployen.md +++ b/docs/issues/0048-wikijs-in-der-suite-deployen.md @@ -38,3 +38,18 @@ Inhalts-Speicher. Ersetzt den Forward-Auth-Zwischenstand auf Overmind (Guide 09, #0024). OIDC + Rollen kommen in #0049, Theming in #0050. Umbrella: #0046. + +## Update 2026-08-13 — Git-Storage-Architektur korrigiert (Widerspruch) + +Deployment, Postgres, Ingress/Cert, öffentliche Erreichbarkeit, OIDC/Rollen (#0049) +und Theming (#0050) laufen live und reproduzierbar über den Konfig-Job. + +**Offen ist nur der Git-Storage** — und die oben geforderte Fassung ist so **nicht +machbar**: „`wiki`-Repo auf git.lab, gespiegelt wie die übrigen, als Storage" setzt +voraus, dass Wiki.js git.lab erreicht. Tut es nicht — der Cluster erreicht bewusst +nur Gitea (verifiziert 2026-08-13). Auflösung in +[ADR-0015](../adr/0015-wiki-git-storage-ueber-gitea-kanonisieren.md): Wiki.js→Gitea +(`sorb/wiki`), CI kanonisiert Gitea→git.lab (Muster `canonize_rotation`). + +Voraussetzung (nur sorb): Gitea-Repo `sorb/wiki` (privat) anlegen + dedizierten +Deploy-PAT bereitstellen. Danach verdrahtet der Agent Storage + Kanonisierungs-Job. diff --git a/docs/issues/0050-wikijs-theming-farben-logo.md b/docs/issues/0050-wikijs-theming-farben-logo.md index 39c04ab..0cc2662 100644 --- a/docs/issues/0050-wikijs-theming-farben-logo.md +++ b/docs/issues/0050-wikijs-theming-farben-logo.md @@ -33,3 +33,22 @@ aus `git.lab/homelab/wiki` extrahiert (2026-08-12): Nice-to-have (`low`), nach #0048/#0049. Assets liegen in `homelab/wiki`; beim Bau in das neue `wiki`-Repo kopieren. + +## Update 2026-08-13 — Umsetzung (Teil) + +Live und reproduzierbar über den Konfig-Job (gitops-Commit `63460e7`): + +- **Dark-Mode als Default.** +- **Logo** (ThreadNet `logo.png`) — als statische Datei in Wiki.js gemountet + (`platform-branding` ConfigMap → `/_assets/img/branding/`), öffentlich ausgeliefert, + auf der Login-Seite und eingeloggt sichtbar (kein `read:assets` für Guests nötig). +- **Login-Hintergrund** = `alpenglow.jpg`, dieselbe Datei wie Authentik/Element + (Erweiterung ggü. der ursprünglichen Spec, Wunsch sorb 2026-08-13) — ebenfalls lokal + gemountet statt per externer URL verlinkt. + +Statt der Spec-Idee „Assets ins `wiki`-Repo kopieren" liegen sie als **eine Quelle** in +`gitops:apps/production/branding/` und werden in den Pod gemountet; später auch in +Authentik/Element mountbar (eine Datei, keine Mehrfachpflege). + +Noch offen: **Akzentfarbe** (`#2b6cb0`/`#63b3ed`, via injectCSS), **Favicon**, und der +**optische Abgleich** durch sorb.