[squid-users] cache_peer_access by dynamic ACL

[Alex Rousskov]

On 4/18/23 11:41, Alexeyяр Gruzdov wrote:

> Could you explain me how the annotation transaction works and how it 
> related to acl that I could to use with cache_peers

Transactions have a (possibly empty) set of name=value annotations.

During Squid configuration time, Squid parses all ACL declarations in 
your configuration file. When Squid parses an annotation_transaction ACL 
declaration, Squid remembers what transaction annotation to add in the 
future, [every time] when that ACL is evaluated (e.g., used in 
http_access rule that Squid reaches during transaction processing).

When evaluated, an "annotation_transaction" ACL simply adds the 
previously configured annotation to the current transaction and returns 
a "yes, this transaction matches" result.

When evaluated, a "note" ACL returns a "yes, this transaction matches" 
result if and only if the current transaction already has the matching 
annotation. This ACL does not modify the set of transaction annotations.

The combination of annotate_transaction and note ACLs allows you to 
annotate a transaction at one time and check previously set transaction 
annotations at another time. The timing and meaning of those annotations 
are up to you.


> ok! Lets look to my case example:

> cache_peer peerG1.com parent 40001 0 no-query no-digest name=peerG1 round-robin

> cache_peer_access  peerG1 allow proxy_peerG1_acl
> cache_peer_access  peerG1 allow proxy_all_acl
> cache_peer_access  peerG1 deny all

> acl proxy_peerG1_acl  proxy_auth  "../users.peerG1.txt"
> acl proxy_all_acl  proxy_auth  "../users.all.txt"

[ I added the missing "acl " directive to the above ACL declarations and 
stripped rules for two out of three cache_peers ]

As you know, the above cache_peer_access configuration is not supported 
because it uses "slow" proxy_auth ACLs in cache_peer_access directives 
that only support "fast" ACLs. It does not matter (to me), whether the 
above appears to "work" in some environments. YMMV.

To fix this problem, we can use http_access rules to essentially 
remember proxy_auth evaluation results (at http_access evaluation time) 
as transaction annotations. Here is an untested sketch that omits other 
(important but irrelevant here) http_access rules and assumes that these 
sketched http_access rules _are_ evaluated:

   # if proxy_peerG1_acl matches, evaluate mark_for_peerG1
   http_access deny proxy_peerG1_acl mark_for_peerG1 !all

   # if proxy_all_acl matches, evaluate mark_for_all_peers
   http_access deny proxy_all_acl mark_for_all_peers !all


Now we can use those remembered proxy_... acl evaluation results (i.e. 
we can check for the matching annotations) in cache_peer_access rules:

   cache_peer_access peerG1 allow marked_for_peerG1
   cache_peer_access peerG1 allow marked_for_all_peers
   cache_peer_access peerG1 deny all


where the new ACLs mentioned above are declared along these lines:

   acl mark_for_peerG1 annotate_transaction for_peer_=G1
   acl mark_for_all_peers annotate_transaction for_all_peers_=true

   acl marked_for_peerG1 note for_peer_ G1
   acl marked_for_all_peers note for_all_peers_ true

This can probably be simplified further by using for_peer_=ALL instead 
of for_all_peers_=true annotation, but I wanted to preserve the symmetry 
with your original configuration.


> And these all works like I need, But - once I am changing a list of 
> users (add or remove) - I need to use "squid -k reconfigure"...... but 
> of course better to go without this reconfigure

One can avoid reconfiguration using an external ACL script that gives 
Squid the right for_peer_=... annotations (instead of using "constant" 
or "hard-coded" annotate_transaction ACLs to store the same annotations).

However, it may be better to make the above sketch to work _before_ you 
replace mark_for_peerG1 ACLs/rules with an external 
mark_for_the_right_peer ACL.


HTH,

Alex.
P.S. This thread continues the discussion started at
https://bugs.squid-cache.org/show_bug.cgi?id=5268