Wandering Thoughts archives

I should probably learn command-line NetworkManager usage

I'm generally not a fan of NetworkManager on the machines I deal with, but I do wind up dealing with it at the command line level every so often, most recently for setting up a WireGuard client on my work laptop. There was a time when it felt that NetworkManager was the inevitable future of networking on Linux even on servers, but fortunately systemd-networkd has mostly made that go away. Still, systemd-networkd has limitations and isn't as comprehensive as NetworkManager, NetworkManager is the face of networking on a lot of Linux configurations, and someday I may be forced to deal with NetworkManager on a regular basis.

(Fedora keeps threatening to remove the ifup and ifdown scripts that drive my DLS PPPoE link, and systemd-networkd doesn't currently have support for PPPoE.)

All of this leaves me feeling that not really knowing even the basics of NetworkManager general concepts and command line usage is a gap in my practical Linux knowledge that matters, and that I should fix. Well, to put it bluntly, it feels like I'm burying my head in the sand. Even if I never really use it, learning the basics of NetworkManager command line usage would give me an informed opinion, instead of my current mostly uninformed one.

The low impact approach to learning NetworkManager command line usage would be to explore it on my work laptop, which already uses NetworkManager. I normally use the Cinnamon Network Manager GUI (which is not nm-applet, it turns out), but I could switch to doing my network manipulation through the command line, and also read and try to understand all of the configured connection parameters.

The high impact approach would be to try to set up a version of my home desktop's DSL PPPoE connection in NetworkManager. Many years ago I configured a version of my DSL connection on my laptop, so in theory I could cross-check my NetworkManager flailing against that version (although I should first make sure it still works). As a side benefit, this would leave me prepared for when Fedora carries through its threat to remove ifup and my current DSL PPPoE setup immediately stops working.

(I've written this partly in the hopes of motivating myself into doing some NetworkManager learning, even if I don't manage much.)

The tiny irritation of ZFS's 'zpool status' nagging you about upgrades

One of the tiny irritations of operating ZFS for a long time is that eventually, running 'zpool status' on your pools would produce a multi-line nag about upgrading them to the latest version of ZFS. I assume that this was added to 'zpool status' output so that you wouldn't be unaware of it, but the size of the message was far too large for its actual importance. Back in the old days of Solaris 10, 'zpool status -x' even included pools that could be upgraded (this was one of our Solaris 10 update 6 gotchas), but fortunately people have gotten more sensible since then. Now it's only a multi-line message.

Perhaps you think I'm exaggerating. No, really, here is the message from the latest version of OpenZFS:

status: Some supported and requested features are not enabled on the pool.
        The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.

That's five lines for what should be one line. When you have multiple pools on a system, as we do in our fileserver environment, it adds up fast.

There are various operational reasons why you might not want to upgrade pools right away. Historically we didn't want to upgrade pools until we were certain we were staying on the new OS and ZFS version, and then once we confident we were staying we weren't certain about the impact on our NFS servers. In theory pool upgrades should be transparent; in practice, who knows.

(Right now all of our fileserver pools are up to date in some sense, because they were freshly created on our current fileservers. But the ZFS version the fileservers are running is out of date, and when we upgrade them next year we'll run into this.)

Fortunately OpenZFS 2.1.0 provides a feature that lets you shut this up, in the form of OpenZFS's support for partial upgrades. If you set the new 'compatibility' property to what you already have, 'zpool status' won't nag you (although 'zpool upgrade -v' will show you what you're missing).