Subject: Proposed system change: ifupdown-ng as default network device manager

From: Ariadne Conill <[email-masked]>
Date: Tue, 28 Jul 2020 09:36:13 -0600

Hello,

At present, Alpine uses BusyBox ifupdown as default network device manager, 
and a few additional 'addon' packages which provide additional scripts that 
interact with ifupdown.

We additionally provide Debian ifupdown and, more recently, ifupdown-ng as 
alternatives.

This has gotten us very far over the past decade.  However, in many 
situations, ifupdown is quite limited, such as in dual-stack scenarios and 
complex configurations where virtual devices depend on parent devices to be 
brought up first.

## What is ifupdown-ng?

ifupdown-ng is a lightweight network device manager that is backwards 
compatible with Debian ifupdown and busybox ifupdown.  Unlike other 
implementations, it uses a dependency solver to determine the interface bring-
up and take-down order.  This allows for the user to significantly simplify 
their network configuration.

Finally, ifupdown-ng allows for an interface to have multiple addresses 
associated with it in a simple way.  For example, we can use the /e/n/i file 
from my main server:

   auto br0
   iface br0
        use bridge
        requires bond0
        address 172.93.5.34/28
        address 10.150.241.1/24
        gateway 172.93.5.33

   iface bond0
        use bond
        requires eth0 eth1
        bond-mode 802.3ad
        bond-xmit-hash-policy layer2+3

The equivalent in traditional ifupdown is almost twice as long, as every 
detail has to be explicitly spelled out, while ifupdown-ng can figure out the 
necessary details by using the dependency solver.

Another benefit to ifupdown-ng is the executor concept.  With the current addon 
scripts, they automatically run for every interface at bring-up and take-down.  
This means that a misconfiguration may result in the addon script doing 
something to an interface that was not intended.  By contrast, if you use 
ifupdown-ng's executors, they will only run when explicitly requested with a 
use statement.

ifupdown-ng is 100% backwards compatible with ifupdown, and can even 
automatically convert an /e/n/i file to use the new syntax with the new 
ifquery(8) utility, but that's optional.

## Benefits to Alpine

* The networking initscript can start interfaces more intelligently by 
leveraging ifquery(8).  Right now this is achieved by attempting to parse the 
/e/n/i file with awk.  Instead, we can change networking initscript to bring 
interfaces up in order according to the dependency tree.

* Configuration of IPv4+IPv6 dual-stack environment is simplified, as you can 
just specify a dual-stack configuration.  Right now to use dual-stack, you have 
to either use up/down statements or use Debian ifupdown which is still limited 
to configuring a single address.

* Future plans for ifupdown-ng include hotplug support, wifi configuration, 
openrc integration, etc.  Early adoption of ifupdown-ng as default network 
device manager allows for streamlined adoption of these later features.

* If ifupdown is dropped from BusyBox, the difference in install size 
requirement is only 8KB.

## Testing

ifupdown-ng is available in edge right now, in the testing repository.  Simply 
do `apk add ifupdown-ng`.

## Contingency Plan

If ifupdown-ng has release-critical problems, we will simply revert the change 
and continue using BusyBox ifupdown as default, with ifupdown-ng as an 
optional package and revisit this in a future release cycle.

## Timeline

I would like to flip the default sometime in September, before feature freeze, 
but allowing users enough time to test and validate ifupdown-ng with their 
setups.

Ariadne

---

From: Natanael Copa <[email-masked]>
Date: Tue, 28 Jul 2020 18:10:33 +0200

On Tue, 28 Jul 2020 09:36:13 -0600

> Hello,

Hi,

> compatible with Debian ifupdown and busybox ifupdown.
...

This is awesome!
 
> ifupdown-ng is 100% backwards compatible with ifupdown, 

This is where I am sold.

> and can even 

What are the current limitations?

> interfaces up in order according to the dependency tree.

This should solve https://gitlab.alpinelinux.org/alpine/aports/-/issues/11562

> * Configuration of IPv4+IPv6 dual-stack environment is simplified, as
> you can just specify a dual-stack configuration.  Right now to use
> dual-stack, you have to either use up/down statements or use Debian
> ifupdown which is still limited to configuring a single address.
> 
> * Future plans for ifupdown-ng include hotplug support, wifi
> configuration, openrc integration, etc.  Early adoption of
> ifupdown-ng as default network device manager allows for streamlined
> adoption of these later features.
> 

