On Thu, 2013-06-13 at 20:42 +0100, David Woodhouse wrote: > 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?
Because the parent device config is passed to the dispatcher here, which pulls out the DHCP options. Given that VPN connections don't currently have DHCP capability, I'd expect clients to ignore that information. For proxy configuration, we'd define new PROXY_ env variables that contain the merged proxy configuration from various sources, including DHCP and VPN. > > 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. Yeah, it was basically added because SUSE's netconfig conflates all that crap together and doesn't have a better way of doing it, plus almost nobody (hopefully) uses NIS anymore so it's pretty harmless. It likely shouldn't have been there, but I didn't really want to rearchitect a whole bunch of stuff just for NIS. > > 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. Yeah, except that it's *delivered* via those mechanisms, and who knows whether they talk to each other. I know we argued about this on IRC and I think we mostly agree; they are global *after* NM receives them and combines them with user overrides, but their sources are clearly stack-specific and users may want/need to override them that way. But yes they are obviously global when written out to the system, like proxy information is. > > 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. Hmm, not sure we can assume that. I'd rather do "use first one". Split tunnel doesn't have anything to do with it though, right? It's just if your corporate VPN stuff gives you a proxy, and your local DHCP stuff gives you a proxy, then you really have no idea what to use. You might be at a location that requires a proxy for access to most resources, but you've got a VPN connection that also requires a proxy for other stuff. So if you do run split tunnel, anything !VPN would require the DHCP-provided proxy, while anything VPN may or may not. Seems pretty likely nothing can handle this situation unless pacrunner can reliably give an answer for "how do I get here" using a number of domains and proxy settings. > 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. Yeah, that sounds like the right approach. > 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. Well, lets start with something like an internal NMProxyConfig just like we have NMIPxConfig; export that over the bus just like the other two, and stuff the PAC URL into it. We can add the other manual settings later if/when we get NMSettingProxy. Then you can populate ProxyConfig with the info from VPN and info from DNS, and eventually the dispatcher can use it too. How does that sound? Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
