On 6/11/20 11:52 PM, Prem Chand wrote: > It's working as expected. I tried to allow only specific domains during > the time by adding below acl but I'm getting HTTP status code 503 > acl usePeerB time 00:30-00:59 > acl usePeerB time 02:00-02:29 > acl alloweddomains dstdomain google.com facebook.com > cache_peer_access peerA allow usePeerA allowedomains > cache_peer_access peerB allow usePeerB allowedomains > cache_peer_access peerC allow !usePeerA !userPeerB alloweddomains Assuming there are no other cache peers, the above rules leave no forwarding path for a request to a banned domain. If you want to ban such requests, http_access instead of cache_peer_access. HTH, Alex. > On Thu, Jun 11, 2020 at 4:54 AM Alex Rousskov wrote: > > On 6/10/20 12:20 PM, Antony Stone wrote: > > On Wednesday 10 June 2020 at 18:11:03, Prem Chand wrote: > > > >> Hi Alex, > >> > >> Thanks for responding to my issue . I didn't get how the math > was done(why > >> it's multiplied by 2) to get 16 slots if possible could you > please elaborate > >> with an example. > > > > I believe what Alex meant was: > > > > You want 30 minute timeslots for each of 3 peers, which is 48 > half-hour > > timeslots throughout the day. > > > > However, you only need to define 48/3 of these for peer A, and > 48/3 of them for > > peer B, and then let peer C deal with anything not already handled > (so it > > doesn't need its own definitions). > > > > 48/3 = 16, therefore you define 16 half-hour periods when you want > peer A to do > > the work, 16 half-hour periods for peer B, and then just say "peer > C, handle > > anything left over". > > Thank you, Antony! Here is an untested sketch: > > acl usePeerA time 00:00-00:29 > acl usePeerA time 01:30-01:59 > ... a total of 16 ORed lines for the first peer ... > ... each line matches a unique 30 minute period ... > > > acl usePeerB time 00:30-00:59 > acl usePeerB time 02:00-02:29 > ... a total of 16 ORed lines for the second peer ... > ... each line matches a unique 30 minute period ... > > # and now match peer to its time slots > cache_peer_access peerA allow usePeerA > cache_peer_access peerB allow usePeerB > cache_peer_access peerC allow !usePeerA !userPeerB > > > The above may need further adjustments and polishing. For example, I am > not sure how Squid will round these time values. The above assumes that > 00:29 limit includes all 60 seconds up to (but excluding) 00:30:00. > > > HTH, > > Alex. > > > >> On Wed, Jun 10, 2020 at 7:12 PM Alex Rousskov wrote: > >>> On 6/10/20 6:09 AM, Prem Chand wrote: > >>>> My squid cache peer has 3 parent IP’s configured. I need to > send HTTPS > >>>> requests to the first parent IP for 30 minutes and after to the 2nd > >>>> parent IP for 30 minutes and then to 3rd IP for 30 minutes and this > >>>> switching needs to happen continuously .Could you please let us > know > >>>> how I can achieve this? > >>> > >>> If you are OK with hard-coded usage time slots for each peer, then I > >>> would use two[1] "time" ACLs and cache_peer_access rules. Look for > >>> "aclname time" in squid.conf.documented. You will have to generate a > >>> list of (24*2/3=16) staggered time slots for each of the two > ACLs, but > >>> it should work. This may be the simplest solution. > >>> > >>> [1] You need two ACLs for three peers because the third peer > should get > >>> the requests that the first two peers were not allowed to get. > >>> > >>> ---- > >>> > >>> With a modern Squid, you could also implement this using a more > flexible > >>> (and more expensive, on several layers!) architecture with two ACLs: > >>> > >>> 1. An external ACL that returns the right cache peer name to use > via a > >>> keyword=value annotation API. This always-matching ACL should be > >>> attached to http_access or a similar directive that supports > slow ACLs. > >>> Its goal is to annotate the request. You will need to write a > >>> script/program that will compute the right annotations based on > time or > >>> some other factors. This is where the flexibility of this > solution is > >>> coming from. > >>> > >>> 2. A "note" ACL attached to cache_peer_access directives, allowing > >>> access to peer X if the external ACL in item 1 returned > >>> use_cache_peer_=X. The "note" ACL is a fast ACL and, hence, can be > >>> reliably used with cache_peer_access. > >>> > >>> If you already have another external ACL, you may be able to > piggyback > >>> annotations in item 1 to whatever that ACL is already doing. > >>> > >>> For more information, search for "keyword=value" and "acl > aclname note" > >>> in your squid.conf.documented and see > >>> > https://wiki.squid-cache.org/Features/AddonHelpers#Access_Control_.28ACL. > >>> 29 > >>> > >>> > >>> HTH, > >>> > >>> Alex. > > > > > > -- > prem _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
