Re: [squid-users] DNS-based reverse proxy peer selection, 2.5 vs 2.6

Sven Edge wrote:
>> From: Amos Jeffries [mailto:squid3@treenet.co.nz]
>>
>>> Is there a way to do this in 2.6?
>> Yes, with a little trickery in DNS. You need to use DNS-views
>> so that the
>> public see squid as being an A/AAAA for the domain and squid
>> does not. If
>> squid ever find itself as a source server for any of the domains its
>> accelerating you get a forwarding-loop.
>
> That's more or less how we do things currently with 2.5.

Yes. It's the same old behaviour without the advanced per-ACL routing
cache_peer allow.

>
>> Other than that catch; configure squid as a normal 2.6 accelerator with
>> vhost and defaultsite on the http_port line, omit any cache_peer_*
>> settings, and set as an open-proxy for the domains you are providing.
>> An external acl helper may be needed to accurately limit the open-proxy
>> behaviour to just the hosted domains.
>
> I think that's what I'm trying, and it fails to find a web server to
> talk to.

Hmm, you can do a spot-check on squid with
    "squidclient mgr:ipcache | grep www.scran.ac.uk"

or track this in cache.log as "debug_options 14,5"
to find out what its looking up and what its trying to use for the
source server on direct.

>
> Using just "http_port 80 accel vhost defaultsite=www.scran.ac.uk", and
> requesting http://www.scran.ac.uk/ from outside our network gives the
> following:
>
> debug 3:
> 2008/02/19 10:14:30| fwdStart: 'http://www.scran.ac.uk/'
> 2008/02/19 10:14:30| storeLockObject: key
> 'B13D9EB5D8D657257342FBE9C74C77D8' count=3
> 2008/02/19 10:14:30| peerSelect: http://www.scran.ac.uk/
> 2008/02/19 10:14:30| storeLockObject: key
> 'B13D9EB5D8D657257342FBE9C74C77D8' count=4
> 2008/02/19 10:14:30| cbdataLock: 0xdc6968
> 2008/02/19 10:14:30| peerSelectFoo: 'GET www.scran.ac.uk'
> 2008/02/19 10:14:30| peerSelectFoo: direct = DIRECT_NO

Looks like possibly a never_direct or a deny ACL getting in the way.

> 2008/02/19 10:14:30| peerSelectIcpPing: http://www.scran.ac.uk/
> 2008/02/19 10:14:30| neighborsCount: 0
> 2008/02/19 10:14:30| peerSelectIcpPing: counted 0 neighbors
> 2008/02/19 10:14:30| peerGetSomeParent: GET www.scran.ac.uk
> 2008/02/19 10:14:30| getDefaultParent: returning NULL
> 2008/02/19 10:14:30| peerSourceHashSelectParent: Calculating hash for
> rem.ote.ad.dr
> 2008/02/19 10:14:30| getRoundRobinParent: returning NULL
> 2008/02/19 10:14:30| getFirstUpParent: returning NULL
> 2008/02/19 10:14:30| getAnyParent: returning NULL
> 2008/02/19 10:14:30| getDefaultParent: returning NULL
> 2008/02/19 10:14:30| peerSelectCallback: http://www.scran.ac.uk/
> 2008/02/19 10:14:30| Failed to select source for
> 'http://www.scran.ac.uk/'
> 2008/02/19 10:14:30| always_direct = 0
> 2008/02/19 10:14:30| never_direct = 0
> 2008/02/19 10:14:30| timedout = 0
> 2008/02/19 10:14:30| cbdataValid: 0xdc6968
> 2008/02/19 10:14:30| fwdStartComplete: http://www.scran.ac.uk/
> 2008/02/19 10:14:30| fwdStartFail: http://www.scran.ac.uk/
> 2008/02/19 10:14:30| fwdFail: ERR_CANNOT_FORWARD "Service Unavailable"
> http://www.scran.ac.uk/
> ...
>
>
> Separately, I also tried setting a cache_peer to the shared hostname of
> the web servers, but that just meant squid used the first IP address it
> got for that hostname for all requests, as opposed to load balancing
> between all the ip addresses, and completely ignored that some requests'
> hostnames didn't resolve to the ip address it was using.
>
> If it's relevant, in both cases, according to cachemgr the IP cache does
> contain all of the correct values for "www.scran.ac.uk".
>
> Setting "prefer_direct on" doesn't do anything.
>
> Ooh. Using always_direct works, including switching origin servers
> immediately after IPcache gets to 0 TTL, although am I right in thinking
> that precludes having multiple squids as siblings?

Yes that would work. And you are correct that will prevent siblings
being tried.

Amos

-- 
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.