I assume the size would increase as new features are added, but I think
its worth it.
 
> ## Testing
> 
> ifupdown-ng is available in edge right now, in the testing
> repository.  Simply do `apk add ifupdown-ng`.
> 
> ## Contingency Plan
> 
> If ifupdown-ng has release-critical problems, we will simply revert
> the change and continue using BusyBox ifupdown as default, with
> ifupdown-ng as an optional package and revisit this in a future
> release cycle.

sounds good to me.

> 
> ## Timeline
> 
> I would like to flip the default sometime in September, before
> feature freeze, but allowing users enough time to test and validate
> ifupdown-ng with their setups.

sounds good.

Thank you for you work on this!

-nc

---

From: Sören Tempel <[email-masked]>
Date: Wed, 29 Jul 2020 20:22:14 +0200

Hi,

Just some initial thoughts below.

> complex configurations where virtual devices depend on parent devices to be 

I agree. Generally speaking, our networking setup could really be
improved. However, I am not entirely convinced yet that doing so based
on the general ifupdown design is a good idea. See also: Denys
Vlasenko's comments on the design of ifupdown (“tries to do the job of
shell script in C“) [1].

I think there is also an argument to be made that Busybox ifupdown is
good enough for simple situations (i.e. for the default Alpine setup).
For more advanced situation users could arguably still install network
management tools from aports (including ifupdown-ng).

> automatically convert an /e/n/i file to use the new syntax with the
> new ifquery(8) utility, but that's optional.

Nice!

> interfaces up in order according to the dependency tree.

Sweet, the ifquery tool does sound very useful to me.

> device manager allows for streamlined adoption of these later features.

Could you maybe elaborate on these planned features further. For
example, how is wifi configuration supposed to work? Generate a
wpa_supplicant configuration from /etc/network/interface? Also: What
does “openrc integration” entail?

If we want to include this in Alpine by default I would try to avoid
reinventing network manager. However, I think I do not fully understand
the scope of ifupdown-ng yet and how it relates to other tools in
regards to these planned features (e.g. wpa_supplicant).

> * If ifupdown is dropped from BusyBox, the difference in install size 

That sounds good, would be good to know though how much this changes
based on the added features outlined above.

> but allowing users enough time to test and validate ifupdown-ng with their 

Not sure what your current roadmap regarding ifupdown-ng itself is, but
September does sound early to me. Why not wait until ifupdown-ng itself
stabilized a bit (also in terms of feature set and resulting size
increase) and discuss inclusion by default for 3.14 then?

Also: Thanks for working on an improved network setup!

Greetings,
Sören

[1]: https://git.busybox.net/busybox/tree/docs/ifupdown_design.txt

---

From: Ariadne Conill <[email-masked]>
Date: Wed, 29 Jul 2020 14:28:06 -0600

Hello,

> Vlasenko's comments on the design of ifupdown (“tries to do the job of

ifupdown-ng is a much simpler design than ifupdown, actually.  At it's core, 
it is essentially a job scheduler that has dependency awareness.  All the 
lifting work is done by helper programs, which are shell scripts.

> management tools from aports (including ifupdown-ng).

Part of the motivation here is to reduce the scope of busybox, so that 
containers can have a smaller attack surface.  By replacing busybox components 
with modern, easily auditable replacements, we improve our security at a 
minimal cost.

> > leveraging ifquery(8).  Right now this is achieved by attempting to parse
> > the /e/n/i file with awk.  Instead, we can change networking initscript
> > to bring interfaces up in order according to the dependency tree.
> 
> > configuration,

These features would be addon packages that could be installed.  They would 
configure and manage services like wpa_supplicant.

OpenRC has hotplug services, so for example, this means we can postpone 
bringing up services that depend on networking until the network is actually 
up.  This could be done in the background, allowing for the user to get to 
shell faster.  A good example here is chrony, which takes upwards of a minute 
to time out when the network is not functioning.  So basically the integration 
is that OpenRC would be aware of ifupdown-ng's state.

