[squid-users] Advice on Cache Peer ACLs

[creditu at eml.cc]

Thanks for the great explanation.  Much appreciated.  

On Fri, Aug 30, 2019, at 2:10 PM, Alex Rousskov wrote:
> On 8/30/19 2:41 PM, squid at buglecreek.com wrote:
> 
> > All requests will always start with www.example.com /.... or origin-www.example.com/
> 
> If that is true, why check domain names at all? When you write an ACL
> that checks for X, it is reasonable to assume that X may not happen. My
> evaluation of your rules made that assumption.
> 
> > Are you saying I should have the following for .4 and .5 instead of what I'm currently using?  
> > 
> >  cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >  cache_peer_access 192.168.1.5 allow limited
> >  cache_peer_access 192.168.1.5 allow all_requests
> >  cache_peer_access 192.168.1.5 deny all
> 
> No, the above does not match what you want to achieve AFAICT. If domain
> names matter, then you should have something like this:
> 
> >  cache_peer_access 192.168.1.5 allow limited all_requests
> >  cache_peer_access 192.168.1.5 deny all
> 
> 
> Needless to say, the name "all_requests" is very misleading, pointing to
> the same inconsistency/problem we are discussing. I will use "myDomains"
> below but you may find a better name based on your business logic.
> 
> The "limited" name also looks like a poor choice because all ACLs
> (except "all") limit matching. I will use mapOneOrTwo below instead.
> 
> If you fix the names, the rules become simpler/readable. For example:
> 
> cache_peer_access 192.168.1.1 deny mapOneOrTwo
> cache_peer_access 192.168.1.1 allow myDomains
> cache_peer_access 192.168.1.1 deny all
> 
> ...
> 
> cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains
> cache_peer_access 192.168.1.5 deny all
> 
> 
> You can achieve even better clarity if you use negation, but I usually
> recommend against negating ACLs:
> 
> cache_peer_access 192.168.1.1 allow !mapOneOrTwo myDomains
> cache_peer_access 192.168.1.1 deny all
> 
> ...
> 
> cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains
> cache_peer_access 192.168.1.5 deny all
> 
> 
> 
> Finally, if domain names do _not_ matter, then you will just have:
> 
> cache_peer_access 192.168.1.1 deny mapOneOrTwo
> cache_peer_access 192.168.1.1 allow all
> 
> ...
> 
> cache_peer_access 192.168.1.5 allow mapOneOrTwo
> cache_peer_access 192.168.1.5 deny all
> 
> 
> HTH,
> 
> Alex.
> P.S. If possible, mapOneOrTwo should be replaced with something more
> meaningful according to your business logic.
> 
> 
> > On Fri, Aug 30, 2019, at 11:41 AM, Alex Rousskov wrote:
> >> On 8/30/19 11:44 AM, creditu at eml.cc wrote:
> >>> We use several squid servers in accelerator mode for load balancing to send public requests to backend servers.   The squids don't do any caching, they just forward requests to the backend. 
> >>>
> >>> We have cache_peer directives to send the incoming requests to the backend Apache servers.  What I need to do is send requests to a certain page to a specific backend server and all others to the  other backends.  The site has many pages, subpages etc.  
> >>>
> >>> What I want to do is if someone requests:
> >>> https://www.example.com/anything/anything/script.php   or https://origin-www.example.com/anything/anything/etc/etc/script.php
> >>>
> >>> Send the request to only .1, .2,.3.
> >>>
> >>> If someone requests :
> >>> https://www.example.com/anything/tst/map2/script.php   or https://origin-www.example.com/anything/anything/tst/map1/etc/script.php
> >>>
> >>> Send that request only to .4 and .5.
> >>>
> >>> It seems to work most of the time, but tailing the access logs on the servers I sometimes see one of the requests for ../tst/map2/... or map1 show up on .1,.2, or .3.  
> >>
> >>
> >> Do Squid access logs have the corresponding records as well? What cache
> >> peer selection algorithm does Squid record for those misdirected
> >> transactions?
> >>
> >>
> >>> Is there something I'm missing?
> >>
> >> Could Squid go direct to one of those origin servers (e.g., when all
> >> eligible cache peers were down)?
> >>
> >> BTW, please note that your cache_peer_access rules look inconsistent:
> >> Your cache_peer_access .1-3 rules require certain domain names but .4-5
> >> rules do not. This does not explain the discrepancy you are describing
> >> above, but you may want to adjust your rules for consistency sake
> >> (either to ignore dstdomain completely or to require correct domains for
> >> all cache peers).
> >>
> >>
> >> HTH,
> >>
> >> Alex.
> >>
> >>
> >>> acl all_requests dstdomain -n www.example.com origin-www.example.com
> >>> acl limited  url_regex -i /tst/map1|/tst/map2
> >>>
> >>>
> >>> cache_peer 192.168.1.1 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.1 deny limited
> >>> cache_peer_access 192.168.1.1 allow all_requests
> >>> cache_peer_access 192.168.1.1 deny all
> >>>
> >>> cache_peer 192.168.1.2 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.2 deny limited
> >>> cache_peer_access 192.168.1.2 allow all_requests
> >>> cache_peer_access 192.168.1.2 deny all
> >>>
> >>> cache_peer 192.168.1.3 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.3 deny limited
> >>> cache_peer_access 192.168.1.3 allow all_requests
> >>> cache_peer_access 192.168.1.3 deny all
> >>>
> >>> cache_peer 192.168.1.4 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.4 allow limited
> >>> cache_peer_access 192.168.1.4 deny all
> >>>
> >>> cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.5 allow limited
> >>> cache_peer_access 192.168.1.5 deny all
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>