73

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?

Pablo Bianchi
  • 15,657
jdgregson
  • 1,024
  • 1
  • 10
  • 16
  • 3
    Why not just configure with netplan? In most situations, it is pretty straightforward. – chili555 May 03 '18 at 20:00
  • 5
    @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. – jdgregson May 03 '18 at 20:06
  • 2
    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. – chili555 May 03 '18 at 20:25
  • @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 May 03 '18 at 20:54
  • 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. – jdgregson May 03 '18 at 20:58
  • 2
    Or, just properly configure netplan and be done. – chili555 May 03 '18 at 21:06
  • 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 May 03 '18 at 21:14
  • 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). – JanC May 03 '18 at 21:17
  • 1
    netplan is not fit for purpose – Spongman Aug 15 '18 at 18:58
  • 1
    Your use of Hitchhiker's quote on the occasion is perfect. – oᴉɹǝɥɔ Aug 24 '18 at 01:23
  • @oᴉɹǝɥɔ Yeah, once I got it in my head I couldn't help but model the whole question around that quote. – jdgregson Aug 25 '18 at 09:38
  • 2
    @chili555 Netplan doesn't support virtual network interfaces. See here: https://askubuntu.com/questions/990825/virtual-interface-in-netplan – user3751385 Jan 28 '19 at 08:12
  • @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. – ygoe Jul 01 '20 at 18:00
  • 1
    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. – deltamind106 Apr 06 '21 at 17:50
  • @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. :-( – DevOpsSauce Jun 25 '21 at 14:14
  • 1
    @IRGeekSauce Is this helpful? cat /usr/share/doc/netplan/examples/static_multiaddress.yaml – chili555 Jun 25 '21 at 16:01
  • Sort of. Doesn't have bonded interfaces, though. – DevOpsSauce Jun 25 '21 at 16:05
  • @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 – Hasan Jul 31 '21 at 09:05
  • @Hasan Please start your own new question and include your netplan file. – chili555 Jul 31 '21 at 13:59
  • 1
    "This has made a lot of people very angry and been widely regarded as a bad move." - hats off for a very suitable quote. – David Jashi Jan 15 '22 at 13:23
  • I've never used network-manager, never used netplan. I've never had any issues with any application. "Live dangerously" ? Nope, nothing dangerous about it, it's just some totally pointless middleware that literally doesn't need to be there, same with pulse-audio and resolved. This is a pernicious disease sweeping through linux and it does nothing for most people. – Owl May 19 '22 at 11:07

7 Answers7

69

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.

  • 23
    Well, f*** them. Just apt-get install when you've got no network configuration. What a brilliant idea, Canonical. – Velkan Aug 03 '18 at 06:47
  • 2
    @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... – Laurent DECLERCQ a.k.a Nuxwin Aug 05 '18 at 09:58
  • @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. – Stephen Boston Sep 01 '18 at 02:38
  • 5
    @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 Sep 01 '18 at 05:59
  • @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 ;) – Laurent DECLERCQ a.k.a Nuxwin Sep 12 '18 at 14:18
  • @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". – EnzoR Sep 12 '18 at 15:22
  • @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. – Laurent DECLERCQ a.k.a Nuxwin Sep 12 '18 at 15:47
  • @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? – EnzoR Sep 12 '18 at 15:50
  • @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). – Laurent DECLERCQ a.k.a Nuxwin Sep 12 '18 at 15:58
  • 1
    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 :) – OttoEisen Dec 16 '18 at 16:26
  • @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. – Laurent DECLERCQ a.k.a Nuxwin Dec 16 '18 at 16:48
  • @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 Feb 15 '19 at 14:45
  • @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 Feb 17 '19 at 20:32
  • @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. – Laurent DECLERCQ a.k.a Nuxwin Feb 18 '19 at 07:36
  • 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. =) – Terrance Feb 18 '19 at 16:00
  • 1
    @Nuxwin man for resolved.conf said that 'DNS=' is "A space-separated list" – Oleg Neumyvakin Mar 24 '19 at 07:40
  • 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.) – Christoph Mar 04 '20 at 23:41
  • For the resolved stuff, i literally just delete the symlink /etc/resolv.conf and then create an actual /etc/resolv.conf file instead. Thank you for helping me remove this awful disease that is happening to linux. – Owl May 19 '22 at 11:03
  • 1
    Note that in /etc/network/interfaces indenting lines is only for humans. It doesn't change the configuration one bit. However, with config files within /etc/netplan, all whitespace is meaningful because these files must be written in YAML syntax. That said, I still don't understand why anybody thinks using YAML for critical system configuration files would be a good idea... The only help you get for modifying config is netplan try which is known buggy! See man netplan-try for details. – Mikko Rantalainen Sep 16 '22 at 11:20
