[arch-projects] [netctl][HEADSUP] systemd-networkd

[Tom Gundersen]

Hi Jouke,

On Sun, Dec 1, 2013 at 4:06 PM, Jouke Witteveen <j.witteveen at gmail.com> wrote:
> On Thu, Nov 28, 2013 at 8:38 PM, Tom Gundersen <teg at jklm.no> wrote:
>> I wrote a bit about the background/status on G+:
>> https://plus.google.com/+TomGundersen/posts/bDQCP5ZyQ3h (there are a
>> few more posts with more details). If any of you have any feedback, or
>> would like to contribute, let me know.
>
> This work is certainly relevant to netctl. I even think you somewhat
> misrepresented netctl in you announcements, as netctl ticks quite a
> few of your boxes:

Sorry about that. That was not my intention. I guess that most of the
other networking solutions do in fact tick most of the boxes (but I'd
claim that none of them tick them all).

> it is rather minimal, it has an easy to use
> plain-text configuration format, and on top of that it harnesses as
> much of the power of systemd as possible (netctl even mimics the
> syntax of systemctl for completely intuitive usage). More or less the
> only difference between networkd and netctl is that networkd targets
> static configurations, while netctl targets dynamic configurations
> (profiles).

That's all correct, but there is also one additional point: we want an
implementation that can integrate all the state machines we will
eventually have (i.e., the rtnetlink one, together with the various
protocols such as DHCPv4, DHCPv6, DNAv4, IPv4LL) into one. So calling
out to external tools the way netctl does is something we'd like to
avoid.

> I do think netctl can benefit from networkd. There are a few things
> I'd like to get a response on.

I hope so!

> This list might not be the right place
> for them, so maybe I repost these things to the systemd list soon.
>
> The first thing I would like a response on is actually a statement. I
> would like to know how far off it is. As I see it, networkd implements
> the functionality of the ip utility of iproute2 inside systemd and
> adds a dhcp client to it.

Yes, that is correct. Both networkd and iproute2 are implemented on
top of the kernels rtnetlink interface, so (at least in principle)
they could expose the same functionality. We intend to add much more
to it though, in particular various the various DHCP-like protocols
listed above. We will probably see even more as time goes by.

> Next are a couple of questions, where I will pretend the above
> statement holds some truth. The questions are basically just one
> question asked a couple of times.
>
> Will the functionality that networkd shares with ip (link and address
> management) be exposed by a script-friendly (non-dbus) command?

It will certainly be exposed on dbus, and then we will have
networkctl, which will expose what makes sense (maybe everything?) to
scripts.

> Will the dhcp server be exposed?

We will have to get back to the details of exactly how these things
are exposed, but I expect static ip's and dhcp will be exposed in the
same way. The way I expect it to work is that a client would have to
atomically feed in (the equivalent of) a .network file to networkd and
tell it to apply it to a certain link, and let networkd sort out the
order in which to do things, what events to wait for etc.

> Will beat detection be exposed, for instance by starting/stopping a
> systemd service when a cable is plugged/unplugged?

It will certainly be exposed over dbus, and it will probably be a way
to query the state via networkctl, I doubt networkd itself will
directly start/stop systemd units based on link detection, but that's
obviously something a third-party daemon could implement on top of the
dbus interface.

> If the answer to the last question is yes, this would finally make
> ifplugd a thing of the past.

Hopefully its author will not be too upset ;-)

Cheers,

Tom