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