DomainKey-Signature: a=rsa-sha1; c=nofws; d=soeren-tempel.net; h=date:to
	:subject:from:references:in-reply-to:message-id:mime-version
	:content-type:content-transfer-encoding; q=dns; s=opensmtpd; b=k
	AKaFxTbE6aGtUOt5ucPR5P/dyB8vtWBsJRFyMMslS7u3csQJTnLwaLeHvUPNokn5
	HV1r/eyYVs4YcxeHQfasFqfQme7bZNdJ0uuWtBHHPx7f6z34ydHYlfqEQr6uaYlK
	Zd34cmZ8LuuIOunN5bP92AayhZ4hYRqWRo3lnnbPok=
Date: Wed, 29 Jul 2020 20:22:14 +0200
To: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Proposed system change: ifupdown-ng as default network device
 manager
From: =?UTF-8?Q?S=C3=B6ren?= Tempel <soeren@soeren-tempel.net>
References: <12372156.q0HFhEdf7Z@localhost>
In-Reply-To: <12372156.q0HFhEdf7Z@localhost>
Message-Id: <29XAQ6FWKOTC3.2UUE0ZYOEL8M7@8pit.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=20
> situations, ifupdown is quite limited, such as in dual-stack scenarios an=
d=20
> complex configurations where virtual devices depend on parent devices to =
be=20
> 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 (=E2=80=9Ctries to do the job=
 of
shell script in C=E2=80=9C) [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=20=

> leveraging ifquery(8).  Right now this is achieved by attempting to parse=
 the=20
> /e/n/i file with awk.  Instead, we can change networking initscript to br=
ing=20
> 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 configuratio=
n,=20
> openrc integration, etc. Early adoption of ifupdown-ng as default network=
=20
> 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 =E2=80=9Copenrc integration=E2=80=9D 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=20
> 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 fr=
eeze,=20
> but allowing users enough time to test and validate ifupdown-ng with thei=
r=20
> 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=C3=B6ren

[1]: https://git.busybox.net/busybox/tree/docs/ifupdown_design.txt