docs: document owner password persistence fix in deployment.md and changelog
This commit is contained in:
+22
-3
@@ -1,7 +1,7 @@
|
||||
# Deployment
|
||||
|
||||
> Letzte Aktualisierung: 2026-06-20
|
||||
> Status: ✅ CD v3 (Auto + Manual)
|
||||
> Letzte Aktualisierung: 2026-06-21
|
||||
> Status: ✅ CD v3 (Auto + Manual) + Owner-Passwort-Persistenz (SeedAudit)
|
||||
> Live-URL: https://nexus.noveria.net
|
||||
|
||||
## CD-Philosophie (v3)
|
||||
@@ -107,6 +107,23 @@ schedule:
|
||||
|
||||
## Secrets und Konfiguration
|
||||
|
||||
### Owner Password Persistence (2026-06-21, permanent fix)
|
||||
|
||||
**Root Cause**: Dual-Source-Architektur fuer das Owner-Passwort (Gitea-Secret `ENV_OWNER_PASSWORD` vs Host `.env` `OWNER_PASSWORD`) verursachte Drift wenn die DB jemals neu geseedet wurde.
|
||||
|
||||
**Fix (3 Schichten)**:
|
||||
1. **SeedAudit-Entity** (DB-Migration `20260621081500_AddSeedAudit`): `EnsureDatabaseAsync` prueft die `SeedAudit`-Tabelle auf Key `owner_created` VOR dem Seeden. Ist dieser Key vorhanden, wird der Owner NIE neu erstellt — selbst wenn die Users-Tabelle komplett geloescht wird.
|
||||
2. **Single Source of Truth**: Deploy- und Rollback-Workflows lesen `OWNER_PASSWORD` jetzt aus dem persistenten Host-`.env` (via `grep` auf dem Deploy-Pfad), NICHT mehr aus separatem Gitea-Secret. Das Host-`.env` ist die kanonische Quelle.
|
||||
3. **admin-reset-password** Endpoint existiert als Recovery-Pfad (braucht `Admin__ResetToken` aus dem `.env`).
|
||||
|
||||
**Verifikation (2026-06-21)**:
|
||||
- Login funktioniert nach `docker compose down && up` (kompletter Stack-Neustart)
|
||||
- Login funktioniert nach `docker compose up -d --force-recreate --wait`
|
||||
- Login funktioniert nach `docker compose restart`
|
||||
- SeedAudit-Eintrag `owner_created` blockiert erneutes Seeden bei jedem Startup
|
||||
|
||||
**Regel gegen Wiederholung**: `OWNER_PASSWORD` nur im Host-`.env` aendern. Das Host-`.env` wird von CI-Deploys gelesen. Niemals ein separates Gitea-Secret fuer OWNER_PASSWORD anlegen.
|
||||
|
||||
### Secrets in Gitea
|
||||
|
||||
Folgende Secrets sind in Gitea (Repo → Settings → Actions → Secrets) konfiguriert:
|
||||
@@ -115,9 +132,11 @@ Folgende Secrets sind in Gitea (Repo → Settings → Actions → Secrets) konfi
|
||||
|---|---|
|
||||
| `ENV_POSTGRES_PASSWORD` | PostgreSQL-Passwort |
|
||||
| `ENV_JWT_KEY` | JWT-Signing-Key (min. 32 Bytes) |
|
||||
| `ENV_OWNER_PASSWORD` | Owner-Account-Passwort |
|
||||
| `ENV_OPENCLAW_TOKEN` | OpenClaw Gateway Token |
|
||||
|
||||
> **Hinweis**: `ENV_OWNER_PASSWORD` wurde aus den Gitea-Secrets ENTFERNT (2026-06-21).
|
||||
> OWNER_PASSWORD kommt ausschliesslich aus dem Host-`.env` auf dem Deploy-Pfad.
|
||||
|
||||
### Safe Secret Handling (v3)
|
||||
|
||||
**Vorher (unsicher)**: Secrets wurden via `${{ secrets.X }}` direkt in eine Datei im Workspace interpoliert, die dann zum Host synct wurde. Das `.env` lag potenziell lesbar im Workspace und auf dem Host-Dateisystem.
|
||||
|
||||
Reference in New Issue
Block a user