Squid Tips and Tricks

##Enable PURGE method for squidclient

By default, the PURGE method is denied with squid, therefore, you cannot use squidclient to purge the cache for a particular page.

The solution to this requires a change in your squid.conf file to allow the PURGE method from localhost.

At my site, squid is installed at /usr/local/squid and the server listens on ports 80 and 8080 instead of the default 3128. You can see what ports squid is listening on with the following:

# grep "^http_port" /usr/local/squid/etc/squid.conf
http_port proxy_ip_addr:80
http_port proxy_ip_addr:8080

First, we need to add a couple of acl‘s to the configuration file, one for localhost (if you haven’t defined it already), and one for the PURGE method itself.

# vi /usr/local/squid/etc/squid.conf
# egrep "^(acl PUR|acl local)" /usr/local/squid/etc/squid.conf
acl localhost src 127.0.0.1
acl PURGE method PURGE

Now, we can add our http_access definitions to allow use of the PURGE method when requested by localhost only. Make sure you add both of these entries before your global http_access deny all entry.

# vi /usr/local/squid/etc/squid.conf
# grep "^http_access.*PURGE" /usr/local/squid/etc/squid.conf
http_access allow PURGE localhost
http_access deny PURGE

Now, we’re ready to ask squid to reload it’s configuration file.

# /etc/init.d/squid reload

No errors? Cool. Now we can attempt to PURGE our cache for a particular page…

# /usr/local/squid/bin/squidclient -h proxy_ip_addr -p 80 -m PURGE http://www.somewhere.com/somepage.html

If the object is in the cache, you should receive a HTTP/1.0 200 OK message. If the object is not in the cache, you’ll be greeted by a HTTP/1.0 404 Not Found message.

##Beware oversized Squid logfiles

We recently had an issue after moving from syslog to syslog-ng on some of our proxy servers. The syslog-ng rpm placed an include file into /etc/logrotate.d alongside the existing entry for syslog (as the syslog rpm had not been removed, just disabled via chkconfig).

The two include files both had entries for /var/log/messages (and others). These duplicate entries caused logrotate to barf (as would have been evident from a logrotate -f /etc/logrotate.conf). Therefore, our squid access, cache and store logs were not being rotated daily.

The first indication we had of there being problems was when squid stopped listening on one of our proxies. A bit of digging around in the logs showed that squid child processes were exiting due to signal 25.

ls -lhrt /usr/local/squid/var/logs…. There’s the problem, the cache and access logs had hit the 2.0gb limit. Yep, the logrotate had been failing for the past couple of days. Fixed up logrotate by removing the old syslog include file from /etc/logrotate.d, ran logrotate -f /etc/logrotate.conf (we have a squid include whose postrotate rule executes a squid -k rotate). Just to make sure all is well, I restarted squid with /etc/init.d/squid restart, then verified that squid was listening (netstat -anl | grep $SQUIDPORTHERE). Testing confirmed that all was well.

Morale to this story? Think of possible side effects when changing the logging functionality of your servers!