From: Ariadne Conill <ariadne@dereferenced.org>
To: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Proposed system change: ifupdown-ng as default network device manager
Date: Wed, 29 Jul 2020 14:28:06 -0600
Message-ID: <2264354.Wqf08ja3cW@localhost>
In-Reply-To: <29XAQ6FWKOTC3.2UUE0ZYOEL8M7@8pit.net>
References: <12372156.q0HFhEdf7Z@localhost> <29XAQ6FWKOTC3.2UUE0ZYOEL8M7@8pit.net>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Hello,

On Wednesday, July 29, 2020 12:22:14 PM MDT S=C3=B6ren Tempel wrote:
> Ariadne Conill <ariadne@dereferenced.org> wrote:
> > Hello,
>=20
> Hi,
>=20
> Just some initial thoughts below.
>=20
> > 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.
>=20
> 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 (=E2=80=9Ctries to do the j=
ob of
> shell script in C=E2=80=9C) [1].

ifupdown-ng is a much simpler design than ifupdown, actually.  At it's core=
,=20
it is essentially a job scheduler that has dependency awareness.  All the=20
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=20
containers can have a smaller attack surface.  By replacing busybox compone=
nts=20
with modern, easily auditable replacements, we improve our security at a=20
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.
>=20
> Nice!
>=20
> > * The networking initscript can start interfaces more intelligently by
> > leveraging ifquery(8).  Right now this is achieved by attempting to par=
se
> > the /e/n/i file with awk.  Instead, we can change networking initscript
> > to bring interfaces up in order according to the dependency tree.
>=20
> Sweet, the ifquery tool does sound very useful to me.
>=20
> > * Future plans for ifupdown-ng include hotplug support, wifi
> > configuration,
> > openrc integration, etc. Early adoption of ifupdown-ng as default netwo=
rk
> > device manager allows for streamlined adoption of these later features.
>=20
> 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 =E2=80=9Copenrc integration=E2=80=9D entail?

These features would be addon packages that could be installed.  They would=
=20
configure and manage services like wpa_supplicant.

OpenRC has hotplug services, so for example, this means we can postpone=20
bringing up services that depend on networking until the network is actuall=
y=20
up.  This could be done in the background, allowing for the user to get to=
=20
shell faster.  A good example here is chrony, which takes upwards of a minu=
te=20
to time out when the network is not functioning.  So basically the integrat=
ion=20
is that OpenRC would be aware of ifupdown-ng's state.

Hotplug is about allowing ifupdown-ng to react to netlink events, in the sa=
me=20
way that mdev and udev do.  For example if you plug in an ethernet cable or=
=20
USB device, ifupdown-ng could automatically configure it in the background =
if=20
you choose to run ifmond(8).  But hotplug/ifmond won't come for 3.13, even =
if=20
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).
>=20
> > * If ifupdown is dropped from BusyBox, the difference in install size
> > requirement is only 8KB.
>=20
> That sounds good, would be good to know though how much this changes
> based on the added features outlined above.
>=20
> > 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.
>=20
> 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=20
consider it stable at this point.  This is easy to validate because ifupdow=
n-
ng is a very simple design (like I said earlier, it is basically just a job=
=20
scheduler, with the heavy lifting being done by the same scripts we are usi=
ng=20
now).

At this point, it is mostly about adding some additional conveniences to ma=
ke=20
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), wh=
ich=20
will atomically synchronize the network state with the configured state, bu=
t=20
that is not so urgent to me.

The key point is that 3.13 introduces the core part (the job scheduler), an=
d=20
we introduce the other features later, since everything is optional.

Ariadne