Ubuntu 18.04: switch back to /etc/network/interfaces

Question

Starting sometime around Ubuntu 18.04, the Ubuntu devs stopped using the classic /etc/init.d/networking and /etc/network/interfaces method of configuring the network and switched to some thing called netplan. This has made a lot of people very angry and been widely regarded as a bad move. Is it possible to remove netplan and use the correct /etc/network/interfaces method for configuring the network?

Solution 1

The following procedure works for Ubuntu 18.04 (Bionic Beaver)

I. Reinstall the ifupdown package:

# apt-get update
# apt-get install ifupdown

II. Configure your /etc/network/interfaces file with configuration stanzas such as:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug enp0s3
auto enp0s3
iface enp0s3 inet static
  address 192.168.1.133
  netmask 255.255.255.0
  broadcast 192.168.1.255
  gateway 192.168.1.1
  # Only relevant if you make use of RESOLVCONF(8)
  # or similar...
  dns-nameservers 1.1.1.1 1.0.0.1

III. Make the configuration effective (no reboot needed):

# ifdown --force enp0s3 lo && ifup -a
# systemctl unmask networking
# systemctl enable networking
# systemctl restart networking

IV. Disable and remove the unwanted services:

# systemctl stop systemd-networkd.socket systemd-networkd \
networkd-dispatcher systemd-networkd-wait-online
# systemctl disable systemd-networkd.socket systemd-networkd \
networkd-dispatcher systemd-networkd-wait-online
# systemctl mask systemd-networkd.socket systemd-networkd \
networkd-dispatcher systemd-networkd-wait-online
# apt-get --assume-yes purge nplan netplan.io

Then, you're done.

Note: You MUST, of course, adapt the values according to your system (network, interface name...).

V. DNS Resolver

Because Ubuntu Bionic Beaver (18.04) make use of the DNS stub resolver as provided by SYSTEMD-RESOLVED.SERVICE(8), you SHOULD also add the DNS to contact into the /etc/systemd/resolved.conf file. For instance:

....
DNS=1.1.1.1 1.0.0.1
....

and then restart the systemd-resolved service once done:

# systemctl restart systemd-resolved

The DNS entries in the ifupdown INTERFACES(5) file, as shown above, are only relevant if you make use of RESOLVCONF(8) or similar.

Solution 2

The Netplan team has posted an official answer on their FAQ here:

How to go back to ifupdown

...

On a running system, netplan can be removed by installing ifupdown and configuring /etc/network/interfaces manually as users have done before.

At install time, a user can opt to use ifupdown by preseeding netcfg/do_not_use_netplan=true. This is done by adding the preseed line to the command line when booting the installation media (i.e. at install media boot menu, press F6, type ‘e’, and add to the command line).

See Nuxwin's answer for more complete instructions.

Solution 3

The answer of Nuxwin is great and almost complete, I'd just add the lines:

rm /etc/resolv.conf
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

This will make sure that the resolver can be updated by the DHCP-client, like it was before when using interfaces.

(I would have added this as a comment but somehow one need 50 reputation to post a comment)

Solution 4

Why not just configure with netplan?

Well, as it is configured in 18.04-Desktop, it is a single line handing over control to all interfaces to NetworkManager.

While that is probably suitable for 95% of users, remember that NetworkManager is only run once you are logged in to a session.

Should you want your machine to act as a server/desktop, for example start serving files to local machines, acting as VNP server, etc... or anything "fancy" before anyone is ever logged in, just by the simple fact it is on, you will have trouble with how it is configured in standard 18.04-Desktop.

Of course, the alternative would be to use the server-Netplan configuration, which, as far as I have read (not checked by myself), hands control over to systemd-networkd instead. In this case you'd better learn how systemd does things as a replacement of the old System V init.

Should you go this path, you still have to make change to the netplan yaml, since on a desktop version the control is given to NetworkManager.

Solution 5

Why not just remove netplan:

$ sudo apt remove netplan
$ rm -rf /etc/netplan

Once for all!

View more solutions

Comments