12

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.

jdgregson
  • 1,024
  • 1
  • 10
  • 16
  • 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. – Steve Valliere Mar 31 '20 at 10:19
10

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)

ChrisTG74
  • 301
3

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.

Zakhar
  • 369
  • 4
    At least one reason exists: Netplan does not support openvswitch. – Kamilion Aug 31 '18 at 18:07
  • 7
    netplan does not support IP aliases (eth0:0 style). I can't believe how such thing could find its way into Ubuntu server! – Hamid Fadishei Oct 11 '18 at 12:30
  • Because my netplan directories is empty ! – dsgdfg Jan 16 '19 at 12:47
  • 2
    NetworkManager service starts pretty early and does not require a session or a logged-in user. – thaller Oct 23 '19 at 21:04
  • Because netplan is not ready for production, with the slightest network problems the server will go into an endless load. – Denis Denisov Dec 08 '20 at 10:38
  • 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. – rustyx Dec 23 '20 at 14:45
2

The key is knowing that cloud.init is the real control program.
That being said the line in the netplan config file "optional: true" is mandatory.
Knowing that made it easy.

I just removed 01-network-manager-all.yaml and copied it to /root/save/. Then put a known good config in place instead of it, 50-cloud-init.yaml: its contents follow:

network:
  version: 2
  renderer: networkd
  ethernets:
    eports:
      match: 
        name: enp*
        optional: true
  bonds:
    bond0:
      interfaces: [eports]
      addresses: [192.168.2.5/24]
      gateway4: 192.168.2.1
      nameservers:
        addresses: [127.0.0.1, 8.8.4.4]          
      parameters:
        mode: 0          
        mii-monitor-interval: 100

Then reboot and it should be working fine.

The known good config came from Configure bonded 802.3ad network using netplan on Ubuntu 18.04.

David Foerster
  • 36,264
  • 56
  • 94
  • 147
pksings
  • 21
  • 2
    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 Sep 01 '18 at 06:09
2

Why not just remove netplan:

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

Once for all!

Robin Hsu
  • 123
  • 1
    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? – jdgregson May 02 '21 at 17:53
0

According to this answer, the solution is to remove all operational .yaml files: Ubuntu 17.10 disable netplan

I wouldn’t remove anything without backing up. We can do so easily by simply moving the files aside. First, locate the files:

sudo updatedb
locate netplan | grep yaml

On my 18.04 system, it appears that the only operational file is /etc/netplan/01-network-manager-all.yaml. Let’s move it:

mkdir ~/netplan
sudo mv /etc/netplan/01-network-manager-all.yaml  /home/user/netplan

...where user is your user name.

Now check to make sure the file is truly gone:

ls /etc/netplan

Now make your additions to /etc/network/interfaces as required.

Reboot.

Any improvement?

Footnote: The exact process to do this is hard to find. We may need to refine a bit as we go.

chili555
  • 60,188
  • 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. – jdgregson May 03 '18 at 22:05
  • 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. – chili555 May 03 '18 at 23:01
  • 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. – jdgregson May 03 '18 at 23:27
  • Awesome! So you are solved and all set? – chili555 May 03 '18 at 23:46
  • Careful, not all *.yaml files are related to netplan, so only remove those in netplan-related directories! – JanC May 05 '18 at 19:33
  • 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. – jdgregson May 06 '18 at 09:02
  • May we please proofread your files: /etc/network/interfaces and also: ip addr show – chili555 May 06 '18 at 13:14
  • The things you requested can be found here. – jdgregson May 07 '18 at 19:58
  • 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 May 07 '18 at 19:59
  • 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. – jdgregson May 07 '18 at 19:59