Home Manager module v2, systemd mounts, options refactoring, tests and more#272
Home Manager module v2, systemd mounts, options refactoring, tests and more#272
Conversation
talyz
force-pushed
the
home-manager-v2
branch
2 times, most recently
from
f226ec5 to
0e97b02
Compare
|
From what you've described it sounds a lot like what i transformed my impermanence setup to be like a while back (but much more fleshed out); I made change that just redirected all my home declarations for it to the NixOS module to avoid bindfs or symlinks. Definitely a major improvement with regards to performance. It may be worth trying to include a notice, or a cleanup for BindFS mounts to prevent any issues during the switch over as I imagine #249 may rear its head out; This change also cause an issue when attempting to live switch a configuration due to in use mounts but that's likely unsolvable. |
|
Curious @talyz , I haven't read too much into these changes, but does this fix the current issue with symlink folders not being created? AFAIK there currently is a issue with symlink not creating the folder in the state directory. So you end up with a symlink pointing to a folder that does not exists. EDIT: Yes it does, you linked this one in the fixes :) #177 thanks! Looks awesome |
|
I think I have found a bug in the new home-manager implementation. Source and target directory are also not created with the same permissions, is that intended behavior? |
|
I just set this up and it's working great, no complaints about functionality on nixos hosts. However, I use some machines with home-manager standalone and I've written my personal home-manager modules in such a way where it would be really nice to be able to disable the assertions that check if impermanence has been imported correctly (like how home-manager can disable nixpkgs version release check) or only run the assertions if any home.persistence submodule is enabled. |
|
I think it's worth mentioning that the unit-based approach was pioneered by @WilliButz already with https://github.com/nix-community/preservation. Perhaps an exchange of experiences could help? |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/are-there-better-alternatives-to-the-impermanence-module/64701/8 |
|
Just got this set up on my machine
I made a small module to track stray files in persisted directories and files that haven't yet been persisted, and having everything now be in the same format and structure now is very helpful!
The migration to v2 was very smooth thanks to these assertions I haven't encountered any problems so far, I use the impermanence module across my entire system Thank you for all the hard work @talyz ❤️ I have been using impermanence since I first started using NixOS a year ago |
MattSturgeon
left a comment
MattSturgeon
left a comment
There was a problem hiding this comment.
I'm not very familiar with the inner workings of impermanence, but I thought I'd give the diff a quick once-over to see if I could help with any small suggestions 🙂
| { pkgs | ||
| , lib | ||
| , name | ||
| , config | ||
| , homeDir | ||
| , usersOpts ? false # Are the options used as users.<username> submodule options? | ||
| , user # Default user name | ||
| , group # Default user group | ||
| }: |
There was a problem hiding this comment.
If going with my suggestion to promote this to a "real" option declaring module, you'd split these args something like:
| { pkgs | |
| , lib | |
| , name | |
| , config | |
| , homeDir | |
| , usersOpts ? false # Are the options used as users.<username> submodule options? | |
| , user # Default user name | |
| , group # Default user group | |
| }: | |
| # Usage: lib.modules.importApply ./submodule-options.nix { /* args */ } | |
| # Applied args | |
| { pkgs | |
| , outerConfig ? null | |
| , homeDir | |
| , usersOpts ? false # Are the options used as users.<username> submodule options? | |
| , user # Default user name | |
| , group # Default user group | |
| }: | |
| # (Sub)module args | |
| { lib | |
| , name | |
| , config | |
| }: |
The rest of this file is already a valid module and shouldn't need any changes, other than to handle outerConfig as needed.
|
I'm thinking of setting up impermanence (again) should I wait for this to land? Or maybe use this PR directly? |
Misterio77
left a comment
Misterio77
left a comment
There was a problem hiding this comment.
This looks amazing, and fixes pretty much everything that was wonky about the HM module before. Thanks so much for the work you put into this, it's so much better than the previous approach.
|
I've been using this daily for a bit over a month now, I only have two issues with the new method
Other than that, I have no issues! |
|
I'm trying to test this out, working through the assertions. I'm getting the error: I don't have that option set anywhere in my config. I've never used it. |
Never mind, I forgot I was using Geometer1729/persist-retro. |
|
Sharing some of my experiences switching to the V2 branch. Firstly, once I rebuilt I got this error: Explicitly persisting the state folders resolved but doesn't happen on V1. Now I'm getting this error relating to Plasma-Manager: Not had a chance to get to the bottom of what's causing this yet. Maybe need to use tmpfiles to create the config directory. The only files I explicitly persist for plasma are: |
It looks like my intermediate folders (for example .config) are getting created with root permissions. This means anything that tries to create a folder in say, .config or .local doesn't have permission. Any ideas? |
|
I cannot seam to even eval the PR, it fails giving me this error: What I am doing wrong? EditAparently Lix is stricter than Nixcpp when it comes to this: Lines 182 to 190 in a2f08d2 I can confirm it works fine using Nix. |
|
I switched the repo in the flake.nix |
This moves the user option out of the options file, keeping only the submodule options which are also merged and unified to work on both the system root and user level.
Had to be done in a separate commit for git to track the changes properly.
If the NixOS persistence module and the Home Manager NixOS module are imported, automatically add the Home Manager module to all Home Manager users imports, easing transition and lowering the risk of incorrect usage.
Yeah, if it was possible to do it without requiring it to be loaded as a NixOS module, that would of course be preferable. However, this was already a requirement in v1 due to activation timing issues, where the users' activation scripts have to run before the users log in. |
More context would be necessary to figure this out. Did you use |
I don't know enough about preservation or its origins to say for sure, but it sounds likely! |
If used as intended, it would. The system Feel free to work on a way to handle this, though! It definitely sounds like a nice feature to have. |
Just switched to v2 and I'm running into the same issue. Home-manager can't create the config symlinks in |
|
That happens if impermanence has to create parent dirs. Since it runs a mkdir -p (as root), then it chowns the specified file/dir to what you set it to. You can solve it by using .tmpfiles to pre create (with the correct perms)/chown the parent directories. |
|
Yes, after doing some more troubleshooting, I also figured out the cause. I don't really like the tmpfiles solution, so I went back to using v1 until a proper solution is added. Currently, I don't see any benefit of v2 for me (at least, I'm not aware of any). |
|
It's actually an issue in v1 too, idk why it would differ between v1/v2. |
|
Weird because under v1 I don't run into this issue - there all parent folders belong to my user and not to root. |
Also having this issue, unfortunately. Having to use tmpfiles to fix it kinda feels like a regression in my opinion... |
|
I think that the reason for the breakage is that (from my understanding) the impermanence now runs as root across the whole system. I think that having "impermanence" auto chown folders in a users home dir may be a good solution, but I'm weary of possible side effects. So although a somewhat weird interface, I still think tmpfiles is a good solution, as they are the permission/file management solution across nixos. From my understanding, the reason that it doesn't always break is due to other services themselves using tmpfiles/folders already existing. |
|
@philipkbh @somasis @upidapi I've created a new issue highlighting this breakage. IMO creating parent directories with the right ownership (or copying over the ownership from the existing directories in persistent storage) should be automated by impermanence by default and not left to the user to do manually. This issue didn't happen with V1. |
20 participants
This PR is a pretty big refactoring and changes a lot of things. When viewing the diffs, I would recommend hiding whitespace changes.
Replace the current Home Manager module implementation with an interface to the NixOS module
This is the main goal. The other changes, while useful on their own, were mostly done to make this doable.
This should close a whole bunch of issues related to the Home Manager module and massively lessen the maintenance burden of the project, since there's now one unified implementation instead of two disparate ones. This also means that things that were previously not possible, such as using real bind mounts, now are.
The main caveat is that the NixOS module has to be imported into the same configuration as Home Manager for this to work. I can't find any good reason to use the Home Manager module exclusively, but if you have one - do tell.
There are some minor UI and feature differences, mainly on the positive side, but assertions should have been added for any removed or changed functionality.
Fixes #247, fixes #248, fixes #207, fixes #184, fixes #177, fixes #142, fixes #130, fixes #45, fixes #198, fixes #232, fixes #256, fixes #257
Move all submodule options out to a separate file
This makes it possible to import shared submodule options where needed, reducing duplication and complexity.
Use
systemd.mountsinstead offileSystemsfor bind mountsThis removes the need for the
homeoption, as the home directory can be deduced automatically. This was previously not possible due to a long-standing issue in nixpkgs: NixOS/nixpkgs#24570.It also greatly simplifies the
neededForBootdirectory creation, since it's either handled automatically by systemd in the initrd or easily done in thepostMountCommands.Fixes #179, fixes #222, fixes #227
Allow setting file linking method
For some files, it's preferable to use symlinks over bind mounts - for example when a program wants to rename the file temporarily. This adds an option (
method = "symlink") to keep a file a symlink even when the file exists, which would otherwise trigger the usage of a bind mount.Closes #146
Add basic NixOS tests
Test the basic and critical functionality of the modules. The tests can be run with
nix flake checkand are run automatically in the CI checks. Should have been added a long time ago - I've just been lazy :)cc @Ma27 @eyJhb @nazarewk @MattSturgeon @colemickens @SrEstegosaurio @DaRacci @mjm @collinarnett @zackattackz