[systemd-devel] [RFC][PATCH] networkd: add a basic network daemon

[Marcel Holtmann]

Hi Auke,

>> This daemon listens for and configures network devices tagged with
>> 'systemd-networkd'. By default, no devices are tagged so this daemon
>> can safely run in parallel with existing network daemons/scripts.
>> 
>> Networks are configured in /etc/systemd/network/*.network. The first .network
>> file that matches a given link is applied. The matching logic is similar to
>> the one for .link files, but additionally supports matching on interface name.
>> 
>> The mid-term aim is to provide an alternative to ad-hoc scripts currently used
>> in initrd's and for wired setups that don't change much (e.g., as seen on
>> servers/and some embedded systems).
>> 
>> Currently, static addresses and a gateway can be configured, mostly as a proof
>> of concept. I expect to expand on this as soon as we are agreed on the basic
>> design.
>> 
>> Comments, testing and contributions greatly appreciated!
> 
> alright, I'll comment, but it took me 5 minutes to clear the coffee
> off my monitor...
> 
> Looking at the feature list, why are you not contributing to connman
> instead? It seems you're going to be duplicating a ton of code.... And
> connman does what your goal is, meaning you can pre-provision static
> configurations without any of the more involved dependencies. It has a
> DBus interface for status, configuration etc....
> 
> I'm frankly shocked a bit, not sure what to say. Maybe this is a great
> thing, but, without a doubt someone will want to convert this code
> long term into connman / NM, and at that point we have 3 standards,
> not 2. Best to try and stick to 2 standards and fix the one that has
> the best long-term prospective value.

I have a little bit different viewpoint here. I do not look at what are the low-level technical tasks or the implementation, I look at the users. We have two types of users for networking. The first type is sysadmins and the second type is end users. These two groups are as different as it gets in their use cases and how they expect things to be done.

When I look at sysadmins, then you target servers, datacenters, could and containers. So headless systems that are not mobile. They are mainly Ethernet based and configure once and not worry about anymore. As an extra added benefit some of these have to configure everything as early as the initramfs. And they want simple configuration files and command line tools.

Looking at end users, I see desktop, laptops, phones and all these embedded devices like thermostats, fridges and whatever you can think of. Things where networking can mean also WiFi, cellular even sensor networks like Bluetooth 6loWPAN. It is a dynamic world and needs configuration that is targeted for non-technical people. And end users need a nice UI for their needs. It is also not one UI, there will be many and so APIs need to be simple and designed for that user base in mind.

You normally do not take your 12-core Xeon server to the coffee shop around the corner and want to use its public WiFi with a hotspot login. If you do, please take a picture ;)

Trying to smash these together seems rather crazy to me. I looks simple in the beginning, but the devil is in the details. There is a reason why ConnMan stayed out of the datacenter world. So the way I see it is that networkd should own the initramfs and sysadmin side of things. And ConnMan will handle the end user side. What this means is that both work in harmony together.

Think of it like this, the system boots with networkd in initramfs and then you either start networkd for taking over the initramfs configuration and running in datacenter mode. Or you start ConnMan for running in desktop mode. It is a little bit over-simplified, but I think you get the basic idea.

So networkd and ConnMan for example will share a lot of code. And what we will be doing is to contribute the shared pieces into networkd. One prime example is DHCP of course. And the rest we will figure out as networkd progresses.

Regards

Marcel