[systemd-devel] [RFC 2/6] proxy-discoveryd: Add the basics for parsing the default configuration

[Tomasz Bursztyka]

Hi Marcel and Lennart,

>>>>> The config file will be in /etc/systemd/proxy/<filename>.conf
>>>>>
>>>>> It currently only load "Proxy" parts, with the key PAC. Rest is ignored.
>>>>> The PAC keyword is a path to a .pac file (a specific js script for proxy
>>>>> configuration).
>>>>>
>>>>> Only one PAC based proxy configuration will be loaded at a time.
>>>> (Just a side note: I figure in the long run we should probably track
>>>> PAC data per-interface (plus maybe one global setting), so that
>>>> clients can query this specifically for an interface, and so that we
>>>> can search PAC data over the right network. But I figure for now this
>>>> doesn't matter too much.).
>>> why would you have a global PAC file. I think they should be all per
>>> interface and nothing else.
>> Well, maybe not a global PAC file, but probably an explicitly
>> configurable global HTTP proxy, if people want that... I mean, it is a
>> pretty common setting to have I figure, and the daemon should
>> proibably cover both PAC and straightforward proxy config...
> yes that makes sense. So what we have done in PACrunner was that instead of a PAC file you could just give it the HTTP proxy address. And that would also work per interface. When then libproxy or someone did FindProxyForURL, the configured HTTP proxy URL was returned.
>
> Of course in these situations, no PAC files are executed, but the D-Bus API for talking to systemd-proxydiscoverd to get the proxy to use can be still used.
>
> I still wonder if it is a good idea to have a global proxy there. I would assume you just configure the proxy per interface in your network configuration file. This should be treated similar to DNS configuration. You want this per interface.

The main point of proxy/<file>.conf files will be indeed to get manually 
set proxies.
Keywords such as: Protocol, Host, Port, etc...
We used to set everything through URIs in pacrunner, but it's finally 
easier to set stuff one by one: less room for bugs and errors.

Tom came with the idea we could do it expressive enough so even complex 
proxy setups could be done,
thus such PAC keyword could be removed eventually.
Then only dynamic context due to dhcp/wpad would generate a PAC based 
proxy configuration.

Tomasz