From b69585789a9fa34a7c33faf24da44926f166a9da Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Fri, 16 Oct 2026 23:49:58 +0200 Subject: [PATCH] README: the database password comes back with the data (R-1106); restic 0.19.1 --- controller/README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/controller/README.md b/controller/README.md index 195c637..c10c5e1 100644 --- a/controller/README.md +++ b/controller/README.md @@ -1538,6 +1538,13 @@ backups/primary// ⚠️ **R-127:** a regenerated **database** password is NOT harmless — `POSTGRES_PASSWORD` is ignored once PGDATA is non-empty, so the restored data dir keeps the old role hash and the app cannot authenticate against its own rows, while the dump replay (local trust socket) still reports success. The WARN says so. +- **The database password comes back with the data (v0.324.0, R-1106, operator decision 1A).** The app.yaml + variables that feed a database service's `*_PASSWORD` (`appbackup.DBCredentialVars`) are never generated (O4 skips + them): the unit's value wins; without one, the current install's value counts only when that install is OLDER than the + data; otherwise the restore is refused before any change (`err.backup.restore_no_db_password`). The off-site full + restore that keeps the app's definition (the reinstall case) writes the snapshot's password into the app's settings + (`stacks.SetStackSecretValues`, load-then-save) before the database starts — only when the snapshot replays the + database's data volume (`appbackup.DBDataVolumes`). Design: felhom.eu `07` §7.4. Catalog gate `db-credentials`. - Helpers: `RecoveryUnitPath` / `RecoveryUnitComposePath` / `RecoveryUnitManifestPath` (`internal/appbackup/paths.go`). Capture: `Manager.CaptureRecoveryUnit` (`internal/backup/recovery_unit.go`), run from the daily DB dump and the periodic `RefreshCache` (idempotent checksum-skip); the split itself @@ -4649,7 +4656,7 @@ git -C ~/git/felhom-controller pull Runtime `debian:13.x-slim`, pinned by version and digest; the Docker CLI's apt repo codename is read from the image's `/etc/os-release`. **restic is NOT an apt package:** the `restic` build stage downloads the official release binary of -the version in `ARG RESTIC_VERSION`, checks restic's signed `SHA256SUMS` with the vendored release key +the version in `ARG RESTIC_VERSION` (0.19.1 since v0.324.0, R-1107), checks restic's signed `SHA256SUMS` with the vendored release key (`third_party/restic/`), the published sum, and the per-architecture sum pinned in the Dockerfile — any mismatch fails the build. Moving restic is a decision with a re-proof: `internal/backup/testdata/restic//` holds REAL outputs of each version the off-site code was checked against, and `TestR1105_*` assert every parsed shape and failure class