NetworkManager plugins installed by default

Help
1

Hi.
It seems like Nix automatically installs several plugins for NetworkManager, which in turn pull in several heavy dependencies. I am trying to build an installation ISO without them. Does anyone know how to disable this behavior?

My config contains this line:

  networking.networkmanager.plugins = [];

Nevertheless I find NetworkManager-openconnect in my system path, which pulls in webkitgtk-2, each adding about 200MiB to the system closure.

EDIT: Might this be part of the problem?

2

yes, you can use lib.mkForce [] instead if you want to set it to an empty list of plugins.

1 Like
3

Thanks, this works, however I am still confused to why the plugins are included by default, when the default for networking.networkmanager.plugins seems to be []. Is networking.networkmanager.plugins more of a “additionalPlugins” option? If would it make sense to propose changing the name to reflect the actual semantics?

4

Another thing is that the networkmanager package still references openconnect which indirectly pulls in gtk3. I don’t see why this is necessary when I want to use neither of openconnect nor a GUI. Would it maybe be possible to offer a “minimal” package for networkmanager?

5

The reason is because of how merging things from different modules work. Those plugins are set at the normal priority level, which is the same level you are using when you don’t have mkForce, so it adds your empty list to the list that is set by default. If that default list was set with something like mkDefault then it would be at a lower priority level, so your empty list at the normal level would be used instead.

I can only speculate as to why it is done like this. Maybe it’s a mistake, but possibly the reason is that folks expect these plugins to be present and available by default, and would be surprised if by adding their own plugins, those disappeared. Maybe calling it additionalPlugins would make more sense, I don’t really have an opinion there.

6

Usually, except, if it’s compelling, we don’t offer all the variants of minimal package because this has a storage cost.

7

Understandable. So maybe it would make sense to split this option into plugins and additionalPlugins, but admittedly it is not a huge issue…

8

It was a compromise between adding a ton of options and being able to enable extra plug-ins without having to repeat the defaults. See also the following discussions:

It is still a list of plug-ins, just that the default is defined implicitly with a different priority to allow the aforementioned.

I think I would be okay with removing the option definition, as long as it is kept in the ISO image (and maybe in the generated config template), and properly announced in the release notes.

This is because Nix does not have the concept of optional runtime dependencies so the only option is relying on some nexus (e.g. global file system or environment variable), which is fragile so the less we rely on those, the better (plug-ins are already enough). Hardcoding is simple and reliable at the cost of closure size. Here, I think it is worth it.

Proper solution would be moving the openconnect-specific part into networkmanager-openconnect as mentioned here networkmanager pulls in gtk3+ by default, can't seem to disable it either · Issue #196067 · NixOS/nixpkgs · GitHub

2 Likes
9

Thanks for the explanation and additional context. Well if nm itsself links these dependencies I guess there’s no way around it.

As for the plugin option: Is there a reason against allowing overriding by default? If NixOS wants to be able to ship a default list of plugins that is not regularly changed by the user maybe it should be moved to an option that represents these semantics, e.g. includeDefaultPlugins (bool) or defaultPlugins (list).

10

Why do you think overriding is being not being allowed? There is mkForce and it becomes a habit pretty quickly. This is a matter of sensible defaults, not “preventing” anything. I rather have a single mechanism that works everywhere than figure out the choice of options for every single module.

11

This is a matter of sensible defaults

This is what I mean. The way it is now, it is not presented as default, at least not in user-facing documentation like search.nixos.org. Of course it can be overridden (as can pretty much anything in NixOS), but that is not my point. To find out about the “default” plugins the way it is now you have to dig through several Github issues and read the module source. I think especially for new users this is a too complicated and does not align well with the (perceived) semantics of mkDefault and mkForce.

1 Like
12

The Module also creates several Users and Groups that seem to be only needed by optional Plugins, that can’t be easely removed.

  • mkForce []-ing the Plugin doesnt effect the Users/Groups
  • user.user. doesnt seem to provide a way to disable defined users, excpedt by mkForce, but
  • mkForce {}-ing here would mean you would still need to re-add every other User/Group
13

Well, the docs do explicitly mention that (though it could probably be made clearer).

For what it’s worth, modules acting like profiles (i.e. modules that set other options unconditionally) is pretty common (especially with, but not limited to, desktop environment module) so you generally have to check the source anyway.