-
-
Notifications
You must be signed in to change notification settings - Fork 13.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/postgresql: deprecate ensurePermissions, fix ensureUsers for postgresql15 #266270
Commits on Nov 13, 2023
-
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgre…
…sql15 Closes NixOS#216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: NixOS#206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also NixOS#265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. NixOS#206467
Configuration menu - View commit details
-
Copy full SHA for 4845956 - Browse repository at this point
Copy the full SHA 4845956View commit details -
nixos/postgresql: restore
ensurePermissions
and strong-deprecate itAs it is technically a breaking change, we should at least make a strong deprecation of `ensurePermissions` and leave it in the broken state it is, for out of tree users. We give them a 6 months notice to migrate away by doing so, which is honest. In the meantime, we forbid usage of `ensurePermissions` inside of nixpkgs.
Configuration menu - View commit details
-
Copy full SHA for 12797a6 - Browse repository at this point
Copy the full SHA 12797a6View commit details -
nixos/postgresql: improve the assertions for equality of DB user and …
…DB name It is hard to figure out which one is offending without the database name.
Configuration menu - View commit details
-
Copy full SHA for d57926c - Browse repository at this point
Copy the full SHA d57926cView commit details
Commits on Nov 17, 2023
-
nixos/tests/pgbouncer: do not use
ensureDBOwnership
pgbouncer test is special in the sense where it actually tries to connect via SCRAM SHA, let's avoid `ensureDBOwnership` here otherwise for some reason pgbouncer will try to look in pg_shadow for the authuser…
Configuration menu - View commit details
-
Copy full SHA for 7319887 - Browse repository at this point
Copy the full SHA 7319887View commit details -
nixos/sourcehut: do not use
ensureDBOwnership
Given that SourceHut uses unfortunate defaults for database name, it will not be realistic to fix this in time for 23.11. We will leave the workaround and leave it to SourceHut maintainers to pick up the work to clean this up after 23.11.
Configuration menu - View commit details
-
Copy full SHA for 7cd63bf - Browse repository at this point
Copy the full SHA 7cd63bfView commit details -
nixos/mobilizon: do not use
ensureDBOwnership
Mobilizon can have a custom database username and it is not trivial to sort out how to remove this. In the meantime, for the upcoming 23.11 release, I apply the classical workaround and defer to Mobilizon's maintainers.
Configuration menu - View commit details
-
Copy full SHA for f653734 - Browse repository at this point
Copy the full SHA f653734View commit details -
nixos/invidious: do not use
ensureDBOwnership
Invidious uses a strange setup where the database name is different from the system username for non-explicit reasons. Because of that, it makes it hard to migrate it to use `ensureDBOwnership`, we leave it to Invidious' maintainers to pick up the pieces.
Configuration menu - View commit details
-
Copy full SHA for 10baca4 - Browse repository at this point
Copy the full SHA 10baca4View commit details -
Configuration menu - View commit details
-
Copy full SHA for 82037ad - Browse repository at this point
Copy the full SHA 82037adView commit details