grenade/moments
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

pg_ident mappings should live in an app-owned moments.conf, not host-named files #3

New Issue
Closed
opened 2026-07-02 06:28:40 +00:00 by grenade · 0 comments
grenade commented 2026-07-02 06:28:40 +00:00
Owner
Copy Link

The moments cert_cn → role mappings in pg_ident.conf.d/ were written to per-host files (<cert_cn host>.conf), shared with other apps' mappings for the same hosts (e.g. nikola.kosherinata.internal.conf carried both mm and moments_ro). Any other app's provisioning that rewrites its host file can clobber or drop moments access.

This also bit in practice: when the worker moved from roosta to frootmig, no frootmig...conf mapping was created, and the worker crash-looped with no match in usermap "cert_cn" (masked until the frootmig host cert expiry was fixed on 2026-07-02).

Fix:

  • script/db-perms.sh maintains a single app-owned pg_ident.conf.d/moments.conf and migrates any moments_ro/moments_rw lines out of legacy host-named files (verbatim, so workstation mappings survive), deleting legacy files left empty.
  • correct the standby hostname (frankie.kosherinata.internal → frankie.hanzalova.internal; the old name no longer resolves) and warn-and-continue on unreachable pg hosts instead of aborting.
  • asset/postgres/ident.conf.tmpl documents the new convention.

Applied to magrathea (primary) on 2026-07-02; frankie (standby) is tracked separately.

The moments cert_cn → role mappings in `pg_ident.conf.d/` were written to per-host files (`<cert_cn host>.conf`), shared with other apps' mappings for the same hosts (e.g. `nikola.kosherinata.internal.conf` carried both `mm` and `moments_ro`). Any other app's provisioning that rewrites its host file can clobber or drop moments access. This also bit in practice: when the worker moved from roosta to frootmig, no `frootmig...conf` mapping was created, and the worker crash-looped with `no match in usermap "cert_cn"` (masked until the frootmig host cert expiry was fixed on 2026-07-02). Fix: - `script/db-perms.sh` maintains a single app-owned `pg_ident.conf.d/moments.conf` and migrates any `moments_ro`/`moments_rw` lines out of legacy host-named files (verbatim, so workstation mappings survive), deleting legacy files left empty. - correct the standby hostname (`frankie.kosherinata.internal` → `frankie.hanzalova.internal`; the old name no longer resolves) and warn-and-continue on unreachable pg hosts instead of aborting. - `asset/postgres/ident.conf.tmpl` documents the new convention. Applied to magrathea (primary) on 2026-07-02; frankie (standby) is tracked separately.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
grenade
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: grenade/moments#3
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?