Hotplug is about allowing ifupdown-ng to react to netlink events, in the same 
way that mdev and udev do.  For example if you plug in an ethernet cable or 
USB device, ifupdown-ng could automatically configure it in the background if 
you choose to run ifmond(8).  But hotplug/ifmond won't come for 3.13, even if 
it is implemented upstream.

> > I would like to flip the default sometime in September, before feature
> > freeze, but allowing users enough time to test and validate ifupdown-ng
> > with their setups.
> 

We are already using ifupdown-ng in production without any problems.  I 
consider it stable at this point.  This is easy to validate because ifupdown-
ng is a very simple design (like I said earlier, it is basically just a job 
scheduler, with the heavy lifting being done by the same scripts we are using 
now).

At this point, it is mostly about adding some additional conveniences to make 
life easier for Debian ifupdown users, those don't impact Alpine though.

The only other major thing I would like to get into 3.13 is ifreload(8), which 
will atomically synchronize the network state with the configured state, but 
that is not so urgent to me.

The key point is that 3.13 introduces the core part (the job scheduler), and 
we introduce the other features later, since everything is optional.

Ariadne

---

From: Ariadne Conill <[email-masked]>
Date: Thu, 20 Aug 2020 05:16:06 -0600

Hello,

On 2020-07-28 09:36, Ariadne Conill wrote:
[...]
> * If ifupdown is dropped from BusyBox, the difference in install size

It is now up to 13KB, but you get a lot for that 20 KB.

> do `apk add ifupdown-ng`.

While ifupdown-ng has transitioned to main, we have not yet flipped the 
switch.  It would be appreciated if more people test, but based on 
feedback of downstream customers, I believe we are ready to make the 
switch -- so I plan to do so this weekend.

Ariadne

---

From: Ariadne Conill <[email-masked]>
Date: Thu, 20 Aug 2020 22:54:17 -0600

Hello,

> switch -- so I plan to do so this weekend.

This has now been implemented with ifupdown-ng 0.8.0-r1, which adds an 
install_if on alpine-base.

If you do not want to use ifupdown-ng, you can get back to busybox 
ifupdown or debian ifupdown by using `apk add '!ifupdown-ng'`.

However, I intend to remove ifupdown from busybox after 3.13.

Ariadne

---

From: Natanael Copa <[email-masked]>
Date: Fri, 21 Aug 2020 19:01:51 +0200

On Thu, 20 Aug 2020 22:54:17 -0600

> install_if on alpine-base.

I'm not sure alpine-base is the thing to hook on. Probably better to
link it with openrc that provides /etc/init.d/networking, which is the
thing that actually uses it. Otherwise even docker images will get it
unless explicitly disabled.

Also, install_if should ideally be linked to a versioned package if
possible, otherwise nasty things may happen if there are multiple
versions of ifupdown-ng repos. They all will want be installed.

Maybe we can solve it with dependencies and provides instead, with
ifupdown-ng with the highest priority.

> However, I intend to remove ifupdown from busybox after 3.13.

I wonder if there are any good reasons to keep busybox ifupdown now.
What stops us from removing busybox ifupdown immediately and add
ifupdown-ng as direct dependency for openrc?

---

From: Ariadne Conill <[email-masked]>
Date: Fri, 21 Aug 2020 18:51:44 -0600

Hello,

> ifupdown-ng with the highest priority.

I have no objection to making it a direct dependency of openrc at 
release time.

> ifupdown-ng as direct dependency for openrc?

In theory, nothing.  In practice, like with any transition, somebody may 
be running a strange setup that ifupdown-ng does not yet support correctly.

So, I would like to spend a week or two verifying everything is fine 
before introducing a direct dependency.  At that time, we could drop it 
from busybox.

Ariadne

---

From: Natanael Copa <[email-masked]>
Date: Mon, 24 Aug 2020 09:55:36 +0200

On Fri, 21 Aug 2020 18:51:44 -0600

> I have no objection to making it a direct dependency of openrc at 

How about we do something like this. We make 3 different packages with
provides=ifupdown:

ifupdown-ng (highes provides_priority)
ifupdown-debian
ifupdown-none

then we let openrc depend=ifupdown. This way users would get
ifupdown-ng by default, but can be easily be swapped out by either
ifupdown-debian or ifupdown-none (which is to be installed for busybox
ifupdown).

-nc