On Mon, 01 Aug 2016 at 12:48:26 +0200, Guus Sliepen wrote:
> Last time I looked at it, systemd-networkd required several
> configuration files just to bring up a single interface.
What were the others, beyond the .network file? This is live configuration
from my home server, which has two network interfaces and I didn't want
it to bring up the other:
# /etc/systemd/network/lan.network
[Match]
Path=pci-0000:03:00.0
[Network]
DHCP=yes
The simplest possible, for "be a DHCP client on all interfaces with
no match configured earlier than this in alphabetical order", is
something like this:
# /etc/systemd/network/zz_default_dhcp.network
[Match]
[Network]
DHCP=yes
I know systemd-networkd also reads *.link files, but they aren't necessary
in cases this simple. They might be needed for WLANs, but if you're dealing
with WLANs it's time to seriously consider NetworkManager (or possibly
ConnMan, but I'm not sure I'd recommend that as a default).
> I'd say a good starting point would be to try to switch the installer to
> configuring NetworkManager or systemd-networkd, instead of generating a
> /etc/network/interfaces file.
This seems reasonable. I think NM is a better choice than ifupdown for
roaming client devices (e.g. laptops), and systemd-networkd is a good
choice for "infrastructure" devices like servers and NAS boxes.
> How would it work on Hurd and kFreeBSD?
That's up to the people who want to support those non-default kernels,
and I don't think it's reasonable to expect the rest of the distribution
to do that work for them. One possible answer would be to write or adapt
an ifupdown-like tool that works on those kernels and can consume (a
sufficiently large subset of) systemd-networkd .network (and maybe .link)
syntax, and/or NetworkManager /etc/NetworkManager/system-connections/
syntax. If that tool also worked on Linux, as a non-default option for
people who want a non-default init or just don't like the default
tools, so much the better.
systemd-networkd syntax is better-documented and better-suited to a
mental model where you configure interfaces; NetworkManager syntax has
fewer files per network, and is better suited to a mental model where
you configure networks that you can roam to, and "the system" connects
whatever interfaces you have to the networks it can see.
I think this might be a good opportunity to get away from the anti-pattern
of defining a Debian-specific file format, which has a heavy risk of
<https://xkcd.com/927/>.
S
