Anyone got any other ideas on why this isn't delving into the cache
when the backend server is down?
On Tue, Mar 22, 2011 at 10:37 AM, Morgan Storey <me_at_morganstorey.com> wrote:
> Thanks Amos I tried your suggestions, still no good when the webserver
> is offline. I get only a single line in the cache.log "2011/03/22
> 10:28:50| TCP connection to myAccel (10.0.0.18:80) failed"
> I have put the squid.conf in the email to make corrections easier (I
> have tried that offline mode on but it doesn't seem to work);
>
> dns_nameservers 10.0.0.2 10.0.0.1
>
> cache_dir ufs d:/cache 8000 100 256
> cache_mem 512 MB
> maximum_object_size_in_memory 10240 KB
>
> access_log e:/squidlogs/access.log squid
> cache_log e:/squidlogs/cache.log
> cache_store_log e:/squidlogs/store.log
> logfile_rotate 10
>
>
> acl all src all
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
> acl localnet src all # RFC1918 possible internal network
>
> acl SSL_ports port 443
> acl Safe_ports port 80 # http
> acl Safe_ports port 443 # https
> acl CONNECT method CONNECT
>
> ##############################################################
>
> http_port 80 accel defaultsite=www.site.com vhost
>
> # proxy icp
> # hostname type port port options
> # -------------------- -------- ----- ----- -----------
> cache_peer 10.0.0.18 parent 80 0 no-query originserver name=myAccel
>
>
> acl our_sites dstdomain www.site.com
> forwarded_for on
>
> http_access allow our_sites
> cache_peer_access myAccel allow our_sites
> cache_peer_access myAccel deny all
>
> cache_effective_group proxy
>
> ##############################################################
>
> #
> #Allow ICP queries from All
> icp_access allow all
>
> # TAG: max_stale time-units
> # This option puts an upper limit on how stale content Squid
> # will serve from the cache if cache validation fails.
> #
> #Default:
> max_stale 1 week
>
> #Suggested default:
> #refresh_pattern ^ftp: 1440 20% 10080
> #refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern -i (/umbraco/|\?) 0 0% 0
> refresh_pattern . 120 20% 4320
>
> acl QUERY urlpath_regex umbraco \?
> acl POST method POST
> no_cache deny QUERY
> no_cache deny POST
>
> # TIMEOUTS
> forward_timeout 15 seconds
>
> # Do not tell the world that which squid version we're running
> httpd_suppress_version_string on
>
> # Remove the Caching Control header for upstream servers
> header_access Cache-Control deny all
>
> cache_mgr someone_at_somewhere.com
>
> #offline_mode on
>
>
> On Mon, Mar 21, 2011 at 10:26 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 21/03/11 21:44, Morgan Storey wrote:
>
>> Some notes on those configs:
>>
>> (squid1)
>> * You can deny CONNECT entirely. It should never happen to a reverse-proxy.
>> They get native HTTPS connections to their https_port.
>>
>> * Your reverse-proxy settings, for cache_peer and the related http_access
>> rule MUST be above the default forward-proxy rules. Since this appears to be
>> a pure reverse-proxy you can drop the default config file http_access lines
>> entirely.
>> NP: do that and I believe your Squid will stop needing to wait for DNS. It
>> only uses it now to check the localnet ACL :)
>>
>> * header_access is not a very safe thing to do for Squid-2. It affects both
>> the client request headers passed to your main server AND the reply headers
>> destined for the visitor.
>> refresh_pattern flag "reload-into-ims" is much safer and helps avoid the
>> forced reload clients sometimes send.
>>
>> (squid2)
>> * you are missing the http_access reverse-proxy settings. squid1 was
>> better.
>>
>>
>> Amos
>> --
>> Please be using
>> Current Stable Squid 2.7.STABLE9 or 3.1.11
>> Beta testers wanted for 3.2.0.5
>>
>
Received on Tue Mar 29 2011 - 07:41:51 MDT
This archive was generated by hypermail 2.2.0 : Tue Mar 29 2011 - 12:00:02 MDT