modules/systemd: don't install home.conf example #85368
Conversation
We don't want /srv on NixOS, and /home is already created by users-groups.nix. Furthermore, systemd tmpfiles are set up post-activation, and so there's absolutely no way for a user to override them. They can't even set their own rules in systemd.tmpfiles, because "home.conf" comes before "nixos.conf" lexicographically, and so systemd always picks the "home.conf" ones.
|
Checking nixos modules: IMO this change is fine, but subsequently we should note this in the docs and fix the modules with defaults pointing to |
|
Do we also chown the permission of existing directories? Also the tmpfiles variant creates a subvolume on btrfs. In doubt we might remove the same functionality from As a whole I think we should stick to what other Linux distribution do and stick to standards. NixOS is already a special snowflake on its own and breaks with many assumption. |
|
Regarding being able to override entries. Should we prefix |
|
Does #85371 fix your problem you are trying to solve with this PR? |
|
Rouven Czerwinski <notifications@github.com> writes:
Checking nixos modules:
`lighthttpd`: defaults to `/srv/www` in the `document-root` option.
`spacecookie`: defaults to `/srv/gopher` in the `root` option.
`tftpd`: defaults to `/srv/tftp` in the `path` option.
`atftpd`: defaults to `/srv/tftp` in the `root` option.
`gitweb`: defaults to `/srv/git` in the `projectroot` option.
`vdr`: defaults to `/srv/vdr/video` in the `videoDir` option. Also conveniently adds a tmpfiles entry.
IMO this change is fine, but subsequently we should note this in the docs and fix the modules with defaults pointing to `/srv/`.
As far as I can tell none of those modules have been modified since the
/srv rule was introduced. Which presumably means they worked fine
before /srv was added in January, and will continue to work fine after.
|
|
Do we also chown the permission of existing directories?
Yes, in users-groups.
Regarding `/srv` is there a reason we should not stick to upstream's
default of choosing their location. In my experience this makes it
easier for users (relying on upstream documentation) and third-party
tools that make assumption where data is stored.
I just don't think it needs to be globally created by systemd. It's
trivial for individual users (or modules!) to ensure /srv exists if they
want it, but I don't want a useless empty top-level directory on my
system if nothing is using it. We got along fine without it until
January of this year.
|
|
Jörg Thalheim <notifications@github.com> writes:
See also #85371
This works, but produces a warning. If we can do it without the
warning, I think that would be fine for /home. I still don't think we
need /srv by default.
|
Maybe not, but it also does not really hurt to have it and I don't want to miss future changes that are applied to this file. |
|
> I still don't think we need /srv by default.
Maybe not, but it also does not really hurt to have it and I don't
want to miss future changes that are applied to this file.
I doesn't feel right to me that the systemd project should be deciding
what directories exist on NixOS. What if they decide to start
automatically creating /usr/lib?
|
|
Not only that, but |
How is this not deterministic? |
We would patch this out for sure, but such a directory is likely in a new file rather than |
Awkward wording on my end (I meant something closer to "unexpected", as nowhere in my config do I say "please put /home on a subvolume"), but if I set up my system in a certain way I don't want systemd to go ahead and say "nope that's wrong, here, do it my way". There's no need for a
Dumb question maybe, but what makes |
That's fair. You can add the following to lines: to disable the default behavior. Otherwise it is handy if those directories are created with the right permissions/owner for majority of users. |
|
Hm, I think #85371 should allow overriding things and be merged first. We should check back with upstream why |
|
/home shouldn't be automatically created by systemd either. We have
never even enforced that home directories live in /home, and we've been
creating it fine for ourselves when it actually is needed forever.
If we really need to create a btrfs subvolume for the three users using
it, we can do that in a way that doesn't break existing setups like this
broke mine. (/home is my home directory, and it's read-only to avoid
untracked state being written there by applications. With this change,
it was silently being set to read-write every boot, and even finding out
why this was happening wasted hours of my time bisecting Nixpkgs.)
The systemd files are even called "example"s. They're clearly supposed
to be something that can be adjusted by the distribution. And since our
distribution has always let home directories be placed wherever the user
wants, we should not be applying policy to /home.
Applying the NixOS overrides first is a good start, but it prints a
warning during the activation process, which has otherwise always been
completely silent (and just as well -- can you imagine how annoying a
noisy activation process would be, given how often it runs?).
|
|
FYI the But yeh I agree that the I'm personally in favor of not shipping |
|
The reasoning behind
This doesn't sound too wrong for me. I personally like to be able to use the
|
|
You can also use this to override the systemd provided file with an empty one: environment.etc."tmpfiles.d/home.conf".source =
lib.mkForce (pkgs.writeText "dummy" "");No warnings generated in this case. |
|
The snippet above should make it easy enough to remove |
We don't want /srv on NixOS, and /home is already created by
users-groups.nix.
Furthermore, systemd tmpfiles are set up post-activation, and so
it’s extremely difficult for a user to override them. They can't
even set their own rules in systemd.tmpfiles, because "home.conf"
comes before "nixos.conf" lexicographically, and so systemd always
picks the "home.conf" ones.