fix: put postgres back on the NAS and revert the c72389c refactor #20

Merged
marti merged 2 commits from hotfix/postgres-datadir into main 2026-10-02 19:59:02 +02:00
Owner

Why

The cum-services deploy failed because postgres was running the wrong
cluster. 42c2ee0 (wysi) removed dataDir = "/mnt/main-hdd/pg", so the
module fell back to /var/lib/postgresql/18: a stale local cluster with
none of the app roles or databases. postgresql-setup then tried to create
all of them from a template1 that predates the glibc 2.42 bump and failed
on the collation version mismatch. The real data on the NAS was never
touched.

The c72389c refactor made the same mistake on cum-media, dropping its
services.postgresql.dataDir, so that host would break the same way on its
next deploy.

What

  • fix(cum-services): restore dataDir = "/mnt/main-hdd/pg".
  • revert: undo c72389c and its fixup 42f3919. This brings back
    cum-media's dataDir, the per-host NAS mounts, NetworkManager, the old user
    groups and docker socket symlinks, and the flake-parts devShell/formatter.
    It also removes nixos/nfs.nix, which only that refactor used.

All five hosts evaluate.

After deploying

  • Expect collation warnings from the NAS cluster too (it was also created
    under glibc 2.40). They don't block anything now that no new database has to
    be created. Reindex and run REFRESH COLLATION VERSION on each database when
    convenient.
  • /var/lib/postgresql/18 on cum-services is the stale cluster. Delete it once
    the services are confirmed healthy on the NAS one.

Generated with Claude Code

## Why The cum-services deploy failed because postgres was running the wrong cluster. `42c2ee0` (wysi) removed `dataDir = "/mnt/main-hdd/pg"`, so the module fell back to `/var/lib/postgresql/18`: a stale local cluster with none of the app roles or databases. `postgresql-setup` then tried to create all of them from a `template1` that predates the glibc 2.42 bump and failed on the collation version mismatch. The real data on the NAS was never touched. The `c72389c` refactor made the same mistake on cum-media, dropping its `services.postgresql.dataDir`, so that host would break the same way on its next deploy. ## What - **fix(cum-services)**: restore `dataDir = "/mnt/main-hdd/pg"`. - **revert**: undo `c72389c` and its fixup `42f3919`. This brings back cum-media's `dataDir`, the per-host NAS mounts, NetworkManager, the old user groups and docker socket symlinks, and the flake-parts devShell/formatter. It also removes `nixos/nfs.nix`, which only that refactor used. All five hosts evaluate. ## After deploying - Expect collation **warnings** from the NAS cluster too (it was also created under glibc 2.40). They don't block anything now that no new database has to be created. Reindex and run `REFRESH COLLATION VERSION` on each database when convenient. - `/var/lib/postgresql/18` on cum-services is the stale cluster. Delete it once the services are confirmed healthy on the NAS one. Generated with [Claude Code](https://claude.com/claude-code)
42c2ee0 dropped dataDir without migrating anything, so the next deploy
started postgres on /var/lib/postgresql/18: a stale local cluster with
none of the app roles or databases. postgresql-setup then tried to
create them all from a template1 that predates the glibc 2.42 bump, and
failed on the collation version mismatch.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Reverts c72389c and its fixup 42f3919. Among other things it dropped
cum-media's services.postgresql.dataDir, which would have started that
host on an empty local cluster the same way cum-services just did. This
brings back the per-host NAS mounts, NetworkManager, the previous user
groups and docker socket symlinks, and the flake-parts devShell and
formatter. nixos/nfs.nix only existed for the refactor, so it goes too.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
marti merged commit 7654cb8764 into main 2026-10-02 19:59:02 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
cumsek/nix!20
No description provided.