NetworkManager without desktop manager (e.g. KDE)

Help
1

Hello,

I had NixOS going on this ThinkPad laptop, and then recently re-installed on to a new drive. I have been manually copying over relevant pieces from the old and new configuration.nix files, mostly going fine.

One thing that I have come across is that the WiFi settings in NetworkManager work under KDE, but the password needs to be re-entered constantly when running Xmonad and no desktop manager. Essentially, the latter case is not writing to /etc/NetworkManager/system-connections/, so even putting it to sleep forces a re-entry. My user is in the network-manager group.

While KDE gets the job done, it’s not my preferred environment, so of course I would prefer to address the root of the problem. Any thoughts?

2

This may or may not be what you want, but in my case I have :

    networking.networkmanager.enable = true;
    users.users.korfuri.extraGroups = [
      "networkmanager"
    ];
3

Thanks, @korfuri, but I have those settings enabled already.
It seems to be more like around the permissions to create those config files that go under /etc/NetworkManager/system-connections/. In other words, the nmcli or GUI applet let me enter the password, but aren’t able to create the files in the root-owned config directory. I’m guessing it’s the job of another tool to do that, that is somehow not quite configured.

4

KDE and Gnome have their own password managers. For example, KDE has Wallet. Is that what’s missing?

5

I think that’s closer to the problem, yeah. I installed initially with KDE (as before), then added i3 and xmonad after the fact. I’m using SDDM as the login manager, and it does launch kwallet, and I have nm-applet loaded in my WM configs. So, I suspect that the issue is more like one of telling nm-applet, or any other tools, where to find secrets.

6

Some progress, if not real clarity just yet:

Trying to change settings for the kdewallet instance would only work within KDE, I think because of some other daemon that it expected (policykit?) I think the original wallet I had defined was Blowfish-encrypted, not based on a GnuPG key, which seems to be expected based on the KDE docs at Chapter 1. Introduction. I deleted and re-created a wallet (now GPG-based) called kdewallet.

From within KDE, I did turn off the “Use KWallet for the Secret Service interface.” Now, the AP passwords are no longer in kdewallet, and the system cheerfully connects to the APs (which I can configure now in NetworkManager, and it’s saved… somewhere.)

It appears that my initial problem might just be resolved, but I can’t say I’m comfortable without knowing how.

7

OK, I’m going to call it fixed, at least for my case.

I think (most) of the original problem was in defining kdewallet as blowfish-encrypted, rather than GPG.
Other than that, digging around was considerably hampered by not having the other KDE daemons running, so that trying to make changes via kwalletmanager or the like would fail with “permission denied” messages.

Now, for solutions:

  • I didn’t find documentation generally on choosing which sort of secrets store to use, as apparently pass and keepassxc can be used (somehow).
  • I set “services.gnome.gnome-keyring.enable = true;” in my configuration.nix, so that gnome-keyring is available.
  • I added gnome.seahorse to my pkgs, as I am otherwise not using any Gnome functionality at this time. This lets me browse and edit my Gnome keyring.