Shared publicly  - 
Networking in +systemd - the immediate future

My last post for now about networkd:

Firstly, it became clear early on that we needed a dhcp library, and that none (that fit our needs) existed. Luckily, Patrik Flykt was already hard at work extracting connman's dhcp handling into a (actually several) librarie(s). He has already posted the patches for DHCPv4 to the mailinglist, and it all looks very promising. I expect that we'll merge this stuff shortly and then quickly integrate it with networkd. Maybe not for v209, but certainly for v210.

Another item high on my TODO list is to add some dbus introspection. At first, we'll probably just expose enough to implement something like "networkctl --wait-online", so that we can properly bring up, which will be appreciated by people using remote filesystems. We will also introduce an interface so other network daemons may queuery us to find out if we are currently in charge of a given network device (say "networkctl --managing-ifindex 2", and the equivalent over dbus). This is important in order to avoid a situation where we have set up a network connection used to mount say the rootfs, and someone else then decides to 'take over' the device, and possibly tear down the connection (say too early at shutdown). These sorts of things have been problematic in the past, and it is important for us to make it simple to avoid in the future. Implementing this will be relatively straight-forward, in large part thanks to the fancy new dbus library we now have, making these things a breeze.
Lennart Poettering's profile photoRaven Dark's profile photoTom Gundersen's profile photo
Hmm, can't we find a different way to indicate whether a device is already managed? For example, we coul do this via udev props, or even by taking a BSD file lock on the sysfs path of the netif or so (which would make things robust to dying daemons)?
+Lennart Poettering I can't see how to do it non-racey with udev props. As networkd will be dbus-activated, I don't see how a dying daemon will pose a problem (assuming it starts up again, and well, if it doesn't, all bets are off).
Hmm, then maybe a flag file in /run somewhere? I'd just prefer a simple synchronus way that in the best case is symmetric, so that other implementations could even tell systemd-networkd to stay away from an interface via the same method.

It sounds easier to make everybody just follow the same logic to take posession of a device than making everybody else a client to systemd-networkd, if you follow what i mean.
+Lennart Poettering So after sleeping on this, I don't think a fully symmetric solution can work. I assume that the problem is only going to be when two networking daemons "greedily" grab all the interfaces they see (and I'll ignore the case where the admin explicitly asks the various daemons to grab an interface, as I think it is reasonable that we expect the admin then not to ask two daemons to configure the same device). So in the case of daemons grabbing the interfaces when they see them, and then indicating to the system that they have done so (in order for others to back off), we'll obviously get a race when two daemons do this at the same time, and in principle it will be random between boots how and by whom an interface is configured.

Another option, which I discussed with Kay in the past, would be for some udev builtin to make the decision about who should manage a device and tag it accordingly. This could be configured by say the .link files. However, I don't see this as a very satisfying solution, as we'll basically have to teach some UI to read/write the .link files and and in some way expose to the user the choice between the network daemons for each device...

Or do you see some other way?
there's a thing called netctl in archlinux, have you ever heard of that?
Not sure if sarcastic or not, but yeah, I have heard of that :)
Not sarcastic at all. I love netctl, but I think it'll be better if it's not done using shell scripts. So I actually like your idea, just want to know if your networkd will have an interface resemble the netctl one.
+Raven Dark ok :-) (The reason I asked is that I'm an Arch developer and netctl is an Arch project, so I have been following it relatively closely). As to the interface, at first we rely purely on configuration files, but it seems inevitable that we will quite soon get a cli, probably 'networkctl' which can also be used to configure the network. The implementation will certainly be very different from netctl, but apart from that, not much is decided.
+Dan Luedtke so far the config files are pretty basic, but there is nothing stopping us from doing pretty much the same as 'ip', it is just a matter of picking the syntax and testing the functionality. Technically speaking both 'ip' and our config files map pretty directly to the kernels rtnetlink(7) interface, so at least in principle we could have a one-to-one coverage (then we have to decide what makes sense of course).
I'm curious why you choose to implement dhcp support in networkd. what's wrong with spawning something like dhcpcd? I'm not criticizing or anything, I'm just curious about the drive behind this design choice.
Also will networkd ever support setting up wireless networks? If not, why?
+Raven Dark we want more control over the dhcp client than the standalone ones allow. In particular so we can integrate it with the other state-machines we are managing (IPv4LL, DHCP6 etc).
We have no immediate plans for wireless networking. Personally I use wpa_supplicant to connect to wireless networks. networkd detects when a connection is made and sets up dhcp etc just fine.
Add a comment...