Re: [squid-users] CDN / JS 503 Service Unavailable

From: Paul Regan <me_at_paulregan.co.uk>
Date: Mon, 18 Aug 2014 08:37:54 +0100

Hello

@Eliezer - Sorry to say the acl lines made no difference. Can I use
any of the debugging options to get deeper into this?

@Amos - Maybe my British sarcasm was lost on an international audience
;) ... This config is an organic one which in parts has existed
through a number of SA and versions so thanks for the audit and we
will take a look at each suggestion.

Re performance. Only 200 (ish) users and no issues reported. Thats
not to say it can't be improved and people accept what they have as
the norm.

The only problem we have (that we know about!) is the .js caching of
this cloudflare site.

Paul

On 17 August 2014 07:03, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 15/08/2014 11:22 p.m., Paul Regan wrote:
>> Urg, thats like standing front of the class for everyone to stare!
>>
>
> If you are not able to take constructive criticisms, sysadmin is
> probably not the best ine of work for you :-)
>
> I see you seem to have found the problem. So consider these a free audit.
>
>>
>> here you go :
>>
>> cache_effective_user squid
>>
>> url_rewrite_program /usr/sbin/ufdbgclient -l /var/ufdbguard/logs
>> url_rewrite_children 64
>>
>> acl localnet src <subnet>
>> acl eu-edge-IP src <subnet>
>> acl eu-buscon-edge-IP src <subnet>
>> acl eu-inet-dmz src <subnet>
>> acl na-subnet src <subnet>
>> acl na-inet-dmz src <subnet>
>> acl na-buscon-edge-IP src <subnet>
>> acl st-buscon-vpc src <subnet>
>> acl eu-mfmgt src <subnet>
>>
>> acl SSL_ports port 443
>> acl Safe_ports port 80 # http
>> acl Safe_ports port 21 # ftp
>> acl Safe_ports port 443 # https
>> acl Safe_ports port 70 # gopher
>> acl Safe_ports port 210 # wais
>> acl Safe_ports port 1025-65535 # unregistered ports
>> acl Safe_ports port 280 # http-mgmt
>> acl Safe_ports port 488 # gss-http
>> acl Safe_ports port 591 # filemaker
>> acl Safe_ports port 777 # multiling http
>>
>> acl CONNECT method CONNECT
>>
>> hosts_file /etc/hosts
>>
>> dns_nameservers <server> <server> <server>
>>
>> http_access deny !Safe_ports
>>
>> http_access deny CONNECT !SSL_ports
>>
>> acl infrastructure src
>>
>> http_access allow localhost manager
>> http_access allow infrastructure manager
>> http_access deny manager
>>
>> acl mo-whitelist dstdomain "/etc/squid/mo-whitelist"
>> http_access allow mo-whitelist
>>
>> acl mo-blockedsites dstdomain "/etc/squid/mo-blockedsites"
>> deny_info http://<url>restricted_content_blockedsites.html mo-blockedsites
>> http_access deny mo-blockedsites
>>
>> acl mo-blockedkeywords urlpath_regex "/etc/squid/mo-blockedkeywords"
>> deny_info http://<url>restricted_content_keywords.html mo-blockedkeywords
>> http_access deny mo-blockedkeywords
>>
>> acl mo-nocache dstdomain "/etc/squid/mo-nocache"
>> no_cache deny mo-nocache
>
> The correct name for that directive is "cache", has been since Squid-2.4.
> As in, what you should have there is:
> cache deny mo-nocache
>
>
>>
>> acl mo-blockedIP src "/etc/squid/mo-blockedIP"
>> acl mo-allowURLs dstdomain src "/etc/squid/mo-allowURLs"
>>
>> http_access allow mo-blockedIP mo-allowURLs
>> http_access deny mo-blockedIP
>> deny_info http://<url>restricted_content_blockedip.html mo-blockedIP
>>
>> acl mo-allowNYIP src "/etc/squid/mo-allowNYIP"
>> http_access allow mo-allowNYIP
>>
>> http_access allow na-subnet mo-allowURLs
>> http_access deny na-subnet
>> deny_info http://<url>restricted_content_subnet.html na-subnet
>>
>> http_access allow localnet
>> http_access deny st-buscon-vpc
>> http_access allow eu-edge-IP
>> http_access allow eu-inet-dmz
>> http_access allow eu-buscon-edge-IP
>> http_access allow na-inet-dmz
>> http_access allow na-buscon-edge-IP
>> http_access allow eu-mfmgt
>>
>> acl ftp proto FTP
>> always_direct allow ftp
>>
>> acl purge method PURGE
>> http_access allow purge localhost
>> http_access deny purge
>
> Hmm.. What you have here is a pure forward-proxy configuration.
> If you need to purge things from the cache of a forward-proxy then it is
> caching badly/wrong.
>
> I know that Squid does cache some things badly, but we have taken great
> pains to ensure that those cases are conservative. The wrong cases
> shoudl all take form of dropping things which should have been kept,
> rather than storing things which should have been dropped.
>
> Are you perhase finding that you need to manually erase content
> permitted into cache by the refresh rules with "override-expire
> ignore-no-store ignore-private". Ignoring private and no-store in
> particular are very dangerous... think Captcha images, username in image
> form for embeded session display, company private information, etc.
>
>>
>> http_access allow localhost
>> http_access deny all
>>
>> http_port 8080
>>
>> cache_dir aufs /squid-cache 39322 16 256
>> cache_replacement_policy heap LFUDA
>>
>> cache_swap_low 96
>> cache_swap_high 98
>>
>> cache_mem 256 MB
>>
>> maximum_object_size 64 KB
>
> It's a little unclear why you are limiting cached objects to 64KB while
> refresh patterns also force archive and binary executable types to be
> cached. You have 40.25 GB of cache space available.
>
>> maximum_object_size_in_memory 20 KB
>>
>> quick_abort_min 0 KB
>> quick_abort_max 0 KB
>>
>> memory_pools off
>>
>
> Have you tested performance with these on recently?
>
>
> HTH
> Amos
>
Received on Mon Aug 18 2014 - 07:38:04 MDT

This archive was generated by hypermail 2.2.0 : Tue Aug 19 2014 - 12:00:05 MDT