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

[Dan Williams]

On Fri, 2015-04-10 at 19:19 +0200, Lennart Poettering wrote:
> 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?

It's much easier to use for languages other than C, like Python or JS or
Ruby or dbus-send or even C in many cases.  We originally used binary
addresses in the D-Bus interface for NetworkManager, and eventually
found that was the wrong choice for these reasons.  It's also easier to
pull in and out of D-Bus, with dbus-glib or GIO.  I'm not sure about
sd_bus though.

> > 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.

If I understand correctly, this means you cannot direct *.foobar.com to
one set of DNS servers,and *.baz.com to another set, assuming those are
bound to the same interface?  Why not allow that?

> 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.

IPSec doesn't give you an kernel netdev at all, it's just routing on an
existing interface.  So for that interface, you'd have both the VPN
servers and upstream servers, all bound to the same interface, and no
ability to direct VPN domains to the VPN servers since they are all on
the same interface?

Dan

> (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
>