> On Mon, 1 Sep 2008 07:34:37 -0700 (PDT) > John Doe <jdmls@xxxxxxxxx> wrote: > >> Cool, thx. >> Would the following work...? >> >> # u1 servers pool >> cache_peer 192.168.16.101 parent 80 0 no-query originserver no-digest >> no-netdb-exchange max-conn=256 sourcehash name=u1pool >> cache_peer 192.168.16.102 parent 80 0 no-query originserver no-digest >> no-netdb-exchange max-conn=256 sourcehash name=u1pool >> cache_peer 192.168.16.103 parent 80 0 no-query originserver no-digest >> no-netdb-exchange max-conn=256 sourcehash name=u1pool >> >> # u2 servers pool >> cache_peer 192.168.16.201 parent 80 0 no-query originserver no-digest >> no-netdb-exchange max-conn=256 sourcehash name=u2pool >> cache_peer 192.168.16.202 parent 80 0 no-query originserver no-digest >> no-netdb-exchange max-conn=256 sourcehash name=u2pool >> cache_peer 192.168.16.203 parent 80 0 no-query originserver no-digest >> no-netdb-exchange max-conn=256 sourcehash name=u2pool >> >> acl u1 url_regex ^http://u1 >> acl u2 url_regex ^http://u2 >> cache_peer_access u1pool allow u1 >> cache_peer_access u1pool deny u2 >> cache_peer_access u2pool allow u2 >> cache_peer_access u2pool deny u1 >> >> Won't there be a problem with the redundant 'name=u?pool' Yes. The name= option is a UID for each peer. Also regex is very very slow. dstdomain is better for those ACL. > > I tried it once with squid 2.6. It did not work. But I would really > like it if that would actually work (i.e. grouping multiple peers > together so one doesn't need to create the same cache_peer_access-rules > for all peers). Good idea. They are already done loosely that way for selection methods, but there does not appear to be anything to group peers based on a tag, and certainly nothing to group *_access lines together yet. Want to spec out a 'pool=' option for squid? Problems: How should a group with mixed selection methods be handled? How should specific per-peer ACL affect peer group ACL? Amos
