Repository navigation
Removing a PostgreSQL Service leaves its pg_hba.conf block and listener on the host #146
Description
Split from #144 (part 2), found in the review of #141 (PostgreSQL remoteAccess, spec S-006).
The problem
Removing a PostgreSQL Service resource removes its firewall rule on the next cloudfall converge baseline, but leaves on the host:
- the Cloudfall block in
pg_hba.conf(itshostssllines) listen_addresses = '127.0.0.1,<listenAddress>'in the Cloudfall conf file
The nftables default-drop still closes the port, so nothing is reachable from outside; the second layer stays open.
Why it isn't a small fix
Cloudfall has no decommission path for any Service today: converge only renders the services the config declares, and nothing records which services a host ran before. Closing what a removed Service left behind needs that path (or a record of the previous services per host) first. S-006-10 covers removing remoteAccess from a Service that stays, which works.
Expected
Whatever the Service decommission path turns out to be, it closes the pg_hba.conf block and resets the listener too, or config validate/converge reports what was left behind.
Related: #81, #141, #144, docs/specs/006-standalone-postgresql.md.
Activity
shipmill-romamo commentedon Oct 27, 2026
Triage: postponed to after 0.8.0. Cloudfall has no decommission path for any Service yet, so there is nothing for this fix to hook into; building one is new behaviour that needs a spec of its own. The firewall rule does go away with the Service, and nftables' default drop keeps the port closed, so this is a gap in the second layer, not an opening.
The plan:
pg_hba.conf, resetslisten_addresses, and reloads or restarts as S-006-10 does for a removedremoteAccessremoteAccessfrom the Service, convergeservices, and only then remove the Serviceshipmill-romamo commentedon Oct 27, 2026
@romamo Decided without waiting: this is postponed until Cloudfall has a Service decommission path, which needs its own spec.
Why: nothing records which services a host ran before, so no fix can tell a removed Service from one that was never there; the nftables default drop still closes the port.
Not taken: specify Service decommission now, which pulls a new capability into 0.8.0 while S-006 and S-007 are still finishing.
Reply with a comment starting with
vetobefore 2026-10-28 11:15 UTC to reverse it, adding what you want instead if you like. A later veto still counts and gets a follow-up.