Skip to content
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

modules/systemd: don't install home.conf example #85368

Closed
wants to merge 1 commit into from

Conversation

@alyssais
Copy link
Member

alyssais commented Apr 16, 2020

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.

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.
@Emantor
Copy link
Contributor

Emantor commented Apr 16, 2020

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/.

@Mic92
Copy link
Contributor

Mic92 commented Apr 16, 2020

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 users-groups.nix. 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.

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.

@Mic92
Copy link
Contributor

Mic92 commented Apr 16, 2020

Regarding being able to override entries. Should we prefix nixos.conf with a suffix to give it higher priority?

@Mic92
Copy link
Contributor

Mic92 commented Apr 16, 2020

Does #85371 fix your problem you are trying to solve with this PR?

@alyssais
Copy link
Member Author

alyssais commented Apr 16, 2020

@alyssais
Copy link
Member Author

alyssais commented Apr 16, 2020

@alyssais
Copy link
Member Author

alyssais commented Apr 16, 2020

@Mic92
Copy link
Contributor

Mic92 commented Apr 16, 2020

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.

@alyssais
Copy link
Member Author

alyssais commented Apr 18, 2020

@puckipedia
Copy link
Contributor

puckipedia commented Apr 18, 2020

Not only that, but home.conf creates subvolumes on btrfs, which goes against the whole NixOS concept of completely deterministically setting up your machine.

@Mic92
Copy link
Contributor

Mic92 commented Apr 18, 2020

Not only that, but home.conf creates subvolumes on btrfs, which goes against the whole NixOS concept of completely deterministically setting up your machine.

How is this not deterministic?

@Mic92
Copy link
Contributor

Mic92 commented Apr 18, 2020

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?

We would patch this out for sure, but such a directory is likely in a new file rather than home.conf.

@puckipedia
Copy link
Contributor

puckipedia commented Apr 18, 2020

How is this not deterministic?

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 /srv on my non-server machines, and there's no reason for /home to be a subvolume. I'd have set it up that way if I desired it to be so.

such a directory is likely in a new file rather than home.conf.

Dumb question maybe, but what makes /srv being in home.conf different from, say, /usr/lib being in home.conf?

@Mic92
Copy link
Contributor

Mic92 commented Apr 19, 2020

How is this not deterministic?

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 /srv on my non-server machines, and there's no reason for /home to be a subvolume. I'd have set it up that way if I desired it to be so.

That's fair. You can add the following to lines:

x     /home                  -    -    -     -           -
x     /srv                  -    -    -     -           -

to disable the default behavior. Otherwise it is handy if those directories are created with the right permissions/owner for majority of users.

@Mic92
Copy link
Contributor

Mic92 commented Apr 19, 2020

@flokli
Copy link
Contributor

flokli commented Apr 19, 2020

Hm, I think #85371 should allow overriding things and be merged first.

We should check back with upstream why /srv was added to home.conf.
This probably should be in a distro-specific file, or a fhs.conf file, but certainly not in home.conf.

@alyssais
Copy link
Member Author

alyssais commented May 4, 2020

@arianvp
Copy link
Member

arianvp commented May 4, 2020

FYI the example directory and what is in there and what not is something we came up with; not something that is present in systemd's upstream itself.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/systemd/default.nix#L238-L240

But yeh I agree that the systemd package should be treated as a "pick n place" source; not a definite source of truth. E.g. we do not ship sysusers.d either because our user-groups activation script implements the same behaviour.

I'm personally in favor of not shipping home.conf at all as I don't see it solving a particular problem at the moment (/home is already created anyway is it?)

@flokli
Copy link
Contributor

flokli commented May 4, 2020

The reasoning behind /home being a subvolume is explained in systemd/systemd@fed2b07:

tmpfiles: make /home and /var btrfs subvolumes by default when booted up with them missing

This way the root subvolume can be left read-only easily, and variable
and user data writable with explicit quota set.
(as per the tmpfiles.d docs, on non-btrfs filesystems, it'll just be a directory.)

This doesn't sound too wrong for me. I personally like to be able to use the btrfs send/receive/snapshot functionality for /home.

/home being the home directory for a specific user sound a bit exotic to me - assuming overriding these directives since #85371 is possible, would using this to make it non-writable again work for you, too?

@Mic92
Copy link
Contributor

Mic92 commented May 5, 2020

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.

@Mic92
Copy link
Contributor

Mic92 commented May 11, 2020

The snippet above should make it easy enough to remove home.conf in case it is not wanted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.