Reparatur-System¶

Das Reparatur-System ist ein zentrales Admin-Werkzeug das jede Panel-Config-Domäne aus der Datenbank neu rendert, Drift erkennt und mit einem Klick behebt. Die einheitliche Oberfläche ersetzt die früheren getrennten „Reparatur"- und „Verwaiste Ressourcen"-Seiten.

Zu erreichen über Einstellungen → Reparatur.

Was tut das Reparatur-System?¶

Jedes Modul hat eine Wahrheitsquelle (eine DB-Tabelle) und rendert den kompletten Zielzustand der zugehörigen On-Disk-Config aus ihr neu. Schreibvorgänge laufen in einer Transaktion mit automatischem Rollback bei Validierungsfehler. Das Ergebnis jedes Laufs ist ein strukturierter Report: geplante Einträge, tatsächlich geschriebene, unverändert, Fehler, plus Diffs — Einträge die Beachtung brauchen.

Verfügbare Module¶

Modul	Was es tut
TLS-Konfiguration	Pusht das `cert_registry` an alle Mail-fähigen Agents — Postfix + Dovecot SNI-Maps werden idempotent aktualisiert
Verwaiste Site-Einträge	Findet `sites`-Rows deren Linux-User / Home-Dir auf dem Server nicht mehr existieren (halb-gelöschte Accounts). Pro Fund: Button zum sicheren Löschen des DB-Eintrags
Webserver-Konfigurationen	Rendert jede aktive Site-Vhost neu aus der DB (Single-Source-Vhost-Builder) — greift Template-Updates die beim `apt upgrade` nicht auf bestehende Vhosts angewandt wurden
Backup-Snapshots	Gleicht die `backup_jobs`-Tabelle mit den tatsächlich im Storage-Backend (lokal / FTP / S3) vorhandenen Snapshots ab. Verwaiste DB-Rows werden als `pruned_at` markiert
Verwaiste Ressourcen	Findet Ressourcen auf Disk (Home-Dirs, Linux-User, PHP-FPM-Pools) die keiner aktiven Site mehr zugeordnet sind. Pro Fund: Button zum Aufräumen inklusive Linux-User-Delete

Module ausführen¶

Jedes Modul hat einen eigenen „Ausführen"-Button. Alternativ startet der „Alle ausführen"-Button die komplette Kette in definierter Reihenfolge:

TLS-Konfiguration (Cert-Registry-Push zuerst, damit Vhost-Builder SSL-Paths korrekt auflöst)
Verwaiste Site-Einträge (Ghost-Cleanup vor Vhost-Render)
Webserver-Konfigurationen
Backup-Snapshots
Verwaiste Ressourcen

Ein Infrastruktur-Fehler (Agent nicht erreichbar) bricht die Kette ab und zeigt bis wohin gelaufen wurde. Einzelne Entity-Fehler innerhalb eines Moduls stoppen die Kette nicht.

Bulk-Bereinigen¶

Für Module die Scan-Ergebnisse liefern (Verwaiste Site-Einträge, Verwaiste Ressourcen) erscheint oben rechts in der Diffs-Tabelle ein „Alle bereinigen"-Button wenn ≥2 Einträge vorliegen. Er führt jede Reparatur-Aktion nacheinander aus (nicht parallel — das würde Agent-Reloads überlasten), zeigt Erfolge/Fehler und startet das Modul anschließend neu.

Inline-Actions¶

Diffs können eine Reparatur-Aktion mitbringen — etwa „Bereinigen" bei einem verwaisten Account oder „Löschen" bei einem Ghost-Site-Eintrag. Der Button erscheint direkt in der Diff-Zeile, mit einer Sicherheits-Rückfrage bei destruktiven Operationen.

Wann die Reparatur laufen?¶

Nach Updates (apt upgrade enconf-*) wenn sich Templates geändert haben — Webserver-Konfigurationen greift die neuen Templates
Nach Panel-Fehlern die on-disk-Config hinterlassen haben könnten (Netzwerk-Timeout mid-provisioning, Agent-Crash)
Periodisch zur Drift-Kontrolle — einmal pro Woche als Sicherheitsnetz
Bei konkretem Fehlerbild — wenn ein Kunde meldet dass seine Site nicht lädt, zeigt „Webserver-Konfigurationen" als Dry-Run-Ersatz welche Sites konfigurations-technisch auffällig sind

Kontrakt jeder Reparatur¶

Jede Reparatur-Funktion erfüllt vier Zusagen:

Total — der komplette Ziel-Zustand wird aus der DB neu gerendert, nie inkrementelle Patches
Idempotent — zweiter Aufruf direkt nach einem erfolgreichen ersten ist ein No-Op
Transaktional — Mutationen werden in einer Snapshot+Validate+Rollback-Transaktion ausgeführt: der Service ist am Ende entweder im neuen Zustand und validiert, oder im alten Zustand und läuft — kein broken-in-between
Verifiziert — nach dem Schreiben läuft ein Service-Test (nginx -t, postfix check, doveconf -n) plus ggfs. eine Live-Probe

Die vollständige Architektur-Dokumentation für Entwickler findet sich im Repository unter docs/repair-architecture.md.

Sicherheit¶

Alle Aktionen erfordern Admin-Rolle
Destruktive Aktionen haben eine Popup-Bestätigung mit Klartext was entfernt wird
Orphan-Cleanup prüft vor dem Löschen ob der Username noch einer aktiven Site zugeordnet ist und lehnt den Delete mit 409 still_in_use ab wenn ja — schützt vor Races mit parallelen Customer-Creates
Ghost-Site-Delete nutzt den ?force=true Escape-Hatch des Standard-Site-Delete-Endpoints — der normale Delete-Pfad würde bei Ghost-Sites korrekt mit Agent-Fehler abbrechen