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

[Dan Williams]

On Fri, 2015-04-10 at 17:17 +0200, Lennart Poettering wrote:
> On Fri, 10.04.15 09:22, Dan Williams (dcbw at redhat.com) wrote:
> 
> > On Fri, 2015-04-10 at 15:17 +0300, Tomasz Bursztyka wrote:
> > > Hi,
> > > 
> > > As it has been discussed in the systemd hackfest during the Linux Conference
> > > Europe, one daemon could centralize the management of all network proxy
> > > configurations. Idea is something user can do per-application (like in
> > > firefox for instance) or broader (per-DM like in Gnome), user could do it
> > > once and for all through such daemon and applications would then request it
> > > to know whether or not a proxy has to be used and which one.
> > > 
> > > As a notice, this is nothing new. Such standalone daemon has been already
> > > done by the past, pacrunner. systemd-proxy-discoveryd will more or less
> > > implement the same ideas with improvements. It will get rid of big JS
> > > engines like spidermonkey or v8 which are overkill for the tiny PAC files
> > > to be executed on, for instance. From pacrunner experience, APIs will be
> > > also improved.
> > 
> > I haven't looked in great detail, but is there some way that other
> > services (like NetworkManager) which have information about proxies
> > discovered via DHCP, would get this information to the daemon?  AFAIUI
> > Lennart in the past has wanted "higher level" stuff (like this daemon I
> > presume) to pull that information from "lower level" processes (like
> > NetworkManager or systemd-networkd).  What are the provisions for that?
> 
> Well, there are three cases where this matters:
> 
> 1. systemd-timesyncd for NTP servers
> 2. systemd-resolved for DNS servers
> 3. and now systemd-proxy-discoveryd for HTTP proxy/PAC stuff
> 
> All of them should get some data from networkd, for example when the
> user configures an NTP/DNS/proxy server in the network configuration,
> or when this data is learnt via DHCP. In this case we should have
> proper stacking, since the three daemons should pull the data out of
> networkd on their own. The way this should work (and already does for
> the case of timesyncd/resolved), is by watching files in /run, so that
> we require no bus interaction to call this.
> 
> 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.

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

>         SetAdditionalPAC(ias)
> 
> Or so, which could be used push additional NTP, DNS, or PAC data into
> the respective daemon, and for the specified ifindex.
> 
> 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.

> For the DNS cases I haven't implemented this so far, because I didn't
> find the time to yet.
> 
> For the PAC case this is not implemented because the code is very very
> new, and not even merged yet.
> 
> I hope this clarifies the road map on this a bit.

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

Dan