Re: [systemd-devel] [RFC 6/6] update TODO

[David Woodhouse]

On Fri Apr 10 06:26:57 PDT 2015, Tom Gundersen wrote:
> > On Fri, Apr 10, 2015 at 2:17 PM, Tomasz Bursztyka wrote:
> > +   - support IPv6
> 
> This we should probably have from the beginning, any reason you kept
> it IPv4 only for now (apart from keeping it simple as a POC)?

Wow, yeah. This far into the 21st century, you basically have to go out
of your *way* to misdesign things badly enough to make them work only
for Legacy IP and not IPv6. Do not simply note it in the TODO list.

You cannot retrofit sanity.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods

[David Woodhouse]

> 
> +static int method_find_proxy(sd_bus *bus, sd_bus_message *message, 
> void *userdata, sd_bus_error *error) {
> +_cleanup_free_ char *p = strdup("DIRECT");
> +Manager *m = userdata;
> +int r;
> +
> +assert(bus);
> +assert(message);
> +assert(m);
> +
> +r = proxy_execute(m->default_proxies, message);
> +if (r < 0)
> +sd_bus_reply_method_return(message, "s", p);
> +
> +return 1;
> +}

That seems to be making no attempt to use the *correct* proxy
configuration according to the request.

In the case of things like split-tunnel VPNs, we want to handle it
basically the same way that we handle DNS.

Requests within the VPN's DNS domains, and the IP ranges which are
routed to the VPN, need to be resolved according to the VPN's proxy
configuration. And everything else needs to be resolved according to
the local proxy configuration.

NetworkManager already sets up dnsmasq to do precisely this for DNS.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[David Woodhouse]

On  Fri Apr 10 05:17:37 PDT 2015, Tomasz Bursztyka wrote:
> 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.

What overriding reason is there for doing this instead of just using
PacRunner? If it's just the JS engine, that's *already* a plugin for
PacRunner and it's easy enough to add new options. Hell *I* managed to
add v8 support at some point in the dim and distant past, and I don't
even admit to knowing any C++. Or JavaScript.

You seem to be reimplementing the part of the solution that was already
basically *working*, while there are other parts which desperately need
to be completed.

PacRunner works. There is a libproxy plugin which uses it¹ — and
alternatively, PacRunner even provides its own drop-in replacement for
libproxy, implementing the nice simple API without the complete horror
the libproxy turned in to.

So we have the dæmon working, and we have a simple way for client
libraries and applications to use it.

The *only* thing that has so far held me back from proposing a
packaging guideline in my Linux distribution of choice which says
"applications SHALL use libproxy or query PacRunner by default" has
been the fact that NetworkManager does not pass on the proxy
information to PacRunner, so applications which query it won't yet get
the *right* results².

If you're going to look at this stuff, I wish you'd fix *that* (for
both NetworkManager and systemd-networkd) instead of polishing
something that already existed.

Then again, as long as it continues to work, I don't really care too
much. In some way, having it be part of systemd would at least give
more credence to the idea that applications SHOULD be using it by
default.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

¹ https://code.google.com/p/libproxy/issues/detail?id=152² 
https://bugzilla.gnome.org/show_bug.cgi?id=701824 and  
https://mail.gnome.org/archives/networkmanager-list/2013-June/msg00093.html

smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel