[squid-users] change between squid 3.1 and 3.3.8
squid3 at treenet.co.nz
Mon May 2 15:07:50 UTC 2016
On 3/05/2016 2:07 a.m., TRIFILETTI Frank (Adjoint au chef du DO Sud-Est
/ Chef du groupe expertise technique) - SG/SPSSI/CPII/DOSE/ET wrote:
> Hello Amos,
> i have this error in my cache.log (no helper entry available)
> 2016/05/02 14:35:37.732| external_acl.cc(793) aclMatchExternal:
> 2016/05/02 14:35:37.732| external_acl.cc(822) aclMatchExternal: No
> helper entry available
> 2016/05/02 14:35:37.732| external_acl.cc(826) aclMatchExternal:
> ldap_group check user authenticated.
> 2016/05/02 14:35:37.732| external_acl.cc(832) aclMatchExternal:
> ldap_group user is authenticated.
That is the external ACL detecting that it has the username required by
%LOGIN macro, but still needs to do a lookup for the helpe response
The next thing it would do is a helper cache lookup to see if it already
knows the response that would come back.
Only if that cache check produces nothing, or stale entry would it
DUNNO. Otherwise it would tell you what it found and match.
> and i read you link
> in my squid.conf i use a slow ACLs (external)
> with one SLOW access clauses (http_access) and another one which is FAST
> access clauses (cache_peer_access)
> but i made another test with the same squid.conf with squid 3.1.20 on an
> Ubuntu 12.04.5 LTS it works (no DUNNO error in cache.log)
FYI: DUNNO used to be logged as "-1" in 3.1.
> but it doesn't with squid 3.3.8 on an Ubuntu 14.04.4 LTS
It is a matter of timing and caching of the helper response. The trick
with using http_access as well as cache_peer_access is to get the helper
lookup done and the response into the helper cache, so that the FAST
lookup can find it there without needing to do a slow lookup.
But that relies heavily on the entry still being cached when
cache_peer_access needs it. Sometimes it will not be.
More information about the squid-users