Re: [squid-users] config trouble moving to squid 3.1

On 1/03/2012 1:16 a.m., Preller, Markus wrote:
> Hi,
> we've been running squid 2.5 and apache 2.x on one box for years now without a problem.
>
> Server IP: 192.168.10.21
> DNS-entry: proxy.mydom.de
>
> Service IP: 192.168.10.22
> DNS-entry: cms.mydom.de
>
> Squid and Apache are set up to only bind to 192.168.10.22.
>
> So squid was set up as a reverse proxy/accelerator using the following
> parameters in squid.conf:
> httpd_port 192.168.10.22:80
> httpd_accel_host virtual # we're using apache name-based vhosts
> httpd_accel_port 81 # apache listens on 192.168.10.22:81
> httpd_accel_with_proxy on
> httpd_accel_uses_host_header on
>
> In httpd.conf you find:
> Listen 192.168.10.22:81
> NameVirtualHost 192.168.10.22:81
>
> and dozens of
>
> <VirtualHost 192.168.10.22:81>
> ServerName www.anyname.dom
> ...
> ...
> </VirtualHost>
>
> Our DNS defines cms.mydom.de as an alias for each ServerName used in a VirtualHost entry.
> Now I'm trying to build the same setup with squid 3.1 on a CentOS 6.2 system while leaving
> the apache config untouched.
>
> So I replaced the lines from squid 2.5
>
> ...
> httpd_port 192.168.10.22:80
> httpd_accel_*
> ...
>
> with
>
> ...
> http_port 192.168.10.22:80 accel defaultsite=192.168.10.22:81 vhost

I think you need to use "defaultsite=cms.mydom.de" instead of that
IP:port. The rest is correct.

> ...
>
> which gives me a TCP_MISS/403 in squid access.log. When I compare
> the logs from squid 2.5 with squid 3.1 I can see that the GET references
> differ between the logs:
>
> in the 2.5 logs I find: ... GET http:// cms.mydom.de:81/...
> in the 3.1 logs I find: ... GET http:// cms.mydom.de/...
>
> Is there something missing in my squid 3.1 config?
> Where is my fault? Your help would be appreciated.
>

You did not mention any cache_peer settings telling Squid where Apache
is that would result in a 403.

This config tutorial should help you with the new setup:
http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting

NP: Squid will pass that clients URL straight through to Apache. As you
noticed already the URL has port 80 not 81 in it. This is so Apache can
see the public details and use them for seamless creation of any embeded
URLs it may need to send back the client. If your Apache has trouble
with the real URL, you can use "vport=81" on the Squid http_port line to
get the old Squid behaviour happening again. Long-term though it is best
to fix Apache up to work with the real public URL.

Amos
Received on Wed Feb 29 2012 - 13:04:51 MST