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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
