Re: [squid-users] single host off/ host_header on question

From: Nick Baronian <[email protected]>
Date: Thu, 25 May 2006 10:40:01 -0400

Thanks Henrik - couple more questions if you don't mind

> Note: For a better experience I would recomment you to have Apache
> listen on port 80 as well. Just bind them to different IPs. This way you
> do not risk that port 81 to leak out to the end-user... (which it often
> does otherwise).

We are blocking incoming port 81 traffic using a firewall, so the
outside world can't access the Apache server (port 81). I have no
problems binding another IP to Apache but do you think it will give me
any other benefit?
>
> Anything in cache.log?

Nothing that stands out to me
2006/05/25 10:07:22| Starting Squid Cache version 2.5.STABLE13 for
i686-pc-linux-gnu...
2006/05/25 10:07:22| Process ID 30310
2006/05/25 10:07:22| With 1024 file descriptors available
2006/05/25 10:07:22| Performing DNS Tests...
2006/05/25 10:07:22| Successful DNS name lookup tests...
2006/05/25 10:07:22| DNS Socket created at 0.0.0.0, port 32776, FD 5
2006/05/25 10:07:22| Adding nameserver 168.192.40.41 from /etc/resolv.conf
2006/05/25 10:07:22| Adding nameserver 168.192.43.41 from /etc/resolv.conf
2006/05/25 10:07:22| Unlinkd pipe opened on FD 10
2006/05/25 10:07:22| Swap maxSize 8388608 KB, estimated 645277 objects
2006/05/25 10:07:22| Target number of buckets: 32263
2006/05/25 10:07:22| Using 32768 Store buckets
2006/05/25 10:07:22| Max Mem size: 524288 KB
2006/05/25 10:07:22| Max Swap size: 8388608 KB
2006/05/25 10:07:22| Rebuilding storage in /u01/squid (DIRTY)
2006/05/25 10:07:22| Using Least Load store dir selection
2006/05/25 10:07:22| Set Current Directory to /u01/squidlogs
2006/05/25 10:07:22| Loaded Icons.
2006/05/25 10:07:22| Accepting HTTP connections at 0.0.0.0, port 80, FD 11.
2006/05/25 10:07:22| Accepting ICP messages at 0.0.0.0, port 3130, FD 12.
2006/05/25 10:07:22| WCCP Disabled.
2006/05/25 10:07:22| Ready to serve requests.
2006/05/25 10:07:22| Done scanning /u01/squid (0 entries)
2006/05/25 10:07:22| Finished rebuilding storage from disk.
2006/05/25 10:07:22| 0 Entries scanned
2006/05/25 10:07:22| 0 Invalid entries.
2006/05/25 10:07:22| 0 With invalid flags.
2006/05/25 10:07:22| 0 Objects loaded.
2006/05/25 10:07:22| 0 Objects expired.
2006/05/25 10:07:22| 0 Objects cancelled.
2006/05/25 10:07:22| 0 Duplicate URLs purged.
2006/05/25 10:07:22| 0 Swapfile clashes avoided.
2006/05/25 10:07:22| Took 0.3 seconds ( 0.0 objects/sec).
2006/05/25 10:07:22| Beginning Validation Procedure
2006/05/25 10:07:22| Completed Validation Procedure
2006/05/25 10:07:22| Validated 0 Entries
2006/05/25 10:07:22| store_swap_size = 0k
2006/05/25 10:07:23| storeLateRelease: released 0 objects

> Squid doesn't really care where the DNS is pointing.. unless you have
> something relying on it such as the dst acl...
> the dst acl looks at the URL, not where the request is forwarded..

So since my dst acl points to specific IP's not domains it doesn't
matter for me, correct?
acl dest_addy dst localhost 168.192.2.3 10.10.21.2

> Only if you set "httpd_accel_single_host on". With this off all the
> httpd_accel_* directives does is to reconstruct the hostname and port
> part of the URL from the request..

So since single_host is off for me all requests replace the URL with
my httpd_accel_* info. I thought this was the case but I wasn't sure.
 My thinking on why I was getting Access Denied/TCP_DENIED was because
we block incoming requests to port 81 on a firewall and requests could
possibly be going to my other 3 webservers, so the request would be
going out my gateway and then back in and getting denied. I had tried
changing my dst acl to point to my non-routable DMZ address but this
didn't change things, thinking this would force Squid to only get the
uncached requests from this URL. But the info still needs to be in
the host file for pages to come up for me. So thinking that Squid is
requesting the page from the outside and then going back in I changed
Apache to run on a port that is open on our firewall and this didn't
help either.

Thanks again,
Nick Baronian
Received on Thu May 25 2006 - 08:40:04 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:02 MDT