Re: [squid-users] reloading settings on a regular basis

2012/10/1 Amos Jeffries <squid3_at_treenet.co.nz>:
> On 01.10.2012 03:39, E.S. Rosenberg wrote:
>>
>> 2012/9/30 Amos Jeffries <squid3_at_treenet.co.nz>:
>>>
>>> On 30/09/2012 12:43 p.m., Eliezer Croitoru wrote:
>>>>
>>>>
>>>> On 9/29/2012 9:38 PM, E.S. Rosenberg wrote:
>>>>>
>>>>>
>>>>> I have A, B and C with a potential for quite a few more (not
>>>>> necisarily ISPs but also browsing restrictions or lack thereof).
>>>>> I guess I over-simplified things a bit, but we have lots of user based
>>>>> stuff going on, in addition we also want to start capping bandwidth
>>>>> usage on a per user basis so that resources are shared more fairly
>>>>> etc.
>>>>> Regards,
>>>>> Eli
>>>>
>>>>
>>>>
>>>> Well still the only difference is that you will need to design the acls
>>>> you are going to use.
>>>> are you using tproxy or intercept?
>>>> you can try by listing a of the things you want to implement and then
>>>> plan
>>>> the network design by that.
>>>>
>>>> if you have 6 ISP's for example you can put one proxy not cache at all
>>>> for
>>>> the interception and accounting stuff which is basically acls and other
>>>> stuff.
>>>> then use cache_peers with 6 incoming ports that will decide the outgoing
>>>> port by the incoming port.(just something in my mind).
>>>
>>>
>>>
>>> or a "OK tag=ISP-1" from the external ACL helper and a tag type ACL in
>>> tcp_outgoing_* to determine either outgoing IP or TOS marking.
>>>
>>> I recommend 3.2.1 or later for this type of thing though we did a lot of
>>> bug
>>> fixing and performance polishing of this type of config in 3.2.
>>>
>>>
>>>
>>>>
>>>> if you have some ICAP service then put it somewhere in the
>>>> infrastructure
>>>> in a place that wont effect you delay pools etc.
>>>>
>>>> I dont remember about resources consumption by a no cache at all squid
>>>> but
>>>> it should be low.
>>>
>>>
>>>
>>> Squid uses a few MB base footprint and up to (usually under) 256KB per
>>> concurrent transaction. The rest is cached data.
>>>
>>>
>>>> I do remember you wanted somewhere to cache youtube etc..
>>>> I have a working solution for that and I'm working on store_url_rewrite
>>>> which can benefit from this two.
>>>>
>>>> you can also add some captive portal that has user validation in it for
>>>> wireless places ( I was working on a way to do it for transparent proxy
>>>> like
>>>> in wifi-coffe shops that has agreement and other stuff like "prepaid
>>>> cap"
>>>> that is being used in cellular providers.
>>>>
>>>> just make a list of things you need\want to get from the network and
>>>> from
>>>> there the only question is how to put the whole puzzle together.
>>>>
>>>> Regards,
>>>> Elizer
>>>>
>>>
>>> Amos
>>
>>
>> Great.
>> So just to summarize:
>> - Reloading often is bad, use smartly structured ext_acls instead.
>>
>> As far as how we do it, we don't use tproxy, we have a class B for
>> ourselves so internally, so the user facing proxy that needs to handof
>> information about a forced plan because of some location does that
>> through the IP it presents to the parent.
>
>
> This is questionable practice. Does the information have to be passed as an
> IP or would using TOS values to mark the service type for particular
> handling work with your other infrastructure?
Well this is what we need to do for one of our ISPs and I saw no
reason not to use the same technique internally, what's bad about
conveying that info like that?

Also I don't see any ACL that in turn allows me to do stuff on the
parent based on the TOS set by the child cache...
Thanks,
Eli
> Squid can set outgoing for either of them just as easily and based on the
> same ACLs. You can even migrate by setting both on Squid outgoing packets
> while you upgrade other things.
>
> Amos
>
>
>> The parent in turn is connected to all ISPs/plans so that it can get
>> better caching results and limit the total traffic of a user (ie.
>> wireless and lab stations).
>>
>> Youtube is something I hope to optimize for in the future but fist
>> this general architecture needs to become active and then we'll start
>> caching optimizations.
>>
>> Thanks,
>> Eli
>
>
Received on Thu Oct 04 2012 - 15:36:24 MDT