Search squid archive

Re: Re: Squid and Splash page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30/12/2011 8:14 p.m., ming wrote:
I have these acl settings in my squid.conf

external_acl_type acexternal children=50 ttl=60 negative_ttl=1 %>{X-MYAUTH}
/usr/local/bin/acexternal localhost
acl iceauth external acexternal
http_access allow iceauth
http_access deny all

I turned on debug mode and see the following message. I noticed that there
is a message (in red) saying that the externalAclLookup: no need to work...
This custom external acl program should return "OK", but because of "no
wait" situation, it get to the "http_access deny all" acl and the request
got denied
<snip>

===========
Then I played around the acl and have the following setup using "deny !"
instead of "allow" on iceauth. But then I need to use "allow all" instead of
"deny all"...

external_acl_type acexternal children=50 ttl=60 negative_ttl=1 %>{X-MYAUTH}
/usr/local/bin/acexternal localhost
acl iceauth external acexternal
http_access deny !iceauth
http_access allow all

I noticed that in the debug message, the same "no wait" message above turned
into a "will wait" situation (see below message in red). Since it waits, it
got "OK" returned from the custom acl program.
It seems works for what I need but I need to use "allow all" that I don't
really like.
<snip>

- Can you please explain why there is a "no wait" in the 1st setup, but
"will wait" in the 2nd setup?


The "wait" case the input line is completely new and a lookup answer is waited for.

There is already a known answer in the "no wait" case. A re-check is scheduled, but there is no need to wait for that answer, Squid already has one it can use immediately.
...
externalAclLookup: no need to wait for the result of 'Basic%20bXlLZXk6bXlWYWx1ZQ==' in 'acexternal' (ch=0x23a5698).
externalAclLookup: using cached entry 0x23adf58
externalAclLookup: entry = { date=1325109258, result=1, user= tag= log=myKey }
ACLChecklist::asyncInProgress: 0x23a5698 async set to 0
aclmatchAclList: async=1 nodeMatched=0 async_in_progress=0 lastACLResult() = 0 finished() = 0

Note: "result=1" is "OK". Why nodeMatched=0 happens is unclear. I think it should be =1 at that point.

There was a bug (#3412) fixed in the grace period handling in 3.1.17, does this still occur with the latest release?

If so can you please try the proposed patch from bug 3370 (http://bugs.squid-cache.org/show_bug.cgi?id=3370). It does not seem directly related, but would be worth checking anyway.

- I don't want to use "allow all". is there any better way to set the acl to
serve my need?

The first setup seems to be the right one. Once the bug is fixed.

Amos


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux