Linux network-scripts being deprecated is a problem for my home PPPoE link

January 6, 2019

The other day, I ran ifdown on my home machine for the first time since I upgraded it to Fedora 29 and got an unpleasant surprise:

WARN : [ifdown] You are using 'ifdown' script provided by 'network-scripts', which are now deprecated.
WARN : [ifdown] 'network-scripts' will be removed from distribution in near future.
WARN : [ifdown] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well.

As they say, this is my unhappy face.

On both my work and my home machines, most of my network configuration is done through systemd's networkd. However, at home I also have a PPPoE DSL link. Systemd (still) doesn't handle PPPoE and I have no interest in using NetworkManager on my desktop machines, which means that currently my PPPoE link setup is still done through the good old fashioned Fedora /etc/sysconfig/network-scripts system. Since this now seems to be on a deprecation schedule of some sort (although who knows what 'near future' is here, for Fedora or in general), I'm going to need to find some sort of a replacement for my use of it.

In theory this shouldn't be too hard, because after all ifup and ifdown are just shell scripts, and for a DSL link it appears that most of what they do is delegate things to rp-pppoe's adsl-start script. In practice, these are gnarled and tangled shell scripts, with who knows what side effects and environment variable settings that adsl-start and things downstream of it are counting on, and I'm not looking forward to first reverse engineering all of the setup and then building an equivalent replacement system, just because people want to remove network-scripts.

For even more potential fun for me in the future, ifup and ifdown are provided both by the network-scripts package and by NetworkManager, with this managed by Fedora's alternatives system. I suspect that this means I won't even notice that network-scripts has been removed until my system's ifup and ifdown invocations start quietly running NetworkManager and things explode for reasons that I expect to boil down to 'because NetworkManager'.

(I don't have much optimism about NetworkManager's ability to cooperate with other parties or be modest about what it will do with your network setup; instead my impression is that NetworkManager expects to run all of your networking however it sees fit. So I expect it to try to read random bits of my very historical network-scripts configuration files, interpret them in various ways, and then probably cause my networking to explode. NetworkManager has an ifcfg-rh plugin for this, but I have no idea how well it works and it doesn't seem to support DSL PPPoE at all based on the documentation.)

PS: For what it's worth, removing the network-scripts package is not currently listed in the Fedora 30 accepted changes as far as I can see (see also).

Sidebar: How I currently have my PPPoE networking wired up

I have a system cron.d file that runs 'ifup ppp0' on boot (via a @reboot action), and then re-runs it every fifteen minutes if there's no default route, because sometimes it falls over. In a more proper systemd world, I guess I should write a service unit that runs it after my home machine's Ethernet is up and then perhaps try out a timer unit to handle the 'try again every fifteen minutes' thing.

(I normally strong prefer crontab entries over systemd timer units, but I would be interacting with other systemd units and with the overall systemd state here so timer units are probably better.)


Comments on this page:

From 78.58.206.110 at 2019-01-06 08:10:08:

If I were not already using NM, it really wouldn't be my first or second choice either; I'd make a .service for PPPoE. (Bad memories from trying to make ADSL work on a Fedora livecd ~13 years ago...)

But now I'm using it, and as long as you're not running your home machine with a full DFZ routing table (which would punch NM and networkd right in the performance), I don't expect "NM for PPPoE, something else for everything else" to be too much trouble.

Although I haven't used RH-style distros, I get the impression that NM is practically the primary reader/writer of ifcfg files nowadays, so its 'ifcfg-rh' plugin should be very compatible.

That said, the plugin is not mandatory anyway; you can edit NetworkManager.conf to make it use just the generic 'keyfile' plugin and stay away from your ifcfg configurations. In fact, maybe do it preemptively now so that ifup will fail fast instead of failing mysteriously.

The same NetworkManager.conf also lets you exclude most interfaces from being managed by NM at all, although recent versions have gotten much better with picking up existing interfaces anyway. (I also frequently use nmcli dev set eth0 managed no whenever I want to temporarily reclaim Ethernet for some local configuration.)

Written on 06 January 2019.
« Some things on ZFS's per-pool performance statistics
accept(2)'s problem of trying to return two different sorts of errors »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 6 01:25:09 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.