Edit Rename Changes History Upload Download Back to Top

Configuring Squid for OpenSkills

We are currently using Squid version 2.5.9 as shipped with Debian sarge.

We use Squid to provide a number of services, each of which is described below, aling with the configuration we have used.

Server Acceleration

Many of the responses made by OpenSkills applications hardly change at all over time (e.g. home pages). Others are unique (e.g. a detail editor page). As a server accelerator, Squid caches the responses that change rarely and directly responds to requests for them without bothering the server. Using http headers, we can ask Squid to used cached responses anywhere from never, to always. Search results from the SkillsBase, for example, are cached for a few minites. The net effect is that the service seems to go faster for the user sat in front of a web browser.

The httpd-accelerator mode FAQ is a good initial read. The following configuration file works as is, though is not useful in production because the access control is nil:

#We want to listen on port 8000
http_port 8000

#Accelerate the SkillsBase which is running on 192.168.1.10:10080
httpd_accel_host 192.168.1.10
httpd_accel_port 10080

#No access control at all.  Let anything through.
acl all src 0.0.0.0/0.0.0.0
http_access allow all

Redirecting

Although the above works great if there is a single origin server (e.g. the SkillsBase server), it does not handle the situation where there are many origin servers.

OpenSkills uses a host name for each service, e.g. skillsbase.openskills.org or mms.openskills.org. All these names map onto one IP address; that of the Squid server. The Squid instance running on that server then has to (in addition to it's caching duties) redirect each request to the correct origin server. For example, the SkillsBase origin server actually runs (at the time of writing) on a host called brock.openskills.org, so a request to skillsbase.openskills.org will arrive at the Squid server. If the response has not been cached, the request URL must be rewritten so the request gets passed onto brock.openskills.org.

Configuring Squid to achieve this is described in a squid HowTo. In sort, we have to nominate a redirector program to take the URL as received by Squid and change it to be the URL of the origin server. We use a small Ruby script.

We have to tell Squid that the rewritten URL should *not* change the host header, but *should* base the rewrite on that header. So, we change the accelerate part of the above Squid.conf file to look like:

#Accelerate the SkillsBase
httpd_accel_host virtual
httpd_accel_port 0
redirect_program /etc/squid/OSkRedirector.rb
redirect_rewrites_host_header off
httpd_accel_uses_host_header on

The Ruby script looks like this (the logging code is removed in production):

#!/usr/bin/env ruby
logFileName = '/var/log/squid/OSkRedirector.log'
log = File.new(logFileName, "a")
log.printf "Starting redirector\n"
log.flush
while true
 log.printf "Waiting for Squid\n"
 log.flush
 source = gets 
 target = source
 target.sub(/skillsbase.openskills.org[^\/]*(.*)/,'brock.openskills.org:80\1')
 target.sub(/mms.openskills.org[^\/]*(.*)/,'mico.openskills.org:80\1')
 log.printf "%s -> %s\n", source, target
 log.flush
 puts target
 $stdout.flush
end
log.close

Authentication

In fact, we do not use the Squid authentication features with Squid 2.5. See below for the explanation. Authentication is currently done by the origin servers.

The next step is to have Squid authenticate requests to member-only pages. This should just requre the addition of the following lines to the squid.conf file:

# Authenticate requests to Member realm
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/ncsa.pwd
auth_param basic children 5
auth_param basic realm OpenSkills Member Authentication
auth_param basic credentialsttl 30 seconds

acl all src 0.0.0.0/0.0.0.0
acl SourcePort myport 8000
acl Member proxy_auth REQUIRED
acl MemberURL urlpath_regex ^/Member/.*
acl SkillsBase dstdomain skillsbase.openskills.org
hxxp_access deny SkillsBase MemberURL !Member
hxxp_access allow SkillsBase SourcePort
hxxp_access deny all

The essence of this is that the program ncsa_auth is to be called if any authentication is needed. The acl Member represents an authenticated member, and the line "hxxp_access deny SkillsBase MemberURL !Member" means deny any requests that try to go to the MemberURLs (^/Member/.*) at the SkillsBase (skillsbase.openskills.org) that are not Members (!Member).

The line "hxxp_access allow SkillsBase SourcePort" allows all other access to the SkillsBase to go through. The last line blocks all other access.

It seems that the above correctly defines what we need, but unfortulately Squid reports in it's logs that:

"authentication not applicable on accelera ted requests"

Squid 3.x will support this (per the change log for Squid 3 - the wording of which I understand only now), but Squid 2.x will not. Oh, dear.

It seems that there is a kind of ready-made change that can be made in the C source code of Squid. By defining AUTH_ON_ACCELERATION=1 and recompiling Squid, the acceleration might work. The fact that this would involve moving out of the SOE support envelope and the fact that this only might work mean that we will be giving this a miss.


Edit Rename Changes History Upload Download Back to Top