[chili555]

Why not just configure with netplan? In most situations, it is pretty straightforward.

[jdgregson]

@chili555 It may be that I just have to accept the change and learn something new. I'd just like to know if it is trivial to revert back to the way it should be. Much like systemd, I understand that disruptive change can sometimes be beneficial and be embraced. However, this is certainly not one of those times when the change was needed or beneficial.

[chili555]

It is not trivial and not easily reversible in case of error. If you'd like to live dangerously, I'll be happy to propose an answer. On the other hand, we can configure netplan in a couple of minutes. Which do you prefer? PS- I don't pretend to fully understand how netplan, to the exclusion of /etc/network/interfaces, fits in to the larger systemd picture. All I can do is trust that those who introduced the change do know why it's a better fit.

[jdgregson]

@chili555 This question is more or less academic, and certainly not something I would recommend anyone do in production. But it may serve to encourage offended users such as myself to begrudgingly accept that netplan is the correct way to configure networking in Ubuntu now, so by all means, suggest anything that comes to mind if you feel like exploring the question.

[jdgregson]

Some workarounds I have thought of are: 1) place a script in /etc/init.d/networking which just calls netplan apply. 2) Write a script which converts the contents of /etc/network/interfaces into YAML-style netplan syntax and adds it to the netplan config.

[chili555]

Or, just properly configure netplan and be done.

[JanC]

I think netplan was mainly designed to make it easier to configure & initialize cloud instances, because the format of /etc/network/interfaces isn't standardised, which makes it hard to edit/change it with a script. So that and similar purposes (like central configuration tools) would be the benefit.

[JanC]

BTW: /etc/network/interfaces not being standardized is also why a conversion script would never work for everyone (although it could probably handle the most common cases).

[Spongman]

netplan is not fit for purpose

[oᴉɹǝɥɔ]

Your use of Hitchhiker's quote on the occasion is perfect.

[jdgregson]

@oᴉɹǝɥɔ Yeah, once I got it in my head I couldn't help but model the whole question around that quote.

[user3751385]

@chili555 Netplan doesn't support virtual network interfaces. See here: askubuntu.com/questions/990825/virtual-interface-in-netplan

[axblount]

@chili555 Netplan doesn't support additional IPv6 addresses with preferred_lft=0. (There's an open and stale bug for that.) Netplan is just a step backwards, missing several required features. They should have switched to it when it's ready. As of today, it's not.

[deltamind106]

All these comments about "just properly configure netplan and be done" crack me up. I mean we have several thousand lines of code written that manually reads/writes the network configuration files, and this enables the users of our embedded device to reconfigure the network from a character LCD and 4 arrow buttons, Now I have to rewrite all that code to deal with some new YAML format file? No thanks.

[DevOpsSauce]

