postgresql_15 requires granting permissions on schema public, ensureUsers insufficient #216989
Assignees
Labels
0.kind: bug
Something is broken
Comments
Check out #203474. |
13 tasks
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/nextcloud-does-not-start-anymore/32891/3 |
12 tasks
13 tasks
38 tasks
13 tasks
|
I'm wondering if this PR #255961 has been considered, it looks like it gets the job done and its quite far along. |
Merged
13 tasks
|
Yes and I think it's a bad idea because it expands on the ensure anti-pattern. I have a proposal lying around that will require a bit of polishing, but I'd submit it tonight. |
|
Which anti pattern do you mean? I couldn't find a comment mentioning this yet. Also I hope I find some time to test this today, so kindly give me a ping. |
|
Basically #206467. |
7 tasks
ambroisie
added a commit
to ambroisie/nixpkgs
that referenced
this issue
Nov 11, 2023
This is a work-around for getting the tests working until NixOS#216989 is fixed.
13 tasks
RaitoBezarius
pushed a commit
to Ma27/nixpkgs
that referenced
this issue
Nov 13, 2023
…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
999eagle
added a commit
to 999eagle/nixpkgs
that referenced
this issue
Dec 17, 2023
…tests Using PostgreSQL 15 without the init script fails due to NixOS#216989.
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/what-about-state-management/37082/1 |
Lainera
pushed a commit
to Lainera/nixpkgs
that referenced
this issue
Dec 20, 2023
…tests Using PostgreSQL 15 without the init script fails due to NixOS#216989.
10 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I was trying to set up Nextcloud on 22.11 through NixOS modules, and failed with pkgs.postgres_15. It was trivial after downgrading to pkgs.postgres_14.
Steps To Reproduce
Steps to reproduce the behavior:
services.postgresql.package = pkgs.postgresql_15;nixos-rebuildand observe the following error in the journal:You can reproduce this with
psqlif you prefer, but the above are steps from the manual, using the latest available postgres.Expected behavior
nixos-rebuildsucceeds, the Nextcloud database is initialized properly. This does work withservices.postgresql.package = pkgs.postgresql_14;Additional context
To quote the postgresql docs:
It appears this only affects fresh databases.
If I understand correctly, to support the
services.nextcloudmodule, theservices.postgresqlmodule needs to provide a way to either set the owner of the database or to grant permissions on a schema. Neither seems to be available, although, naturally, it's possible I missed something. It's almost possible to useensureUsersto do this: the syntax for theGRANTdoes the right thing, but the problem is that you need to be connected to the database in question, and thepostgresql-post-startscript does not do that.Notify maintainers
@thoughtpolice @danbst @globin @marsam @ivan
Metadata
"x86_64-linux"Linux 5.15.92, NixOS, 22.11 (Raccoon), 22.11.20230207.af96094yesyesnix-env (Nix) 2.11.1"nixos-22.11"/nix/var/nix/profiles/per-user/root/channels/nixosThe text was updated successfully, but these errors were encountered: