nixos/miniflux: add options for all secret files#429983
nixos/miniflux: add options for all secret files#429983jfly wants to merge 1 commit intoNixOS:masterfrom
Conversation
|
|
Since you're editing a module, the title prefix should be |
I added these new options: - `services.miniflux.adminUsernameFile` - `services.miniflux.adminPasswordFile` - `services.miniflux.oauth2ClientSecret` - `services.miniflux.pgpassFile` I deprecated `services.miniflux.adminCredentialsFile` in favor of the above options. The new options all use systemd's `LoadCredential` functionality, so people don't have to futz around with permissions. I learned the hard way it's particularly annoying to create a `PGPASSFILE` that works: now that's all abstracted away for people.
f8ce0d5 to
0a2fd56
Compare
|
(pinging the miniflux maintainers. please let me know if this is bad etiquette) |
|
This would actually break my current use of the module. I'm not sure why we need all this complexity when pgpass requiring the hostname:port really negates its value over specifying the database URL in an env, in my opinion. You can't change one without the other. EnvironmentFile doesn't require you to mess with permissions, since it's read by systemd. Here's what I currently have: age.secrets."miniflux-secrets.env".file = ./secrets.env.age;
services.miniflux = {
enable = true;
adminCredentialsFile = config.age.secrets."miniflux-secrets.env".path;
};Where the env file has ADMIN_PASSWORD=
DATABASE_URL=
OAUTH2_CLIENT_SECRET= |
There was a problem hiding this comment.
Sorry, this is a no from me as-is. I don't see the value in the credentials file/script abstraction for most of the environment variables. We can rename the option to make it clear it's an EnvironmentFile and if really necessary expose a pgpass file option.
Ah, bummer. I was under the mistaken impression that the goal was for nixos modules to expose secrets as standalone options. I had sent in PRs in the past that were accepted that make this sort of change: #388853. I've since talked to some people, and now understand that this is just a style thing that's up to the module maintainer. I do still see value in exposing secrets as individual knobs, but this definitely isn't the venue to debate that. Perhaps vars (or something like it) will encourage us all to get on the same page someday. |
|
Please also note that the approach you used here is unnecessarily indirect and also incomplete. Indirect, because Incomplete, because you forgot a bunch of additional secrets. In my opinion this should have been a free-form secrets option, similar to I, too, don't understand why you decided to go with Either way, for those that may find this in the future or whatever, you can use e.g. {
services.miniflux.config.OAUTH2_CLIENT_SECRET_FILE = "/run/credentials/miniflux.service/OAUTH2_CLIENT_SECRET";
systemd.services.miniflux.serviceConfig.LoadCredential = [
"OAUTH2_CLIENT_SECRET:/run/secrets/miniflux/oauth2-client-secret"
];
}or even |
|
Thanks, @emilylange, good to know. |
I added these new options:
services.miniflux.adminUsernameFileservices.miniflux.adminPasswordFileservices.miniflux.oauth2ClientSecretservices.miniflux.pgpassFileI deprecated
services.miniflux.adminCredentialsFilein favor of theabove options.
The new options all use systemd's
LoadCredentialfunctionality, sopeople don't have to futz around with permissions. I learned the hard
way it's particularly annoying to create a
PGPASSFILEthat works: nowthat's all abstracted away for people.
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.