[squid-users] Why is overlapping dstdomains a FATAL error now?

[Dan Charlesworth]

Huh! Thanks for that, Amos. 

Our software actually flags the redundant entries and doesn't write those ones out, just that I realised I didn’t really understand “why” squid does that and why we need to work around it in the first place.

Doing a `-k parse` before loading any new changes is super good advice though. We’ll be implementing that failsafe for sure.

> On 7 Aug 2015, at 1:26 pm, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> 
> On 7/08/2015 11:48 a.m., Benjamin E. Nichols wrote:
>> Agreed, whoever decided it was a wise decision to make this a stop error
>> should be fired or at the very least, slapped in the back of the head.
>> 
>> On 8/6/2015 6:44 PM, Dan Charlesworth wrote:
>>> This used to just cause a WARNING right? Is this really a good enough
>>> reason to stop Squid from starting up?
>>> 
>>> 2015/08/07 09:25:43| ERROR: '.ssl.gstatic.com
>>> <http://ssl.gstatic.com/>' is a subdomain of '.gstatic.com
>>> <http://gstatic.com/>'
>>> 2015/08/07 09:25:43| ERROR: You need to remove '.ssl.gstatic.com
>>> <http://ssl.gstatic.com/>' from the ACL named 'cache_bypass_domains'
>>> FATAL: Bungled /etc/squid/squid.conf line 149: acl
>>> cache_bypass_domains dstdomain "/acls/lists/8/squid_domains”
>>> 
> 
> It *seems* very daft. But there actually is a very good reason.
> 
> Squid stores these data into a splay tree structure as it goes. Adding
> to a splay tree is a one-way operation. There is no remove short of
> dumping the entire squid.conf and re-configuring.
> 
> [ just a side note: we *are* actively in the process of trying to
> eradicate these splay trees and use another type of fast hash we could
> remove from. ]
> 
> There are several cases for what the loaded file may contain:
> 
> A)
> .gstatic.com
> .ssl.gstatic.com
> 
> B)
> .gstatic.com
> .gstatic.com
> 
> C)
> .gstatic.com
> gstatic.com
> 
> D)
> .ssl.gstatic.com
> .gstatic.com
> 
> E)
> gstatic.com
> .gstatic.com
> 
> 
> Cases (A, B, C) will happily go along and add .gstatic.com to the ACL.
> The next one is an overlap with a more narrow matching range than
> already in the tree.
> These *are* nicely displayed as WARNING, and just ignored by Squid as
> it continues to run. If you put "acl all src 0.0.0.0" into a squid-3
> config you can see that happen.
> 
> 
> Cases (D, E) are special. The first entry already added to the ACL splay
> will match *less* than the second one.
> Now the way using a splay tree works is that for any lookup one of them
> will be 'closer' and thus match. But not always the same one.
> So adding both to the splay will cause domains in the non-overlap area
> to randomly be blocked or allowed.
> These are what you are seeing displayed as ERROR.
> 
> So then we get back to how restarting the entire reconfigure process
> from scratch is needed to remove the first entry from the splay tree.
> 
> ---> Doing a reconfigure will only load the same details in the same
> order unless manually fixed first.
> 
> Squid must halt and wait for you to fix this. If it is left running the
> config *will not* be doing what you intended Squid to do. That is FATAL.
> 
> 
> And BTW, finding these issues in manually edited or third-party lists is
> one of the reasons one should always run "squid -k parse" before loading
> new config.
> 
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users