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

[Amos Jeffries]

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