Moving on from net-tools

LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

Old habits die hard, even when support for the tools required by those habits ended over a decade ago. It is not surprising for users to cling to the tools they learned early in their careers, even when they are told that it is time to move on. A recent discussion on the Debian development list showed the sort of stress that this kind of inertia can put on a distribution and explored the options that distributors have to try to nudge their users toward more supportable solutions.

The package in question is net-tools, the home for many familiar network-configuration utilities. If you are accustomed to using commands like ifconfig , arp , netstat , or route to make network changes, you are a net-tools user. Many of these tools have a long pedigree, at least in spirit, having originally been written before the first Linux kernel. Anybody who has been administering Unix-like systems for any period of time will certainly have learned how to use the net-tools utilities to get things done.

The only problem is that net-tools is considered obsolete; indeed, it has been so considered since early this century. The modern replacement is iproute2, which is actively developed and, unlike net-tools, has support for all of the kernel networking stack's fancier features. In theory, we all should have transitioned over to iproute2 at least ten years ago.

In practice, many of us have not done that. Indeed, "us" in this case includes distributors who still use net-tools utilities in a number of packages. Surprisingly, the net-tools developers, who have not made a new release since 2011, have recently resumed working on those utilities; even more surprisingly, they made output changes, apparently breaking scripts that parse that output. These changes led Debian developer Marco d'Itri to call for the project to "kill" net-tools, and, in particular, to stop depending on it in other packages. He would also like to see the project stop installing net-tools by default.

The list of Debian packages depending on net-tools is not that short, but it would appear to be a manageable list if the project were to decide to fix all of those dependencies. The net-tools maintainer is not opposed to the idea of deprecating and eventually phasing out the package; indeed, he tried to do so in 2009. It seems to be generally agreed that the configuration scripts shipped with Debian packages should use iproute2 rather than net-tools to ensure that the examples seen by administrators are using the current tool set. So there would appear to be little controversy around the idea of phasing out net-tools usage and dropping the priority of the package for installations.

There is less consensus around removing the package entirely, or even just dropping it from the default install. There are, it seems, quite a few users who have ifconfig and netstat burned into their muscle memory; those tools work fine for most use cases, so users don't see a strong reason to shift to iproute2. As Ted Ts'o put it:

This is really going to be a generational thing. For those of us who started programming in the BSD 4.x days (my first kernel programming experience was with BSD 4.3), ifconfig and netstat are still the tools that I use every day, and I only use the iproute2 tools in the *extremely* rare circumstances that I need to do something exotic which is only supported by the iproute2 tools.

The fact that the iproute2 commands are seen as more verbose and, by some at least, as having less readable (and less machine-parseable) output doesn't help either. So it's not surprising that various participants expressed their preference for the net-tools utilities, but Russell Stuart suggested that it might be time to move on:

To me this thread looks like a bunch of old men grumbling that the young'ins have taken over what they created and turned the tools they were comfortable with into something unrecognisable. It's true - they did do that, and it's true it was unnecessary. They could have just extended net-tools. But this is how the young'ins have behaved for time immemorial - when they take over the reins from the previous generation and make it their own.

(It is worth noting that the "unnecessary" part is not universally accepted; it's not clear that net-tools could have been evolved to handle modern networking configuration without incompatible changes.)

Debian, as it happens, is having this discussion a bit late. OpenSUSE discussed removing net-tools in 2009, but has not done so. Red Hat and Fedora got serious in 2011, and the RHEL 7 release no longer installs net-tools by default. The fact that this change is not universally popular shows how reluctant users can be to let go of their long-used tools.

None of these distributors have removed the net-tools package, and none are likely to as long as supporting them is relatively easy and users depend on them. But, when they do break, or when they fail to support new networking features that users need, there is not likely to be a lot of interest in fixing them. Distributors have to choose where to expend their energy, and there will come a point where dragging along obsoleted tools that the old folks want falls off the list.

For now, users who are accustomed to typing commands like ifconfig are probably safe; at worst, they will need to install the net-tools package explicitly. But anybody who is using these commands in scripts should probably have updated those scripts some time ago. There will come a point where those scripts break; it seems that could even happen as a result of attempts to restart development on net-tools, rather than by explicit deprecation. This cheat sheet is likely to prove helpful for anybody wanting to make the transition to the new tools.

Software transitions like this are invariably an unwanted distraction for users who are uninterested in whatever new features are available and would prefer that their systems (and their habits) just continue to work. But the world we live in does not stand still, so such transitions are simply going to happen, and distributors will find themselves caught in the middle. As those distributors strive to keep everybody happy, we should not be surprised to see more of these transitions take a decade or more.

