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

On 5/10/2012 4:36 a.m., E.S. Rosenberg wrote:
> 2012/10/1 Amos Jeffries:
>> On 01.10.2012 03:39, E.S. Rosenberg wrote:
>>> 2012/9/30 Amos Jeffries:
>>>> 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?

"questionable". IPv4s are running out, and how many does this one server
consume?

It also limits the connection count since each IP is locked to one user
who woudl be using not many ports out of the 64k that IP would otherwise
make available.

> 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...

That is a probem. I was of the understanding this was a single proxy
layer with upstream routes. The OS routing systems should be fully
capable of receiving TOS values from Squid and routing traffic based on
them.

Amos
Received on Fri Oct 05 2012 - 02:42:26 MDT