Cannot create root user with den v0.5.0

[xdbr]

Before creating an actionable issue, here's what I observed:

From what I understand, den tries to create a home-manager-managed home-directory for a root user for which no home-managed directory was requested.

Running nix run ".#write-flake" && nix flake check fails with the following error message:

error: The option `home-manager.users.root.home.homeDirectory' has conflicting definition values:
       - In `/nix/store/ddjzg6dfk2a6i4kpdkrkyqz58rh0mhbr-source/modules/aspects/provides/define-user.nix, via option den.provides.define-user.<function body>.includes."[definition 1-entry 1]".includes."[definition 1-entry 1]".homeManager': "/home/root"
       - In `/nix/store/zcb71zw9z034af9lrv07x8xcy3hagxqc-source/nixos/common.nix': "/root"
Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

Steps to reproduce:

• Create a user named root for a certain machine in den.nix:

{
  den.hosts.x86_64-linux.barbara-bar.users.dbr = {};
  den.hosts.x86_64-linux.barbara-bar.users.alice = {};
  den.hosts.x86_64-linux.barbara-bar.users.root = {};
  den.homes.x86_64-linux.dbr = {};
  # NOTE no home-management requested for the other users!
}

Notably, no home-managed capabilities were requested for users alice or root.

For the user alice, nix flake check doesn't throw an error, only for root – although, as I understand, no home-management should be created for user alice and neither for root?

I believe the source of this problem are the settings in den.defaults, namely this line making the userContext bigger than requested and in contradiction to there being no inventory definition like den.homes.x86_64-linux.root and thus no request for a home-manager context to be created?

[vic]

Where is define-user included in your setup, is it in den.default ? if you had a root user, define-user would not be needed for it.

define-user is opt-in, as all den-batteries, so it is up to you to include them in the correct place for your use case. If you are willing to have a root user, either create a wrapper around define-user that does not applies when user is root, but does for all others. or include define-user on each user aspects except for root.

[vic]

The default template is a starting point, with things I believe most people would need to get started right away (it enables home-manager, nix-darwin) so people can remove code instead of having to find what to add. That is why the default templates includes also a couple of hosts for you, the idea is that people modify it to their needs, once cloned it is yours completely, delete it all if you will. Perhaps, adding a new "empty" template ? even more basic than default ? Default is there to provide a batteries-included experience, you can remove the batteries and use your own, it is one of the design decisions of den, even home-manager is not mandated by Den.

I was a bit reluctant to even add batteries in Den. but some things like home-manager are better as provided by Den, while still optional. Other batteries are convenience, and examples people can use to create their own, it is not my intention to add more batteries now, nor change much how they work.

It is awesome you and other people are integrating and using other tools I've never heard of, well I had heard of deploy-rs, but have never used it. So I'd like to help, but I have no idea on how it works. In theory if you can build your nixosConfiguration locally it can be deployed I guess.

And no, you don't have to setup your entire repository whenever the batteries change, they are just mixed in. Those few Den includes will be shipped with den, but will likely have more aspects in other people's repos and denful repo. That's the whole idea why I'm making this, so we can share aspects.

[vic]

Something is really, really off here. It's really hard to reconstruct what is giving me so much pain at the moment: I am trying to deploy using deploy-rs, but can't see yet what exactly is going on or where the actual issues are. This has been giving me troubles for 2 days now and I have tried to come up with different solutions, a separate root user, this, that, but I don't see what it is actually.

Feel free to use a thread for this if you want, I'm willing to help on anything I can. It is people like you, actually using Den who make are making it work for them, it is not me, it is people like you who are shaping it, eg, we recently added parametric { } syntax for someone's use-case. So, believe me, I really, pretty much appreciate you using Den even if it has unpolished edges right now (we are in 0.x series). I also put a lot of my daily time into it. debugging and trying to fix the errors people report, I'm always trying to fix them asap, I'm not trying to add disrupting features, just make it stable enough for all of us.

I'm with you in you pain, believe me (software is like that a times), but even pain has fruits at the end, be it learning or a finally stable Den.

Brave are the people who are willing to go where others would not go without having strong guarantees. Thanks for being brave enough to try Den, and contributing with your inputs and how you are using it.

[vic]

That's also why I have (and ask people for) tests, so we can make sure we have no regressions, only an even more stable Den each day. Of course I need help, I cannot imagine all use cases. When I'm not fixing Den I'm trying to use it in my own infra, so I'm also an user of it, and because of that it is important for me for it to work.

[xdbr]

Thanks for you encouraging words, and I full-heartedly appreciate your countless efforts @vic! Of course all of this is at a very early of development. I'm trying to work out examples and tests, although in my setup even getting those to work is currently a little painful :). The vm goes into an infinite ballooning loop on the server I'm trying to run it from. If I could describe this better, I would let you know, but I'm still in trenches here...

I'm currently just completely lost with how to create a suitable root user for deploy-rs based deployments and have tried a dozen different ways – all to no avail.

Of course I will continue to push through although it can be a little frustrating at times... But it's all good :)

[xdbr]

In any case, setting up a privileged root user for my use case is just too troublesome at the moment and I don't have the slightest idea why that is...

[xdbr]

I could finally avoid a root user for deploy-rs deployments after jumping through a couple of hoops (note that the extraRules to limit dbr's capabilities to only the necessary ones for deploy-rs doesn't work yet):

  den.aspects.dbr = {
    nixos = {pkgs, ...}: {
      services.openssh.settings.AllowUsers = ["dbr"];
      security = {
        sudo = {
          wheelNeedsPassword = false;
          # extraRules = [
          #   {
          #     users = ["dbr"];
          #     commands = [
          #       {command = "/nix/store/*-activatable-nixos-system-*/activate-rs";}
          #       {command = "/run/current-system/sw/bin/rm /tmp/deploy-rs-canary-*";}
          #     ];
          #   }
          # ];
        };
        pam = {
          sshAgentAuth.enable = true;
          services.sudo.sshAgentAuth = true;
        };
      };
      users.users.dbr = {
        isNormalUser = true;
        packages = [pkgs.vim];
        extraGroups = [
          "wheel"
          "networkmanager"
        ];
        uid = 2000;

        openssh.authorizedKeys.keys = [
          ''ssh-rsa ...'
        ];
      };
    };

Marking this discussion as answered