Re: [squid-users] Unusual behaviour when linking ACLs to delay pools

On Thu, Aug 19, 2010 at 10:10 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:

> This category are tested so often on high-speed pathways they can only use
> the data immediately available in memory and will not do remote lookups for
> auth or external helper results.
>
> They will *sometimes* be able to use cached in-memory results from previous
> lookups. So the the "slow" category ACL types are not prohibited in "fast"
> category access controls. But they are not guaranteed to work 100% of the
> time either.
>
>
> I suspect your http_access rules are different when testing for the two
> groups. In such a way that the "throttled" ACL never gets tested in
> http_access (causing its result to be cached for delay_Access).
>
>
> My favorite hack for pre-caching these types of lookup results for later use
> is to test the ACL by itself early in the config with !all tacked on the end
> of the line (which prevents the line as a whole matching and doing the
> allow/deny).

Thanks! And you'd be dead right. That's exactly what was happening.
The test against another group was succeeding as it had already been
used for Internet access by proxy_auth.

I now have another problem, however, in that it appears you can't AND
multiple ACLs to determine whether or not they can access a delay
pool. Say for instance, I wanted to do:

delay_access 1 allow throttled badfiles
delay_access 1 deny all

This would throttle only when members of the 'throttled' acl attempt
to download files in the 'badfiles' acl. I can apply the pool to one
ACL or the other, but not both. I also tried getting cheeky and
stacking multiple conditions into the ACL definition. eg:

acl throttled urlpath_regex -i "/etc/squid/badfiles.txt"
acl throttled external ldap_group Internet-Throttled

But squid doesn't like mixing multiple conditions to make a single acl.

Is there a workaround for this?

Thanks
Richard
Received on Thu Aug 19 2010 - 23:04:11 MDT