nixos: optionally use user service for activation (updates #2548)

[zackw]

This is an updated version of PR #2548. I am filing it like this because I was not able to figure out how to file it any other way; it is not my intention to stage a hostile takeover of @pasqui23's work, only to address one (fairly serious) problem and to make the PR mergeable as quickly as possible. I require this feature to be able to use home-manager at all and I'd really like to see it squeak under the bar for 25.05.

Description

Add an option, home-manager.useUserService, to use systemd user services for per-user activation, rather than activating all users' environments on boot using systemd system services. This option enables use of home-manager in configurations where users' home directories are not available until they log in (for example, when using pam_mount).

The documentation for the new option is:

Activate each user's environment only when they log in, using a systemd user service, instead of activating all configured users' environments proactively during boot-up.

This mode is necessary if users' home directories are not available until they log in (for example, when using pam_mount).

Other usage scenarios are still experimental. It may speed up boot when there are many users; this has not yet been confirmed. It could break configurations where the configured users do not (or do not always) run their processes within a complete systemd-managed user context.

Changes from PR #2548

1. Remove the special treatment of .ssh/config. As far as I can tell from OpenSSH's documentation, this was never necessary; sshd does not look at .ssh/config at all, so it does not need to be available pre-login. The file that does need to be available pre-login, on systems that run sshd, is authorized_keys, and the NixOS ssh service module already handles that.

   This is the piece that addresses a serious problem; the special treatment of .ssh/config was buggy and was causing any attempt (by me) to build a NixOS configuration from @pasqui23's branch to crash.

2. Expand the documentation of the new option.

3. Remove the duplicate copy of the installation section of the manual (this appears to have been added by accident).

4. Squash all patches on the branch, for ease of review, and rebase against current top of trunk (8a31864).

Checklist

• Change is backwards compatible.

• Code formatted with nix fmt or ./format.

• Code tested through nix-shell --pure tests -A run.all
  or nix build --reference-lock-file flake.lock ./tests#test-all using Flakes.

  (There are a bunch of "trace: evaluation warning:" messages but they all look to be unrelated to this change.)

• Test cases updated/added. See example.

  (I will happily add some test cases but I could use some advice first as to what sort of testing would be appropriate for a new option with global effects.)

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

Maintainer CC

@rycee @khaneliman @ncfavier

[pasqui23]

Don't worry, clearly I didn't have the time to properly develop it

[LordGrimmauld]

I relied on my own adaptation of @pasqui23's work - this is especially useful when using PAM-mounts, which i was using on my daily driver. I love to see some progress on this!

Keeping my HM fork updated was bothersome, this is nice!

[mikunimaru]

Home-manager startup at login worked fine with patch #2548. But with this new patch, home-manager doesn't start correctly at login for me.

My setup mounts the home directory at login. Patch #2548 fixed a home-manager startup issue with this setup.

Question: Did this new patch change anything related to timing (e.g., service startup order) that could affect the fix from #2548?

If this new patch breaks the #2548 fix, the old problem (where home-manager doesn't start correctly) will return, and this is a big issue for my setup.

[zackw]

@mikunimaru I want this patch for the same reason you do -- mounting the home directory at login -- and I did not intentionally change anything that should have broken this usage. I'm guessing one of the changes from home-manager master branch, that weren't included in #2548, is at fault. Can you share more details on the behavior change you are observing? What errors did you get, which operations changed their timing, etc.

[mikunimaru]

@zackw Thank you for your kind reply.
I investigated according to your advice and found that there was a problem with my local settings.
This patch works fine and doesn't break #2548.
Sorry for the noise. Looking forward to seeing this merged.

[cassandracomar]

applied this PR as a patch and it works perfectly to allow security.pam.zfs to mount/unmount encrypted home dirs. prior to this PR, the home-manager service would attempt to load the home mounts on boot and after updating the system generation, and it would hold the systemd mount even after the user logged out.

so thanks for this and I hope this gets merged soon!