@chili555 Have a server that has 6 IP addresses. The new server has a bonded interface for failover, and I do not know how to give it multiple IP addresses. I'm reverting back to the old school way because I'm finding nothing in the actual documentation on how to implement this. I actually like Netplan, too. :-(

[chili555]

@IRGeekSauce Is this helpful? cat /usr/share/doc/netplan/examples/static_multiaddress.yaml

[DevOpsSauce]

Sort of. Doesn't have bonded interfaces, though.

[Hasan]

@chili555 netplan on my servers loses the IP address once the interface goes down for any reason. I have to login via console and do 'netplan apply' to access it again. I really hate it

[chili555]

@Hasan Please start your own new question and include your netplan file.

[David Jashi]

"This has made a lot of people very angry and been widely regarded as a bad move." - hats off for a very suitable quote.

[jdgregson]

I'll have to try that and see how it goes. The only other question would be how to apply the changes without rebooting. In the past you could use ifup/ifdown, /etc/init.d/networking restart, service networking restart, and the systemd methods, like systemctl restart networking, systemctl restart Network-Manager.service etc, but none of these were possible for me after installing Ubuntu 18.04.

[chili555]

What is the result of: sudo ip link set eth0 down followed by: sudo ifup -v eth0 Of course, substitute your interface for the mythical eth0.

[jdgregson]

ifupdown is not installed by default, so when you call ifup it just tells you how to install it. However, sudo ip link set eth0 down followed by sudo ip link set eth0 up does turn the interface off and back on.

[chili555]

Awesome! So you are solved and all set?

[JanC]

Careful, not all *.yaml files are related to netplan, so only remove those in netplan-related directories!

[jdgregson]

I can't get this to work. I've configured /etc/network/interfaces as I normally would and removed the only file in /etc/netplan. The only netplan-related .yaml files are in an "examples" directory. If I reboot, eth0 is down. When I bring it up using the ip link set method I get an IPv6 address, bit the IPv4 address I set in /etc/network/interfaces doesn't apply and I am left with IPv6 only.

[chili555]

May we please proofread your files: /etc/network/interfaces and also: ip addr show

[jdgregson]

The things you requested can be found here.

[jdgregson]

I read the comments in the /etc/network/interfaces file and noticed the To re-enable ifupdown on this system bit and did the follwing: 1) replaced the yaml file and rebooted, getting a DHCP address 2) installed ifupdown and restarted 3) checked my IP and I still had the DHCP address 4) ran ifdown eth0 and ifup eth0 and then had the static address as configured in /etc/network/interfaces 5) rebooted again and still had the static address.

[jdgregson]

I'll test again with a fresh install later, but it looks like installing ifupdown is all you have to do to get /etc/network/interfaces working again.

[Velkan]

Well, f*** them. Just apt-get install when you've got no network configuration. What a brilliant idea, Canonical.

[Laurent DECLERCQ a.k.a Nuxwin]

@Velkan You can always pre-configure your network with netplan then switch back to ifupdown later on ;) But I agreed with you. Somehow canonical take bad decisions. For instance, they break softwares that rely on ifupdown for networking configuration (no provider for netplan). This is the case for our control panel software (stable serie) where we do not want add new network configuration provider...

[Kamilion]

At least one reason exists: Netplan does not support openvswitch.

[Stephen Boston]

@Nuxwin People who want a conservative system evolution will probably find Debian stable more to their liking. It is very like Ubuntu except that it moves more slowly - though processes a bit faster. I like Ubuntu because it does change and exposes me to new ideas, but I'm not running a production server or a system subject to any deadlines at all.

[Laurent DECLERCQ a.k.a Nuxwin]

@StephenBoston I totally agree with you. However, even if Canonical try to go ahead by introducing new technology, it could do this in less invasive manner. I mean, the choice should be left to end user. For workstations, the change from ifupdown to netplan is surely not a big deal but when you have to deal with Ubuntu servers, that's another story because most stable softwares doesn't necesserely provide adapters... That has been the same story for systemd. I've to deal with both Debian and Ubuntu everydays. The problem with Ubuntu is that they don't care much about backward compatibility.

[Laurent DECLERCQ a.k.a Nuxwin]

The question here is how to switch back to ifupdown ;) In future, you should try to answer the questions without polluting them, even through it is not always easy to stick to initial subject ;)

[Laurent DECLERCQ a.k.a Nuxwin]

@Uqbar Why you say that my solution don't get rid of netplan exactly? Did you read it correctly? Netplan is purged with my solution. That is enough. You shouldn't remove remaining files from /etc/netplan directory manually if any because those can come from other package than netplan itself. Anyway, both solution are almost identical except that you make use of the networking service while I'm doing the job manually using ifupdown ;)

[Ollie Harridge]

@Nuxwin you leave behind those directories that belong to netplan and don't get purged (read the messages coming from the purge process). If I ask to get rid of netplan, I mean all of it. And, as the topic is about a server, I would expect to use higher level tools. But maybe this could be more about "religion" or "taste".

[Laurent DECLERCQ a.k.a Nuxwin]

