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

[Lennart Poettering]

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 idea would basically be that we provide in all three daemons calls
like:

        SetAdditionalNTP(ias)
        SetAdditionalDNS(ia(uay)) 
        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.

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.

Lennart

-- 
Lennart Poettering, Red Hat