nixos-config/docs/research/full-system-aufit.md

# Full-System-Audit: NixOS-Plattform (blunix / pinix / tnix)

**Datum:** 2026-09-11
**Scope:** Read-only Audit von Repository (`/home/drone/nixos-config`, Branch `dev`, HEAD detached), Runtime-Zustand auf `blunix` (lokale Shell, systemd, Journal, Netzwerk, HTTP), sowie extern erreichbare Endpunkte unter `*.0ff.space`.
**Methode:** Repository-Lektüre (Nix-Konfiguration, Git-Historie), lokale Diagnosebefehle auf blunix (systemctl, journalctl, ss, df/du, tailscale status), sowie HTTP-Prüfungen gegen öffentlich exponierte Endpunkte über einen bereits im Nix-Store vorhandenen `curl`-Build (kein neuer Build/keine Zustandsänderung). Kein SSH auf pinix/tnix, kein `nixos-rebuild`, keine schreibenden Aktionen.

## Executive Summary

1. **Kritischer Vorfall bestätigt:** blunix ist mit 96 % Diskbelegung (1,5 GB frei von 37 GB) faktisch am Limit. Am 10.09. führte das tatsächlich zu Ausfällen (Forgejo-Dump, Prosody Push-Notifications, DHCP-Lease-Schreibvorgang schlugen mit „No space left on device" fehl). Ursache: ~208 `nixos-rebuild switch`-Läufe und 34 System-Generationen in weniger als 48 Stunden (automatisierte Builder-Pipeline), während GC nur wöchentlich mit 30-Tage-Retention läuft.
2. **pinix ist seit ca. 1 Tag über Tailscale nicht erreichbar** (`tailscale status`: „offline, last seen 1d ago"). Das erklärt gleichzeitig mehrere scheinbar unabhängige Symptome: Timeouts auf `board.0ff.space`, `social.0ff.space`, `phanpy.0ff.space`, `sound.0ff.space`, `calendar.0ff.space` sowie wiederkehrende Forgejo-Webhook-Fehler gegen `100.64.0.3:9000` (pinix' Tailnet-IP).
3. Der **Codeberg-Push-Mirror schlägt seit Tagen zyklisch alle paar Stunden fehl**, weil der Mirror versucht, den Branch `master` auf Codeberg zu löschen (lokal existiert kein `master` mehr, nur `dev`/`production`), Codeberg das aber als aktuellen Default-Branch ablehnt.
4. Auf blunix liegt ein **verwaistes 117 MB großes `/var/lib/gotosocial`-Verzeichnis**, obwohl GoToSocial laut Repo ausschließlich auf pinix läuft — vermutlich Rückstand einer Host-Migration, verschärft den Diskdruck unnötig.
5. **LLDAP** (Admin-Verzeichnisdienst) ist öffentlich unter `lldap.0ff.space` ohne zusätzliche Traefik-Middleware (kein `basicAuth`, anders als z. B. das Traefik-Dashboard) erreichbar (HTTP 200 auf Login-Seite) — vergrößert die Angriffsfläche für den zentralen Auth-Verzeichnisdienst.

## Audit Coverage

**Untersucht:**
- Repository-Struktur, `flake.nix`, Host-Configs (`hosts/blunix`, `hosts/pinix`, `hosts/tnix`, `hosts/globalServices`), Firewall-/Traefik-/GC-Konfiguration
- Git-Historie (letzte ~30 Commits), Branch-/Remote-Zustand
- systemd: alle Units, Failed-Units (keine), Restart-Zähler, laufende vs. nicht-laufende Services, Timer (restic, forgejo-dump, nix-gc)
- Journal: `journalctl -p err` über die letzten Tage, gezielte Suche nach wiederkehrenden Mustern (Forgejo, Prosody, SSH, dhcpcd)
- Disk-/Speicherzustand (`df -h`, `du` auf `/var/lib/*`, `/nix/store`, `/home`, journal disk usage), Nix-Generationenverlauf
- Netzwerk: offene Ports (`ss -tlnp`), Firewall-Regeln aus dem Repo (`allowedTCPPorts`, `trustedInterfaces`), Tailscale-Peer-Status
- HTTP: Live-Check mehrerer extern gerouteter Endpunkte (`git`, `lldap`, `traefik`, `board`, `social`, `phanpy`, `sound`, `data`, `hdm`, `head`, `calendar`) via bereits gebautem `curl`
- Backup-Kette: restic-Timer und letzte drei Läufe, Forgejo-Dump-Timer und letzter Lauf

**Nicht untersucht / eingeschränkt:**
- **Kein Zugriff auf pinix oder tnix** (weder SSH noch Shell) — alle Aussagen zu diesen Hosts stammen ausschließlich aus Repo-Konfiguration und indirekten Beobachtungen von blunix aus (Traefik-Timeouts, Tailscale-Status, Webhook-Fehler). Der tatsächliche Zustand von pinix (läuft es noch? Netzwerkproblem oder Host down?) bleibt ungeklärt.
- Keine Web-UI-Funktionsprüfung mit echtem Login (Board, Kanboard, Mastodon-Frontend etc.), da das die Sandbox-Vorgabe „keine Formulareingaben/Aktionen" verletzen würde und ohnehin die Backends über pinix nicht erreichbar waren.
- Detailinhalt von `/var/lib/forgejo`, `/var/lib/mysql/*`, `/var/log/fail2ban`, `/var/lib/tailscale` etc. war aus Permission-Gründen (kein sudo im Runtime-Pfad dieser Rolle) nicht lesbar; Aussagen zu diesen Komponenten stützen sich auf öffentlich lesbare Metadaten (Verzeichnisgröße von außen, systemctl-Status).
- Kein `nix flake check` / `nix eval` durchgeführt (für diesen Auftrag nicht notwendig gewesen); keine Bewertung der Nix-Ausdrucks-Korrektheit über die gelesenen Dateien hinaus.
- Keine tiefere Analyse von `agents/` (Board-Automatisierung, Codex/Claude-Runner) über das hier relevante Maß hinaus — der Job, der diesen Audit ausführt, läuft selbst als `board-agent-worker.service`-Kindprozess; das wurde nur am Rande beobachtet, nicht separat auditiert.
- Die genannten 5 SSH-`kex_exchange_identification`-Fehler/Tag wurden nicht tiefer untersucht (typisches Internet-Hintergrundrauschen von Portscannern); fail2ban-Jail-Details konnten mangels `fail2ban-client` im PATH nicht abgefragt werden, nur `systemctl is-active fail2ban` (aktiv).

## Findings

### F1 — Disk-Auslastung auf blunix kritisch, bereits mit realem Ausfall (Critical)
**Komponenten:** blunix Root-Filesystem, Nix-Store, `nix.gc` (`hosts/nix-gc.nix`), automatisierte Rebuild-Pipeline (`agent-codex/deploy_runner.py`), Forgejo, Prosody, dhcpcd
**Beobachtung:** `df -h` zeigt 96 % Belegung (34G/37G, 1,5G frei). `/nix/store` allein belegt 25G. Zwischen dem 09.09. 22:49 und dem 11.09. 16:40 wurden 34 System-Generationen erzeugt (`system-471-link` … `system-504-link`), `journalctl` zählt 208 Aktivierungen von `nixos-rebuild-switch-to-configuration.service` in 3 Tagen.
**Evidenz:**
```
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/pool-root   37G   34G  1.5G  96% /
Sep 10 04:31:02 blunix forgejo[1636407]: Failed to create temporary directory: ... no space left on device
Sep 10 04:31:02 blunix systemd[1]: Failed to start forgejo dump.
Sep 10 00:59:42 blunix prosody[683999]: datamanager: Unable to write to cloud_notify storage ('No space left on device')
Sep 10 05:00:07 blunix dhcpcd[450984]: dhcp_writefile: ... No space left on device
```
**Erwarteter Zustand:** Ausreichend Puffer entsprechend der in `hosts/nix-gc.nix` dokumentierten Analyse (`docs/intent/nix-gc-plattform.md`, min-free 1GiB/max-free 3GiB), keine anwendungsseitigen Fehler durch Plattenmangel.
**Tatsächlicher Zustand:** Trotz aktivierter `min-free`/`max-free`-Settings (verifiziert in `/etc/nix/nix.conf`) reicht die inkrementelle Garbage Collection nicht aus, weil `nix.gc` nur wöchentlich mit `--delete-older-than 30d` läuft — bei 200+ Rebuilds/3 Tage bleiben praktisch alle Generationen (und ihre GC-Roots) für Wochen erhalten.
**Vermutete Ursache:** Hohe Rebuild-Kadenz der Board-/Builder-Automatisierung kombiniert mit einer GC-Policy, die auf gelegentliche manuelle Rebuilds ausgelegt war, nicht auf mehrfach-stündliche automatisierte Deploys.
**Mögliche Auswirkungen:** Wiederkehrende Datenverlust-nahe Situationen (fehlgeschlagene Backups/Dumps), Instabilität weiterer schreibender Dienste, im Extremfall Root-FS voll → Totalausfall.
**Empfohlene nächste Schritte:** GC-Strategie an tatsächliche Rebuild-Frequenz anpassen (z. B. `nix.gc.dates` täglich statt wöchentlich, `--delete-older-than` deutlich verkürzen, oder Generationen explizit auf eine kleine Anzahl begrenzen statt nur Boot-Menu-Einträge via `configurationLimit`); alternativ Rebuild-Frequenz der Automatisierung selbst hinterfragen (muss jeder einzelne Board-Job sofort `switch` auslösen?).
**Konfidenz:** Hoch (direkt aus `df`, `journalctl`, Generationenliste und Rebuild-Zähler belegt).

### F2 — pinix seit ~1 Tag über Tailscale nicht erreichbar, mehrere Public-Routes tot (Critical)
**Komponenten:** pinix (Tailnet-Konnektivität), Traefik-Routing (`routes-external.nix`), Forgejo-Webhooks, Kanboard/„board", GoToSocial/„social", „phanpy", „sound", Radicale/„calendar"
**Beobachtung:** `tailscale status` zeigt pinix als „offline, last seen 1d ago" (tx>0/rx=0 — einseitig tot). Live-Checks gegen alle Traefik-Routen, die auf `tailnetIPs.pinix` zeigen, laufen in einen TLS-Handshake-Erfolg gefolgt von vollständigem Timeout; rein lokale Routen (`data`, `hdm`, `head`, alle `127.0.0.1`) liefern HTTP 200.
**Evidenz:**
```
100.64.0.3  pinix  worker@  linux  active; relay "fra"; offline, last seen 1d ago, tx 6240 rx 0
board.0ff.space  -> Operation timed out after 15002 milliseconds
social/phanpy/sound/calendar.0ff.space -> http_code 000 (Timeout)
data/hdm/head.0ff.space -> http_code 200
Sep 11 16:33:16 blunix forgejo[...]: Unable to deliver webhook task[1374] ... http://100.64.0.3:9000/hooks/wiki-update ... context deadline exceeded
```
**Erwarteter Zustand:** pinix als Tailnet-Peer aktiv, alle darüber gerouteten Public-Services erreichbar.
**Tatsächlicher Zustand:** pinix vom Tailnet aus nicht erreichbar; dadurch mindestens 5 nach außen beworbene Dienste (Board/Kanboard, Mastodon-Frontend, Phanpy, Sound, Calendar) faktisch down, plus tägliche Webhook-Fehlversuche gegen pinix.
**Vermutete Ursache:** Entweder pinix selbst ist down/hängt, oder ein Tailscale-/Netzwerkproblem auf pinix-Seite (z. B. IP-Wechsel, Stromausfall, Kernel-Update-Hänger). Ohne Zugriff auf pinix nicht abschließend klärbar.
**Mögliche Auswirkungen:** Nutzer-sichtbarer Totalausfall mehrerer Dienste seit ~24h, ohne dass dies (soweit im Audit sichtbar) bereits gemeldet/alarmiert wurde — deutet auf eine **Observability-Lücke** hin (kein Alerting für Tailnet-Peer-Verfügbarkeit oder Backend-Health der Traefik-Routen).
**Empfohlene nächste Schritte:** Sofortige manuelle Prüfung von pinix (Konsolen-/Out-of-Band-Zugriff, da SSH über Tailnet ja gerade das Problem sein könnte); danach Monitoring/Alerting für Tailnet-Peer-Status und Traefik-Backend-Health ergänzen.
**Konfidenz:** Hoch für „pinix nicht erreichbar" und „dadurch Route-Timeouts" (direkt gemessen); die eigentliche Ursache auf pinix selbst ist unbelegte Vermutung.

### F3 — Codeberg-Push-Mirror scheitert zyklisch seit Tagen (Medium)
**Komponenten:** Forgejo Push-Mirror (`lukas/nixos-config` → `codeberg.org/pijukka/nixos-config`)
**Beobachtung:** Wiederkehrender Fehler alle paar Stunden über mehrere Tage hinweg.
**Evidenz:**
```
Sep 11 13:54:49 blunix forgejo[608639]: Error pushing .../lukas/nixos-config.git mirror[2] ...: PushRejected
Sep 11 13:54:49 blunix forgejo[608639]: remote: Forgejo: branch master is the default branch and cannot be deleted
```
Lokal existiert kein `master`-Branch mehr (`git branch -a` zeigt nur `dev`/`production`), `origin/HEAD` zeigt aber noch auf `refs/remotes/origin/master`.
**Erwarteter Zustand:** Push-Mirror synchronisiert erfolgreich, kein wiederkehrender Fehler im Journal.
**Tatsächlicher Zustand:** Jeder Sync-Versuch versucht, den auf Codeberg als Default gesetzten `master`-Branch zu löschen, was Codeberg ablehnt — seit Tagen ununterbrochen wiederholt.
**Vermutete Ursache:** `master` wurde im Quell-Repo entfernt/umbenannt (vermutlich im Zuge der `dev`/`production`-Umstellung), ohne den Default-Branch auf dem Mirror-Ziel entsprechend nachzuziehen.
**Mögliche Auswirkungen:** Kein Datenverlust, aber dauerhaftes Fehlerrauschen im Journal, unnötige Last, und ein nicht mehr aktueller Codeberg-Mirror (bleibt vermutlich auf dem Stand vor der Branch-Umstellung).
**Empfohlene nächste Schritte:** Default-Branch auf Codeberg-Seite auf `production` oder `dev` umstellen (oder Mirror-Konfiguration entsprechend anpassen), danach Journal auf Wiederholung prüfen.
**Konfidenz:** Hoch (Fehlermeldung ist eindeutig, lokale Branch-Situation bestätigt die Diskrepanz).

### F4 — Verwaistes GoToSocial-Datenverzeichnis auf blunix (Low, Cleanup)
**Komponenten:** `/var/lib/gotosocial` auf blunix, GoToSocial-Service (laut Repo nur auf pinix definiert)
**Beobachtung:** `du -sh /var/lib/gotosocial` liefert 117M auf blunix, obwohl `hosts/pinix/localServices/gotosocial.nix` der einzige Ort im Repo ist, der den Service definiert; `systemctl status gotosocial` auf blunix meldet „could not be found".
**Erwarteter Zustand:** Keine GoToSocial-Daten auf einem Host, der den Service gar nicht betreibt.
**Tatsächlicher Zustand:** 117 MB toter Daten-Altlast auf einer Platte, die gerade bei 96 % liegt (F1).
**Vermutete Ursache:** Migration von GoToSocial von blunix nach pinix, Altdaten wurden nicht bereinigt.
**Mögliche Auswirkungen:** Unnötiger Verbrauch von knappem Speicherplatz; potenzielle Verwechslungsgefahr bei zukünftigen Debugging-Sessions.
**Empfohlene nächste Schritte:** Verifizieren, dass die Daten wirklich nicht mehr gebraucht werden (z. B. Vergleich mit dem aktiven Datenstand auf pinix, sobald erreichbar), dann manuell entfernen.
**Konfidenz:** Mittel — Verzeichnisinhalt selbst war wegen fehlender Leserechte nicht einsehbar, nur die Größe und der Servicename sind belegt.

### F5 — LLDAP-Admin-UI öffentlich ohne zusätzliche Auth-Schicht exponiert (Medium, Security)
**Komponenten:** `hosts/blunix/localServices/lldap.nix`, `hosts/blunix/localServices/traefik/routes-external.nix` (Route „lldap")
**Beobachtung:** `https://lldap.0ff.space/` liefert HTTP 200 (Login-Seite) ohne Traefik-`basicAuth`-Middleware, im Unterschied zur Traefik-API-Route, die per `middlewares = ["auth"]` geschützt ist (HTTP 401 bestätigt).
**Erwarteter Zustand / Vergleich:** Andere sensible interne Tools (`intent-board`) sind bewusst mit `middlewares = ["auth"]` versehen; LLDAP als zentraler Identitäts-/Admin-Dienst hat dieses zusätzliche Netzwerk-Gate nicht.
**Vermutete Ursache:** LLDAP verlässt sich allein auf sein eigenes Login (Passwort-Auth), vergleichbar mit der bewussten Design-Entscheidung bei „calendar" (Kommentar: „Radicale's own per-request LDAP auth is the real security boundary"). Bei LLDAP ist das aber der Verzeichnisdienst selbst, dessen Kompromittierung (z. B. Brute-Force, ungepatchte CVE) alle nachgelagerten Auth-Flows (Dex, oauth2-proxy) betrifft.
**Mögliche Auswirkungen:** Größere Angriffsfläche für den zentralen Identity-Provider als nötig; kein Brute-Force-Schutz auf HTTP-Ebene sichtbar (nur generisches fail2ban, Jail-Details nicht einsehbar).
**Empfohlene nächste Schritte:** Prüfen, ob `basicAuth`- oder IP-/Tailnet-Beschränkung für die LLDAP-Web-UI sinnvoll ergänzt werden kann, ohne den beabsichtigten Nicht-Tailnet-Zugriff (falls gewollt) zu brechen; alternativ gezielte fail2ban-Jail für LLDAP-Login-Fehlversuche verifizieren/ergänzen.
**Konfidenz:** Mittel — die Exposition ist belegt, ob das eine bewusste Design-Entscheidung war (wie bei „calendar" dokumentiert) oder ein Versehen, ist aus dem Repo nicht eindeutig ersichtlich (kein entsprechender Kommentar wie bei anderen Routen).

### F6 — Wiederkehrende Forgejo „bad object"-Fehler bei PR-Diff-Stats (Low)
**Komponenten:** Forgejo, `GetPullDiffStats`
**Beobachtung:** Drei distincte Objekt-Hashes (`059210b7…`, `13f74c33…`, `45db7d4d…`) tauchen über mehrere Tage hinweg wiederholt als „fatal: bad object" auf.
**Erwarteter Zustand:** Diff-Stats-Berechnung für alle offenen PRs funktioniert fehlerfrei.
**Tatsächlicher Zustand:** Für (vermutlich) einzelne PRs mit inzwischen nicht mehr existenten Commits (z. B. nach Force-Push/Rebase eines Fork-Branches) schlägt die Berechnung dauerhaft fehl und wird periodisch erneut versucht.
**Vermutete Ursache:** Stale PR-Referenz auf gelöschten/umgeschriebenen Branch-Kopf, kein Repo-Korruptionsproblem des Hauptrepos.
**Mögliche Auswirkungen:** Kosmetisch (fehlende Diff-Stats-Anzeige für betroffene PR(s)), plus unnötige wiederkehrende Last/Log-Rauschen.
**Empfohlene nächste Schritte:** Betroffene(n) PR(s) identifizieren (über Forgejo-UI/DB) und schließen oder neu synchronisieren.
**Konfidenz:** Mittel (Fehlermuster eindeutig, genaue betroffene PR nicht identifiziert).

### F7 — MySQL/MariaDB lauscht auf `0.0.0.0:3306` statt `127.0.0.1` (Informational)
**Komponenten:** MySQL/MariaDB (WordPress-Backend), Firewall
**Beobachtung:** `ss -tlnp` zeigt `0.0.0.0:3306` und `[::]:3306`; die Firewall-Konfiguration (`allowedTCPPorts = [22 80 443 5222 5269]`, keine `trustedInterfaces`, kein `tailscale0`-Sonderfall für 3306) lässt aber keinen externen oder Tailnet-Zugriff zu.
**Erwarteter/tatsächlicher Zustand:** Kein akutes Risiko, da die OS-Firewall den Port blockt; sauberer wäre dennoch ein `bind-address = 127.0.0.1`, um Defense-in-Depth nicht allein von der Firewall-Regel abhängig zu machen.
**Mögliche Auswirkungen:** Gering, solange Firewall-Konfiguration unverändert bleibt; Risiko steigt bei künftigen Firewall-Änderungen (z. B. neuer `trustedInterfaces`-Eintrag).
**Empfohlene nächste Schritte:** `bind-address`/`http_host`-Äquivalent für MySQL auf `127.0.0.1` setzen, falls kein externer DB-Zugriff je benötigt wird.
**Konfidenz:** Hoch für die Beobachtung, mittel für die Risikoeinschätzung (abhängig von künftigen Konfigurationsänderungen).

## Positive Findings

- **Backups laufen zuverlässig:** `restic-backups-vpsBackup` hat an allen drei geprüften Tagen (09.–11.09.) erfolgreich Snapshots erzeugt, auch am Tag des Disk-Vorfalls — die Backup-Kette selbst war nicht betroffen.
- **Selbstheilung des Forgejo-Dumps:** Nach dem akuten Space-Vorfall am 10.09. lief der Forgejo-Dump am 11.09. wieder sauber durch (`Finished dumping in file forgejo-dump-…`), sobald wieder Platz frei war — kein manuelles Eingreifen nötig.
- **Durchdachte, dokumentierte GC-Tuning-Historie:** `hosts/nix-gc.nix` zeigt bereits eine bewusste, aus einem Preflight abgeleitete Anpassung (`docs/intent/nix-gc-plattform.md`, 2026-09-05) mit klar begründeten Host-spezifischen Schwellenwerten — das Problem in F1 ist also bereits erkannt und teilweise adressiert worden, reicht aber (siehe F1) angesichts der Rebuild-Frequenz nicht aus.
- **Saubere Trennung von Auth-Boundaries dort, wo dokumentiert:** Die `calendar`-Route hat eine explizit begründete Design-Entscheidung („Radicale's own per-request LDAP auth is the real security boundary"), die `intent-board`-Route bekam bewusst `basicAuth` ergänzt, nachdem ein Review das als Lücke markiert hatte — die Codebase zeigt an mehreren Stellen nachvollziehbare, kommentierte Sicherheitsentscheidungen statt Zufall.
- **Firewall-Policy minimal und explizit:** Nur 5 TCP-Ports global offen, alle weiteren Dienste laufen entweder rein lokal oder über gezielte `tailscale0`-Ausnahmen — kein Anzeichen einer „alles offen"-Konfiguration.
- **Keine failed systemd-Units zum Prüfzeitpunkt**, kein Service mit auffälliger Restart-Historie außer dem hier selbst laufenden Board-Worker-Job.

## Cross-System Observations

- **F1 (Disk voll) und die 34 Generationen/208 Rebuilds sind direkt kausal verknüpft:** Die hohe Automatisierungs-Kadenz der Board-/Builder-Pipeline (jeder abgeschlossene Job löst offenbar einen `nixos-rebuild switch` aus) unterläuft die am 2026-09-05 bewusst eingeführte GC-Politik. Das ist kein Konfigurationsfehler in `nix-gc.nix` selbst, sondern ein Mismatch zwischen einer für gelegentliche Rebuilds ausgelegten Politik und einer inzwischen viel höherfrequenten Realität.
- **F2 ist die gemeinsame Ursache für mindestens 5 scheinbar unabhängige Symptome:** Timeout auf `board.0ff.space`, `social.0ff.space`, `phanpy.0ff.space`, `sound.0ff.space`, `calendar.0ff.space` sowie die tagelang wiederkehrenden Forgejo-Webhook-Fehler gegen `100.64.0.3:9000` — alle laufen über denselben Tailnet-Pfad zu pinix. Ohne Korrelation hätte man das leicht als 6 getrennte Bugs behandelt.
- **Dokumentation vs. Runtime:** `docs/intent/nix-gc-plattform.md` beschreibt einen Zustand („blunix hat kaum Reserve, 29G Store auf 37G-Platte"), der sich seit dem 2026-09-05 durch die gestiegene Rebuild-Frequenz weiter verschärft hat (Store jetzt 25G, Gesamtbelegung 34G/37G) — die Doku ist also nicht falsch, aber die zugrunde liegende Annahme (Rebuild-Häufigkeit) hat sich seither verändert, ohne dass die Gegenmaßnahme nachgezogen wurde.
- **Kein sichtbares Alerting für beide Critical-Findings:** Weder der Disk-Vorfall vom 10.09. noch der seit ~24h laufende pinix-Ausfall scheinen ein aktives Monitoring/Alerting ausgelöst zu haben (soweit aus Journal/Config ersichtlich) — beides wäre ohne diesen Audit vermutlich erst durch Nutzerbeschwerden aufgefallen.

## Empfohlene Folge-Intents (priorisiert)

1. **[Reliability/Bugfix] GC-Policy an tatsächliche Rebuild-Frequenz von blunix anpassen.** Ziel: `nix.gc` täglich statt wöchentlich, kürzere Retention und/oder Begrenzung der Anzahl gehaltener System-Generationen, damit die min-free/max-free-Schwellen nicht durch Dutzende frischer Generationen unterlaufen werden. Bezug: F1, `hosts/nix-gc.nix`.
2. **[Reliability] pinix-Erreichbarkeit klären und wiederherstellen.** Ziel: Root Cause des Tailnet-Ausfalls seit ca. 24h ermitteln (Host down? Tailscale-Client hängt? Netzwerkproblem?) und Board/Social/Phanpy/Sound/Calendar wieder erreichbar machen. Bezug: F2. Höchste Nutzerrelevanz.
3. **[Observability] Alerting für Tailnet-Peer-Status und Disk-Füllstand ergänzen.** Ziel: Beide Critical-Vorfälle (F1, F2) hätten proaktiv erkannt werden können; ein einfacher Schwellenwert-Check (Diskbelegung, `tailscale status` Peer-Offline-Dauer) mit Benachrichtigung wäre risikoarm und hochwirksam.
4. **[Bugfix] Codeberg-Push-Mirror-Konfiguration an aktuellen Default-Branch (`production`/`dev`) anpassen.** Bezug: F3. Geringer Aufwand, beseitigt tagelanges Fehlerrauschen.
5. **[Cleanup] Verwaiste GoToSocial-Altdaten auf blunix identifizieren und entfernen**, nachdem pinix wieder erreichbar ist und der aktive Datenstand verifiziert werden kann. Bezug: F4.
6. **[Security] LLDAP-Web-UI-Exposition bewerten und ggf. zusätzliche Schutzschicht (Middleware/IP-Beschränkung/Rate-Limiting) ergänzen.** Bezug: F5.
7. **[Cleanup] Betroffene PR(s) mit „bad object"-Referenzen in Forgejo identifizieren und bereinigen.** Bezug: F6.
8. **[Security/Cleanup] MySQL `bind-address` auf `127.0.0.1` setzen als Defense-in-Depth**, unabhängig von der Firewall-Regel. Bezug: F7.
9. **[Architecture]** Grundsätzliche Diskussion, ob jeder einzelne Board-/Builder-Job wirklich einen sofortigen `nixos-rebuild switch` auslösen muss, oder ob Batching/Throttling der Deploys (z. B. max. 1 Switch pro X Minuten) die Systembelastung strukturell reduzieren würde — würde F1 nicht nur symptomatisch (GC), sondern ursächlich adressieren.

## Unsicherheiten / offene Punkte

- Die tatsächliche Ursache der pinix-Nichterreichbarkeit (F2) ist von blunix aus nicht abschließend diagnostizierbar (Host down vs. reines Netzwerkproblem).
- Ob die fehlende Middleware bei LLDAP (F5) eine bewusste Entscheidung oder ein Versehen war, ist aus dem Repo nicht mit Sicherheit ablesbar.
- Genaue Größe/Inhalt von `/var/lib/forgejo`, `/var/lib/mysql/*`, `/var/lib/traefik`, `/var/lib/postgresql` etc. blieb wegen fehlender Leserechte im Runtime-Pfad dieser Rolle unzugänglich; die Diskbilanz aus F1 könnte daher noch weitere, hier nicht sichtbare Verbraucher enthalten.
- Fail2ban-Jail-Konfiguration/-Wirksamkeit im Detail nicht prüfbar (`fail2ban-client` nicht im PATH der Sandbox).

## Fazit

Die Plattform ist grundsätzlich solide und mit erkennbarer Sorgfalt gepflegt (dokumentierte Design-Entscheidungen, funktionierende Backups, minimale Firewall-Policy). Der Audit deckt jedoch zwei bereits real eingetretene bzw. laufende Incidents auf, die ohne diesen Blick von außen leicht als mehrere unabhängige Kleinprobleme behandelt worden wären: ein selbstverschärfender Diskplatz-Engpass durch die hohe Automatisierungs-Kadenz der Deploy-Pipeline (F1), und ein seit rund einem Tag bestehender Totalausfall mehrerer öffentlicher Dienste durch einen nicht erreichbaren pinix-Host (F2). Beide sollten vorrangig behandelt werden; die übrigen Findings sind überwiegend kostengünstig zu beheben und primär Hygiene-/Cleanup-Charakter.