On 1/27/06, Michael Pye <michael@ulimit.org> wrote:
> We have a very similar setup to what you describe. Squid acting
> as a reverse proxy or http accelerator.
>
> We use regular dns on the squid servers but setup an /etc/hosts file
> to direct squid to the backend origin web servers for each vhost. We also
> use a software load balancer as we have multiple backend servers that each
> vhost can be served from. (http://www.inlab.de/balance) You could also
> use a redirector.
>
> Using name based vhosts is fine as long as you set:
> httpd_accel_uses_host_header on
>
> To prevent proxying for sites other than your own you use a dst acl, ie:
> acl ourips dst 127.0.0.0/8
> http_access deny !ourips
> http_access allow ourips
>
> where ourips lists the ips of your backend servers or where your
> balance/redirector is.
>
> Squid 3 has an extra feature of directing requests to your origin servers
> using the cache_peer origin directive but this is not advisable to put
> into production yet. Theres no need for balance or a redirector if you
> only have one web server per vhost.
>
> Squid is very flexible as a reverse proxy. The only issue you may have
> is using wildcard domains, as you cannot do this in /etc/hosts.
>
> --
> Michael
Michael, thanks for your advice. After thinking about the problem a
little more, I came to the same conclusions, with one addition -
utilizing Squid's internal DNS resolver along with a private DNS
server to provide the "true" ip's for the servers. I'm working on a
proof-of-concept system right now.
Thanks again,
Jeremy
Received on Fri Jan 27 2006 - 11:59:29 MST
This archive was generated by hypermail pre-2.1.9 : Wed Feb 01 2006 - 12:00:01 MST