On Thu, 2013-06-13 at 13:30 -0500, Dan Williams wrote:
On Wed, 2013-06-12 at 15:26 +0100, David Woodhouse wrote:We already request WPAD information from the DHCP server (bug 368423) but we don't do anything useful with it at all.Well, except provide it to dispatcher clients.
Yeah, but you provide an irrelevant $DHCP_WPAD to dispatcher clients even when invoking them for a *VPN* connection that doesn't even use DHCP at all, let alone have a proxy configuration of its own. Has anyone ever actually tried to *use* that?
I think instead of stuffing into the IPv4 config we should probably have per-interface proxy config instead, like we have ip4_config and ip6_config. Anyone else have comments on that?
You are preaching to the choir. The NIS domain doesn't live in the IP4 config, and neither does the DNS search domain (or nameservers). They should *all* live somewhere generic.
There are any number of proxy options, and I don't think they really are IPv4 or IPv6 specific, are they? I mean, whether you get a PAC file from DHCPv4 or DHCPv6 or VPNv4 or VPNv6 doesn't really make a difference, it's just a URL.
Right. Just like the search domain. And the list of nameservers. In each case you may want to trust or distrust certain information according to whether it comes from DHCPv4 or DHCPv6 or RA or VPN server or wpad.$searchdomain or wherever. But that isn't fundamentally a Legacy IP vs. IPv6 distinction and it's wrong to make it one as we have historically done.
And I have no idea how a client would make a decision on which PAC URL to use if they had more than one?
For now my dispatcher script (bug #701824) just punts that question, on the basis that if you have more than one, it's probably because you have split-tunnel VPN. And if you have split-tunnel VPN, it's probably done *specifically* to avoid having to use the damn corporate proxies for real "Internet" access, so just having no proxy should be fine. But in the fullness of time, the plan is to handle this just like we do dnsmasq configuration for multiple connections. For each proxy configuration (be it PAC script or manual setup), we give PacRunner a list of domains/IP ranges for which that configuration applies. It needs implementing in PacRunner but it's not that hard, as PacRunner already *has* the concept of multiple configs and a 'domains' list for each one. It just doesn't *check* that list yet. But still, step one is actually making the information available in a coherent fashion at all. If you want me to have a go at a patch set which moves NIS and DNS information into the *generic* connection config, and base this patch on top of that, then I can try. But it's probably better for someone who actually knows the codebase to do that, rather than a stray monkey like me. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature