nixos/invidious: cleanup, allow for easy scaling and load balancing, add http3-ytproxy #265857
Conversation
github-actions
bot
added
6.topic: nixos
ofborg
bot
added
10.rebuild-darwin: 0
999eagle
force-pushed
the
feat/invidious-scale
branch
from
128d46c
to
bb41dc6
Compare
999eagle
changed the title
ofborg
bot
added
8.has: package (new)
999eagle
force-pushed
the
feat/invidious-scale
branch
from
bb41dc6
to
cf031a0
Compare
999eagle
force-pushed
the
feat/invidious-scale
branch
from
cf031a0
to
7db61ab
Compare
|
Generally looks good! I don't have the time for a detailed review, but ping me before it gets stuck too long :) |
…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
force-pushed
the
feat/invidious-scale
branch
from
7db61ab
to
a285d2c
Compare
999eagle
force-pushed
the
feat/invidious-scale
branch
from
a285d2c
to
5d28c72
Compare
|
@RaitoBezarius I've changed this module to use @infinisil it'd be great if you could review this :) |
Thank you so much!! |
999eagle
force-pushed
the
feat/invidious-scale
branch
from
5d28c72
to
2ba8521
Compare
999eagle
force-pushed
the
feat/invidious-scale
branch
from
2ba8521
to
978daba
Compare
|
Updated so the database changes now only apply by default for |
What if a user is following |
|
If |
Oh I see ! I missed the warning part. Thanks :) |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-already-reviewed/2617/1290 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-already-reviewed/2617/1318 |
|
@999eagle Can I ask you to resolve the comments and resolve the conflict? Then, we can go for the merge. |
999eagle
force-pushed
the
feat/invidious-scale
branch
2 times, most recently
from
30da208
to
2a2cf92
Compare
See the note on https://docs.invidious.io/db-maintenance/. Manual maintenance is no longer required.
…tests Using PostgreSQL 15 without the init script fails due to NixOS#216989.
This makes sure we don't need any workarounds for running Invidious with a local PostgreSQL database. Changing the default user should be fine as the new init script for PostgreSQL automatically creates the new user and changes the existing database's owner to the new user. The old user will still linger and must be removed manually. See also: NixOS#266270
999eagle
force-pushed
the
feat/invidious-scale
branch
from
2a2cf92
to
24e561f
Compare
|
The conflict is in the release notes, so as long as the release notes for 24.05 are relatively short, it will conflict again very quickly. I've rebased to fix the conflict now. |
Don't hesitate to resolve them otherwise you get stuck in this "everyone is waiting on each other" hell and we can still improve further your stuff later on. :) |
Description of changes
This PR contains mainly three changes:
services.invidious.serviceScaleandservices.invidious.addresshave been introduced to allow scaling Invidious to multiple services as recommended in https://docs.invidious.io/improve-public-instance/#2-multiple-invidious-processes and to allow configuring Invidious to not listen on0.0.0.0.services.invidious.http3-ytproxy.enablehas been introduced to configurehttp3-ytproxyaccording to https://docs.invidious.io/improve-public-instance/#3-speed-up-video-playback-with-http3-ytproxy.Tests have also been fixed by switching to PostgreSQL 14 (see #216989) and new tests for the scaled Invidious deployment and http3-ytproxy have been added.
I've deployed these changes to my own Invidious instance at iv.catgirl.cloud for testing.
CC: @sbruder @GaetanLepage @infinisil
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)