feat: added nixos-rebuild actions to blockTypes/nixosConfigurations

[Sntx626]

I've tested all actions through the std tui for my personal systems.

Design Considerations

• I've used mapAttrsToList to reduce the amount of boilerplate drastically
• I'm elevating switch, boot, test and dry-activate with run0 - the other command shouldn't need elevated privileges

Known Issues

• The edit action fails -> This seems to be an issue with nixos-rebuild, can be ignored for this PR
• The repl action goes through but doesn't :lf . (load flake) inside the repl -> This seems to be an issue with nixos-rebuild, can be ignored for this PR
• run0 was introduced in systemd v256, the actions will fail if an older version of systemd, or another init system is used -> NixOS assumes to be running on systemd and the required version has been out for a few months.

---

That's about it. I'm not set in using run0 over sudo, it's just what my current implementation uses.

[blaggacao]

Can you fetch run0 from the inputs.nixpkgs (they are local to the system on which the user executes the command)? Or wouldn't that work in some/many scenarios for reasons private to how run0 is implemented?

[blaggacao]

https://github.com/divnix/std/blob/main/src%2Fstd%2Ffwlib%2FblockTypes%2Fkubectl.nix#L34

[Sntx626]

We could add a $@ to pass along any user supplied flags, if that's possible amd practical. That would be a bit more consistent with the way other block types handle things.

I think thats the best option.

Can you fetch run0 from the inputs.nixpkgs (they are local to the system on which the user executes the command)?

Yes, though it will only work with nixpkgs containing https://github.com/NixOS/nixpkgs/pull/307068 and forward...

Or wouldn't that work in some/many scenarios for reasons private to how run0 is implemented?

This is just a guess, but systemd v256+ should be required.

[Sntx626]

nixpkgs/unstable contains run0.

However nixpkgs/24.05 doesn't...

[womfoo]

Maybe consider having the run0 actions behind inputs.nixpkgs.lib.version > 24.05?

[blaggacao]

@Sntx626 I like @womfoo 's suggestion (hi! :wave:).

I'm not sure why I haven't merged this already.

So could you adapt and make sure to ping me again with @blaggacao ? — should be ready to merge and iterate on, if need be.

[Sntx626]

@blaggacao Should be ready for final review and merge now.

[Sntx626]

I'm using you in the follwoing comment to address all readers

Maybe consider having the run0 actions behind inputs.nixpkgs.lib.version > 24.05?

I like acting based on version, however I though a bit about this and in the end it comes down to the systemd version running on the system executing the std command.

We cannot know this during nix eval, as it is an external factor. We can only know the systemd version of the system that is defined in the nix code - which might as well be a wholly different system.

I did rewrite the privilegeElevationCommand to specifically check the systemd version:

privilegeElevationCommand = pkgs:
  if (l.compareVersions pkgs.systemdMinimal.version "256") >= 0
  then "${pkgs.systemdMinimal}/bin/run0 --setenv=PATH=\"$PATH\" "
  else "sudo ";

However I'm considering shifting the evaluation of the version to the runtime and linking a bash script in the nix code instead. I'm thinking something along the lines of:

privilegeElevationCommand = pkgs: pkgs.writeShellScript "elevate" ''
  HOSTVERSION="$(systemctl --version | head -n1 | cut -d' ' -f2)"

  if [ "$HOSTVERSION" -ge "256" ]; then
      run0 --setenv=PATH="$PATH" "$@"
  else
      sudo "$@"
  fi
'';

Though I fear this is more prone to breaking...

What's your opinion on this?

---

And yes, I fear this has gone a little bit offtopic from the inital PR. So depending on you see it, we might as well drop run0 entirely and stick with the established sudo.

[pecode]

I agree runtime check makes more sense.

Also note that 24.05 support stops at the end of the year. Might as well simplify to just run0 and then print a warning if not supported.

[Sntx626]

@blaggacao Would you mind taking another look and merging it if you're happy with it?

[blaggacao]

Agreed, this PR has seen enough cycles. If anything, let's fix it in further iteration.

@Sntx626 could you maybe illuminate on @Hajitorus 's comment, still?

[Sntx626]

Is .system a typo for .config.system.build.toplevel here? Or am I missing something that would alias to the shorter version?

I simply copied it from the blockTypes/darwinConfigurations.

Good catch! It does look like a typo, however this should be a new issue (I can look into if that's the case in about an hour).