Hi Alex,
I stopped the
peerA(purposefully) and noticed that requests are failing
for the time slots that are going through peerA. I used
"connect-fail-limit" in cache_peer but it's not working. Is there any
way we can address this issue using the same solution considering how to
handle the requests if any of the parent peer goes down?
Thanks & Regards
Premchand .
On Fri, Jun 12, 2020 at 6:47 PM Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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
--
prem
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