@Uqbar As an administrator, you should be able to play with low level tools such as ifudown without the need to invoke the networking service which can break. Regarding remaining conffiles (APT warning), you're wrong. Some of remaining files could have been installed by other packages than netplan.io package. That is same scenario for systemd where several packages install systemd units, sysvinit scripts and upstart jobs even if those are not being used. By removing them, you could have issues in future if you want switch back to netplan... Purging the netplan.io package is sufficient.

[Ollie Harridge]

@Nuxwin Sure. But the question isn't from an expert person. And you could till use iptables2 instead of ifupdown. Nope, as system administrator I use high level stuff all the times. I go to lower level stuff only when really needed. Which isn't our case. Is it?

[Laurent DECLERCQ a.k.a Nuxwin]

@Uqbar If I've prefered ifdown (with the --force option) over the networking service that's not for nothing ;) Updating the network configuration by invoking the networking service is a bad idea in that specific scenario (switching from netplan to ifupdown).

[Hamid Fadishei]

netplan does not support IP aliases (eth0:0 style). I can't believe how such thing could find its way into Ubuntu server!

[OttoEisen]

Also, if you use dns-domain and dns-searchin the interfaces file, you should configure the Domains parameter in resolved.conf, I think? Anyway, great job putting that all together here, probably saved me a lot of time :)

[Laurent DECLERCQ a.k.a Nuxwin]

@OttoEisen Of course. I've not added notes regarding these parameters as the purpose was primarily to switch back to ifupdown. Resolver configuration is another topic.

[dsgdfg]

Because my netplan directories is empty !

[Laurent DECLERCQ a.k.a Nuxwin]

@Terrance Most of time, administrators will do a "sudo -s" before. Thus they will be already logged-as root. Regarding the /etc/resolv.conf it should be already a link to /run/systemd/resolve/resolv.conf by default.

[Laurent DECLERCQ a.k.a Nuxwin]

@Terrance First you should considere to talk other way. I'm not your boy friend. Anyway, if you make use of the DNS stub resolver as provided by SYSTEMD-RESOLVED.SERVICE(8), and if you configure it correctly (as shown in my answer), the /etc/resolv/resolve.conf file is expected to be a link to /run/systemd/resolv/stub-resolv.conf. Finally regarding the sudo wrapper on each command, that your choice and I'll not update my answer just for you. If you want do some copy-pasta by closing eyes, that necessarily mean you're not really an administrator.

[Laurent DECLERCQ a.k.a Nuxwin]

@Terrance this doesn't break anything as long as you configure your network correctly. The subject here is how to switch back to ifupdown. This is not a full howto about how configure your network stack. Regarding the 'boy friend', this is just a way to say please calm down. I 've been a bit irritated by your "Please don't put blanketed statements." sentence which for me, look like an order. But that's ok.

[Terrance]

I have removed all my comments. I am not going any further on this. I am indeed sorry for my actions. Your answer is a good answer, so stick with it. =)

[Oleg Neumyvakin]

@Nuxwin man for resolved.conf said that 'DNS=' is "A space-separated list"

[thaller]

NetworkManager service starts pretty early and does not require a session or a logged-in user.

[Christoph]

Do I understand correctly that the DNS entries in /etc/systemd/resolved.conf are not required if I have a dhcp config in my /etc/network/interfaces? (I didn't quite understand the part about the DNS resolver.)

[Steve Valliere]

This appears to be ignored by the 18.04.4 installer. I tried putting this option both before and after the --- that ends the command line initially presented (on separate attempts, of course) and always end up with netplan. I may need to try installed 16.04 and doing a dist upgrade just to get what I want.

[jdgregson]

Upvoting to get you to 50 rep.

[ChrisTG74]

@Nmath, thanks for the hints, I've edited my post.

[Denis Denisov]

Because netplan is not ready for production, with the slightest network problems the server will go into an endless load.

[rustyx]

Netplan does not support setting wifi regulatory domain (country), or pretty much any other wpa_supplicant.conf entry other than ssid and pwd, but it does rewrite it every time.

[jdgregson]

Assuming you've never successfully connected the server to the network before to install alternate methods of configuring the network, does this leave you completely unable to configure networking? It is there a built in fallback method?