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
On Tue, 28 Jul 2020 09:36:13 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:
> Hello,
Hi,
> > 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.
...
This is awesome!
> 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,
This is where I am sold.
> 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.
What are the current limitations?
> ## 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.
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.> > * If ifupdown is dropped from BusyBox, the difference in install size > requirement is only 8KB.
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
> > Ariadne>
Ariadne Conill <ariadne@dereferenced.org> wrote:
> Hello,
Hi,
Just some initial thoughts below.
> 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.
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).
> 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.
Nice!
> * 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.
Sweet, the ifquery tool does sound very useful to me.
> * 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.
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 > requirement is only 8KB.
That sounds good, would be good to know though how much this changes
based on the added features outlined above.
> 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.
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
Hello,
On Wednesday, July 29, 2020 12:22:14 PM MDT Sören Tempel wrote:
> Ariadne Conill <ariadne@dereferenced.org> wrote:> > Hello,> > Hi,> > Just some initial thoughts below.> > > 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.> > 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].
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.
> 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).
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.
> > 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.> > Nice!> > > * 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.> > Sweet, the ifquery tool does sound very useful to me.> > > * 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.> > 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?
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.
> 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> > requirement is only 8KB.> > That sounds good, would be good to know though how much this changes> based on the added features outlined above.> > > 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.> > 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?
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
Hello,
On 2020-07-28 09:36, Ariadne Conill wrote:
[...]
> * If ifupdown is dropped from BusyBox, the difference in install size> requirement is only 8KB.
It is now up to 13KB, but you get a lot for that 20 KB.
> ## Testing> > ifupdown-ng is available in edge right now, in the testing repository. Simply> 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
Hello,
On 2020-08-20 05:16, Ariadne Conill wrote:
> Hello,> > On 2020-07-28 09:36, Ariadne Conill wrote:> [...]>> * If ifupdown is dropped from BusyBox, the difference in install size>> requirement is only 8KB.> > It is now up to 13KB, but you get a lot for that 20 KB.> >> ## Testing>>>> ifupdown-ng is available in edge right now, in the testing >> repository. Simply>> 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.
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
On Thu, 20 Aug 2020 22:54:17 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:
> Hello,> > On 2020-08-20 05:16, Ariadne Conill wrote:> > Hello,> > > > On 2020-07-28 09:36, Ariadne Conill wrote:> > [...] > >> * If ifupdown is dropped from BusyBox, the difference in install size> >> requirement is only 8KB. > > > > It is now up to 13KB, but you get a lot for that 20 KB.> > > >> ## Testing> >>> >> ifupdown-ng is available in edge right now, in the testing > >> repository. Simply> >> 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. > > This has now been implemented with ifupdown-ng 0.8.0-r1, which adds an > 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.
> 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.
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?
> > Ariadne
Hello,
On 2020-08-21 11:01, Natanael Copa wrote:
> On Thu, 20 Aug 2020 22:54:17 -0600> Ariadne Conill <ariadne@dereferenced.org> wrote:> >> Hello,>>>> On 2020-08-20 05:16, Ariadne Conill wrote:>>> Hello,>>>>>> On 2020-07-28 09:36, Ariadne Conill wrote:>>> [...]>>>> * If ifupdown is dropped from BusyBox, the difference in install size>>>> requirement is only 8KB.>>>>>> It is now up to 13KB, but you get a lot for that 20 KB.>>> >>>> ## Testing>>>>>>>> ifupdown-ng is available in edge right now, in the testing>>>> repository. Simply>>>> 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.>>>> This has now been implemented with ifupdown-ng 0.8.0-r1, which adds an>> 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.
I have no objection to making it a direct dependency of openrc at
release time.
>> 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.> > 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?
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
On Fri, 21 Aug 2020 18:51:44 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:
> > Maybe we can solve it with dependencies and provides instead, with> > ifupdown-ng with the highest priority. > > I have no objection to making it a direct dependency of openrc at > release time.
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