Re: [squid-users] (mis)understanding delay pools?

From: Gavin McCullagh <gavin.mccullagh_at_gcd.ie>
Date: Sun, 11 Oct 2009 13:36:24 +0100

Hi,

just a further question on this.

On Sun, 11 Oct 2009, Amos Jeffries wrote:

>> acl accommclients_old src 10.2.0.0/16
>> acl accommclients src 172.17.0.0/20
>> acl studentclients src 172.18.0.0/16
>> acl studentwificlients src 172.19.0.0/23
>> acl summerschoolclients src 172.19.4.0/24

>> delay_access 1 allow accommclients accommclients_old studentclients studentwificlients
>
> See
> http://wiki.squid-cache.org/SquidFaq/SquidAcl#Common_Mistakes
>
> The YOU/ME example mistake is exactly the one you have made above.

I feel pretty stupid falling on such a bog standard mistake and I'm annoyed
at myself that it has been in place for some months now.

It strikes me that, in this case, the mistake lead to an internally
contradictory (multiple times over!!) config. It couldn't possibly have
been correct. Would it be practical for squid to give a warning in this
instance?

I'm not saying squid should necessarily molly-coddle its users, but if it
weren't difficult to do perhaps it would lead to a greater degree of people
spotting their own mistakes early (before they use it for months thinking
it's working or give up confused or ask the mailing list). Compilers, for
example, do a certain amount of this kind of thing which often prevents
bugs in code.

Just looking at the FAQ page it might be nice to warn on:

 - An _access combination of ACLs which cannot match anything (eg colour is
   black and colour is white)
 - An _access which comes after one which is more general than it (eg allow
   all red colours; deny pink)
 - Possibly suggest use of src instead of srcdomain (though this is probably
   not wrong in some instances)

though there are probably others.

Perhaps this has been suggested before or perhaps there are good reasons
not to do it? Perhaps it's already there and I haven't spotted it?

Gavin
Received on Sun Oct 11 2009 - 12:36:30 MDT

This archive was generated by hypermail 2.2.0 : Mon Oct 12 2009 - 12:00:03 MDT