forced use of systemd-networkd interferes with ifupdown in 18.04

[Wes]

For several reasons, we are not able to use netplan nor systemd-networkd due to legacy applications that expect ifupdown's pre-up and post-up script mechanism. The documentation around 18.04's (premature, I feel) wholesale adoption of netplan claims that one can revert to old behaviour by merely installing ifupdown (amongst assertions that netplan will never offer a mechanism for configuring pre-up and post-up actions even for network managers that support them).

However when ifupdown is installed, systemd-networkd still tries to manage interfaces. If you 'systemctl disable systemd-networkd', upon next reboot it is automatically re-enabled. We tried disabling any systemd units even remotely related to networking and yet systemd-networkd still runs. If it hasn't been configured, it tries to DHCP. On networks that don't provide DHCP this results in a stupendously long stall during boot. Currently it appears to be impossible to tell systemd-networkd not to run in a clean manner that won't get reverted on package upgrades.

I sincerely hope this is is a bug/oversight and not intentional. We need to be able to disable systemd-networkd properly.

Thanks

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1771236/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Wes (wes234234)]

Well I think it pertains to ubuntu's architecture in general not just systemd but whatever.

[Dimitri John Ledkov (xnox)]

What is the legacy software in question?

Why does it have pre-up / post-up scripts and what do they do?

Can the functionality be replicated using networkd-dispatcher which is available out of the box on bionic? Specifically the routable.d/ off.d/ directories. See http://manpages.ubuntu.com/manpages/bionic/en/man8/networkd-dispatcher.8.html

[Dimitri John Ledkov (xnox)]

Please note, that networkd most likely is triggered by netplan configuration. If you do not wish an interface to be managed by netplan, please check netplan configs in /etc/netplan/

[Wes (wes234234)]

There are plenty of examples, some of them bespoke 3rd party things. An equally large issue though are legacy technicians who aren't familiar with systemd's way of doing things yet (I've been trying to get them up to speed though).

But the crux is if returning to ifupdown is offered as an option, then it needs to work as expected. If there's more to reverting to the old way than merely 'apt install ifupdown' then the documentation and config file comments referring to this needs to be updated to outline these steps. If a sysadmin disables systemd-networkd, it should stay disabled.

[Dimitri John Ledkov (xnox)]

@wes234234

A simple "apt install ifupdown" will not undo everything that installer has done to setup the system, nor redo it for the alternative networking management tool. Where do you expect ifupdown configs to materialize from? And how do you expect the netplan configs be removed? Given that the system is sensitive to all configs present on disk. This is similar situation to how on the desktop one cannot simply "remove network-manager & install ifupdown" to switch to ifupdown.

"there are plenty of examples" -> can you please give the examples that you have experienced, specifically? the ubuntu developers have gone extensive amount of porting, and integration testing to ensure that as many things as possible are fixed to work, both on new installs and upgrades.

I really want to know what is still broken and still needs fixing.

[Dimitri John Ledkov (xnox)]

Please provide the contents of /etc/netplan on the affected systems, and please let me know, if removing files in said directory makes networkd ignore interfaces.

Please provide output of $ networkctl

By default, if there is no netplan configuration, networkd does not "force use of systemd-networkd" and "does not interferes with ifupdown". Thus specifics about your system are required to describe the bug in detail and/or eventually fix Ubuntu or specific systems in question.

[Wes (wes234234)]

> A simple "apt install ifupdown" will not undo everything that installer has done to setup the system, nor redo it for the alternative networking management tool. Where do you expect ifupdown configs to materialize from?

Well that's kind of my point - your documentation is deficient around that. And we expect the ifupdown configuration to 'materialize' from the sysadmin writing them, that's the point of ifupdown isn't it? I'd wager that anyone reverting to ifupdown is doing so specifically because they don't want something managing configuration for them - they want to do it themselves.

> Given that the system is sensitive to all configs present on disk. This is similar situation to how on the desktop one cannot simply "remove network-manager & install ifupdown" to switch to ifupdown.

That's why we tried disabling systemd-networkd, which came back as enabled on subsequent boots. Apparently netplan adds some hooks that aren't clearly documented (at least when I looked on netplan.io, maybe I missed them?). I guess netplan needs to be actively purged, but that breaks the dep on it in ubuntu-minimal which may not be desirable to purge if its dep list changes in the future and people want to pull in those deps (apart from netplan).

> can you please give the examples that you have experienced, specifically? the ubuntu developers have gone extensive amount of porting, and integration testing to ensure that as many things as possible are fixed to work, both on new installs and upgrades.

We run gateways and firewalls with multiple providers and so forth. The need for pre-up, and more importantly post-up, comes up frequently in all sorts of situations. 'We need to (re)start openvpn after this vlan interface is configured, but both need to happen only after this pppoe interface is (re)configured' (yeah some of our ISPs still use ppp.. even on fibre links. it's terrible). This is why systemd-networkd implements such a facility, and why ifupdown does too. I feel it's near-sighted of netplan to pretend the need doesn't exist when the things it's configuring do see the need and do implement such facilities. If Ubuntu devs tested netplan extensively' I'd wager they never tested beyond basic use cases otherwise the deficiency would have been obvious. There are other, complex configurations out in the wild and netplan can't even begin to accommodate them in its current form. Which is fine... we remove it. But removing it appears to be problematic, or not permanent. So what's the correct method? Remove the initial config the installer makes? Does that let systemd-networkd remain disabled or does it get re-enabled anyway? Can you put this somewhere in the documentation and /etc/network/interfaces comments beyond the mere 'apt install ifupdown' that is there currently? As a side note we found an issue yesterday where DHCP via systemd-networkd in 18.04 wasn't working against an isc-dhcpd running on an early ubuntu version. The apparent inability to prevent systemd-networkd from trying to run and conflicting with other mechanisms was causing enough grief for my employer to decide to just give 18.04 a miss entirely. :( I could have put ...

[Brandon Applegate (vom)]

Looking for an update on this - specifically the seemingly unanswered question of "does removing all netplan related config render systemd-netword 'toothless'". I too am very concerned that simply installing ifupdown doesn't by itself achieve the result that seems to be put forth by the various pieces of documentation and advice around these issues.

I'm currently fighting vmware guest customizations on 18.04 (a whole other rabbit hole...) - but my current solution is in jeopardy if systemd-networkd is "touching" interfaces before I can get ansible to do it's thing. I'm currently testing and troubleshooting this.

[Brandon Applegate (vom)]

So from the troubleshooting and testing I just did, it seems like (at least) I had to do the following:

# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}

and

mv /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.disabled

Before taking these two steps, I kept getting a DHCP address on my interface. After doing this and rebooting, I finally have an interface that is simply "UP" - as configured in my /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto ens160
iface ens160 inet manual

[Brandon Applegate (vom)]

Sigh.

After I push my /etc/network/interfaces from ansible (not the stub one I previously posted) - "something" is re-reading it and applying settings. This never happened in 16.04 until an ifup/ifdown, service restart or reboot (which is what I expect and need). Not quite sure how to find the culprit. But this is breaking my ansible flow in the middle of the playbook as I lose the network config that Vmware put in.

[Launchpad Janitor (janitor)]

[Expired for systemd (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for ifupdown (Ubuntu) because there has been no activity for 60 days.]

[Wes (wes234234)]

Sigh indeed. The ignoring of this bug report (and many other bad, bad decisions for that matter) has now lead us to just abandon Ubuntu entirely. Even for non-server desktop use cases. I have no idea if the original reported issue has ever actually been dealt with, and I guess I never will.