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

>From: Amos Jeffries [mailto:squid3@treenet.co.nz]
>Sven Edge wrote:
>>> From: Amos Jeffries [mailto:squid3@treenet.co.nz]
>>>
>> 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"

It's definitely doing the lookup and caching the right destination IP
addresses.

>> 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.

Turning up debug_options, it happily gets past the ACL stuff, including
a destination check on a correctly-resolved web server ip address, spits
out a "The request GET ... is ALLOWED, because..." message, and then
does peerSelect stuff and dies.

Poking around the source for the squid-2.6.STABLE17 release currently in
Fedora, there's appears to be another source of DIRECT_NO besides a
never_direct, in peer_select.c.
http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/peer_select.c
I've got version 1.131, where there's an "if
(request->flags.accelerated)" that can cause a DIRECT_NO, but the most
recent version 1.134 has changed that. Not sure what the code's testing
for in either version, but from the commit comment it sounds like up to
now 2.6 was deliberately blocking direct access when in accelerator
mode.

Maybe it's just a case of waiting for the next release?

Sven
Received on Tue Feb 19 2008 - 07:00:51 MST