[systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

[Lennart Poettering]

On Fri, 10.04.15 12:06, Dan Williams (dcbw at redhat.com) wrote:

> > Now, what's left to do is open up the three daemons for foreign
> > networking daemons, such as NM. I don't think that using files in /run
> > is a good idea as a public interface, hence we'd prefer to use dbus
> > for those cases. Of course, this would mean that in that case NM would
> > push the data into our daemons, which I think is a bit of a layer
> > violation, but I am fine with, since it is outside of systemd's own
> > codebase at least.
> 
> So what you're saying is that systemd project helpers will use the
> "correct" layering, and pull from lower systemd components, but that
> external users will push the information up to the systemd helpers,
> technically an "incorrect" layering?  I guess that works but that's
> somewhat icky.

Yes. But see it like this: I really like to keep things clean within
the systemd project. I am also sure that we need these calls to push
server data into the daemons sooner or later anyway, not just for the
NM usecase. 

We tried to come up with a nice way to allow
resolved/timesyncd/... pull the data out of NM too, but defining
abstract bus ifaces or file formats in /run neither appeared to
attractive to us, the slightly ugly solution of allowing NM to push
the data into our daemons has the ebenfit of not requiring neither,
without having to add any other interface at all...

> > So idea would basically be that we provide in all three daemons calls
> > like:
> > 
> >         SetAdditionalNTP(ias)
> >         SetAdditionalDNS(ia(uay)) 
> 
> I would strongly suggest using strings in the API for IP addresses, not
> byte arrays.  

Why so?

> Also, remember that we want to push domains too, for split
> DNS in the VPN or other cases.  So it really should be something like:
> 
> SetAdditionalDNS(ia(sas))  (index, array[domain, array[server]])
> 
> what were the (uay) arguments you proposed?

resolved supprots split DNS, but it will not allow multiple DNS
servers with different domains on the same interface. Instead, you
bind a set of DNS servers and a set of domains to an interface, and
that's it, there's no further connection between servers and domains.

I fail to see the strong usecase for allowing per-server domains. I
mean in the VPn case you have one explicit interface for the VPN
connection, so this should be covered with the current design.

(uay) is supposed to be the address family (AF_INET or AF_INET6),
followed by the address bytes.

> > For the NTP case we haven't implemented this so far, since timesyncd
> > is actually an early-boot service, and dbsu1 is not available in
> > early-boot, and we didn't want to deal with the complexities this
> > creates. We can add this as soon as kdbus is reality.
> 
> NM would like to somehow convey NTP information that it receives via
> DHCP too.

Use the same mechanism.

> Yes, it does.  Now how about the roadmap for libsystemd-network being a
> standalone library? :)

Well, we still keep adding stuff...

Lennart

-- 
Lennart Poettering, Red Hat