Re: [squid-users] Squid 3.2.0.9 problems and special reverse proxy configuration

 On Wed, 13 Jul 2011 12:27:11 -0700 (PDT), niemidc wrote:
> I really have two things I'd like to ask about.
>
> 1) I'm using Squid 3.2.0.x for a use that will eventually be a
> production
> use, but not right away. SMP is quite a desirable feature for us.
> What
> shape is 3.2 in these days? 3.2.0.9 seems pretty badly broken, the
> two
> backwards strncmp() calls that were also in 3.1 seem to have
> afflicted it
> too, without a release fixing it yet. I also seem to have found a
> backwards
> assert() call, and even after fixing these three it is not working
> for me.
> Is 3.2 in a huge amount of churn, with lots of new features that are
> not yet
> tested? Or should it be starting to stabilize soon?

 3.2.0.8 is very stable, but still has most of the issues from 3.1.

 As you say, 3.2.0.9 has paid a steep stability for deep architectural
 fixes. That has mostly been fixed now in the snapshots, with a few
 difficult bugs to find. .10 will be out ASAP before we drop down into
 another expected dip for shared SMP caches in .11.

>
> 2) What I'm trying to do is have Squid listen to a bunch of ports,
> potentially over 100, and use a corresponding group of content
> servers at
> the back end. The content must be carefully segregated and we can't
> afford
> to let any of it get mixed up. I'm using memory caching only, no
> disk. I
> haven't found a very simple way of doing this, but in 3.2.0.2 I was
> able to
> do something like this (in this case for port 3333):
>
> http_port 127.0.0.1:3333 intercept
> acl www3333 mypport 3333
> cache_peer origin.corresponding.to.3333.com parent 80 0 originserver
> no-digest round-robin no-query name=server3333
> cache_peer_access server3333 deny !www3333
>
> Can anyone think of a more streamlined way to directly correlate an
> incoming
> port with an origin server (or group of origin servers) than this?

 myport is quite unreliable/inconsistent with intercept traffic where
 the TCP-level ports depends on the NAT software behaviour. Its much
 better to use myportname ACL to check the explicitly configured
 receiving port.

 If you find that not working, try this patch on 3.2.0.*:
   
 http://www.squid-cache.org/Versions/v3/3.2/changesets/squid-3.2-11199.patch

 With:
  http_port 127.0.0.1:3333 intercept name=3333
  acl www3333 mypportname 3333

 or, playing on the trick that name= defaults to the IP:port _text_ for
 the directive.

  http_port 127.0.0.1:3333 intercept
  acl www3333 mypportname 127.0.0.1:3333
  ...

 NOTE: Having the ports received by the same Squid will mix the objects
 in memory storage. You will find HITs on the memory cache crossing over
 between requesting ports.

 Amos
Received on Thu Jul 14 2011 - 00:15:15 MDT