iso: systemd service startup

[blaggacao]

Expected Behavior

The live cd acting as bespoke bootstrapping medium, only a necessary set of systemd modules should be started instead of starting up the complete os

Current Behavior

While all relevant closures are included, and therefore act as a cache to the nixos installer, also all systemd services of the target host configuration are launched.

Possible Solution

• Keep the closures & avoid service startup
• don't bother and just ssh into the target machine

Steps to Reproduce

This happens with any current iso live installer.

Context

Just a random example:

• A host is configured to launch cage and server a browser app in kiosk mode
• We could ssh into the target machine, here
• But still it might be beneficial to avoid service startup (there might be cases where this is indeed fully prohibitive, for example if those services involve some sort of state or host identity).

/cc @Pacman99

[Pacman99]

I have a couple ideas to tackle this, but it might require adding more code. So I think it would be good to get #170 done first.

[blaggacao]

Per #197 (comment) it was decided to not exempt user systemd services as per the argument made therein:

User services are usually really light if any are even defined. And it could be nice to login to your user and get an environment your comfortable with.

[Pacman99]

Based on the discussions in the PR's, I think this is an overview of the problems we've run into:

• Selectively importing modules introduces problematic side affects like missing users, hostName, and likely other issue we don't know of.
• Including the host's toplevel build takes up a lot of space and causes the squashfs to take a long time to build

[Pacman99]

I'm going to try investigating something that I think was suggested earlier. I want to see if its possible to import everything just as its done right now but find a way to just disable the systemd services defined in profiles.

[Pacman99]

I haven't written any code for this, but I think I've come up with a method to import everything, including profiles, but disable all systemd services defined in profiles.

[Pacman99]

This is really finicky and is a bit of an abuse of the module system, but I wrote some code to try and override systemd services:

isoServiceOverrides = profiles: with lib; (lib.evalModules {
        modules = profiles ++ modules.flakeModules ++ [
           {
            config._module.check = false;
            options.systemd.services = mkOption {
              default = {};
              type = with types; attrsOf (submodule {
                config._module.check = false;
                options.enable = mkEnableOption "enable service";
              });
            };
          }
        ];
      }).config;

But this has various issues. It only overrides services explicitly defined in profiles as systemd.services or services added through the ./modules folder.
I was trying to see if it was possible to create a module that overrides all systemd services defined through the profiles. So I evaluated them with a custom option for systemd.services. And then the .config of the evaluated module is also a valid module.
I don't think this will end up being feasible in its current state, but I'm posting the code here, in the case that someone can build upon the idea.

[nrdxp]

I've worked out the logic of how to do it in some experiments, but it is a bit involved and I wasn't sure at the time if it was the best way to go. This was for #127 though, so the goal is a bit different. Essentially, we would have to evaluate each module in isolation, with only the base modules included so evaluation doesn't fail. Then we would have to determine with options were set by the default modules and filter them out of the evaluationed module. This may be pretty expensive computationally, I haven't work out the complexity yet, but it seems like it would be, and that's why I stopped there.

In theory though, at that point we would be left with just a single modules affect on the overall system after being evaluated. I was wanting this to be able to pull things out of environment.etc for any given module, thus allowing an easy compatibility layer between nix-darwin, home-manager and the like, but it should be usable to determine which services are started by a given module as well, if we can make it simpler, or perhaps combine it with layers of your implementation above.