A Look at Squid

Zonker gets all wrapped up in Squid, a package that handles proxy caching for Web pages and other Internet objects. He also comments on Gartner's recent recommendation that enterprises should move away from IIS.


September 26, 2001
URL:http://www.drdobbs.com/a-look-at-squid/199200738

September 2001

A Look at Squid

by Joe "Zonker" Brockmeier

Web Caching

This month, I'd like to talk about a fun package that goes by the lovely name of Squid. I've always thought "squid" was a fun word, although restaurants are apparently ashamed of the tentacled delicacy and prefer to call it "calamari."

If you haven't heard of Squid before, it's a package that handles proxy caching for Internet objects. Note that I didn't say "Web pages," because Squid can handle more than just HTML files. Squid can be used for a number of things, including saving bandwidth, handling traffic spikes, and caching sites that are occasionally unavailable. Squid can also be used for load balancing.

Essentially, the first time Squid receives a request from a browser, it acts as an intermediary and passes the request on to the server. Squid then saves a copy of the object. If no other clients request the same object, you'll see no benefit. However, if multiple clients request the object before it expires from the cache, Squid can speed up transactions and save bandwidth. If you've ever needed a document from a slow site, say one located in another country, hosted on a slow connection, or both, you can see the benefit of having a document cached. The first request may be slower than molasses, but the next request for the same document will be much faster, and the originating server's load will be lightened.

Operating Systems

Squid should run on just about any current Unix-type operating system, including Digital UNIX, IRIX, SunOS/Solaris, AIX, HP-UX, Linux, FreeBSD, NetBSD and even OS/2. For a full list, see the Squid FAQ. It's available under the GNU General Public License, and you can find the latest stable version -- or development version if you're feeling experimental -- at: http://www.squid-cache.org/Versions/v2/.

If you're running Linux, odds are your distribution comes with Squid packages. Binaries are also available for FreeBSD on x86 and Alpha, and for all of NetBSD's platforms. For Debian folks, just log in as root and type apt-get update and apt-get install squid, apt-get install squidclient, and you'll be on your way. If binary packages aren't available for your OS, you should have no problem compiling Squid as long as you have the GCC compilers.

By the way, a big kudos to Team Squid for doing a bang-up job of providing documentation. The configuration manual is nicely laid out, and available in HTML or PDF for your browsing or printing pleasure. (They don't want it mirrored yet, because it's not finished. However, they promise to release it under the GNU Free Documentation License once the docs are "stable.") Many Free Software/Open Source projects are found lacking when it comes to documentation, but Squid is nicely covered.

Configuring Squid

Squid has many configuration options -- more than a hundred of 'em, in fact, so I won't try to present them all here. However, the Squid Configuration Manual describes them all very well.

Once Squid is installed, you'll need to edit the squid.conf file. The location of this file may vary. The Squid documentation says that it will be in the /usr/local/squid/etc directory. However, the Debian packages place this file in /etc, which is the normal home for .conf files.

You do not need to edit every possible Squid configuration option to get Squid up and running. (Thank goodness!) But you will need to edit the Access Control Lists to allow your clients to use the Squid proxy. Depending on how you're using Squid, you will probably want to set up fairly strict access control so that random clients cannot access your cache.

The most basic way to perform access control is to use the http_access option. The basic syntax of the option is http_access allow|deny [!]aclname. If you want to provide access to an internal network, and deny access to anyone else, your options might look like this:

acl home src 10.0.0.0/255.0.0.0

http_access allow home

The first line sets up an Access Control List class called "home" of an internal network range of addresses. The second line allows access to that range of addresses. Since it's the final line in my access list, all other clients that don't match one of my rules will be denied.

Note that Squid's default behavior is to do the opposite of your last access line if there is no match for a client attempting to connect to Squid. For example, if the last line is set to "allow" access for a certain set of network addresses, then Squid will deny any client that doesn't match any of its rules. On the other hand, if the last line is set to "deny" access, then Squid will allow access to any client that doesn't match its rules. Clear as mud, right?

After you've made changes to your configuration, issue squid -k reconfigure so that Squid will recognize the changes.

If you've installed Squid from source or precompiled packages, it's probably set to run as the user "nobody" -- but the Squid manual frowns on this. For security reasons, you may want to invest some time in creating a Squid user and group. Then change the cache_effective_user and cache_effective_group to "squid." Once Squid is started by the root user, it will switch to "squid" after binding to the incoming network ports.

Next month, I'll spend a little more time tweaking Squid, and I'll cover some of the more useful options, including setting the cache size, timeouts, and load-balancing options.

On another topic...

As I was putting this column to bed, I came across a link to a recommendation from Gartner that enterprises should move away from IIS. This is in response to the latest worm called "Nimda" to hit IIS. While this recommendation is long overdue, there it is in black and white -- a major research firm actually saying in plain English that IIS is a horror show of intrusion opportunities. (Okay, that's my phrasing, not theirs.)

It will be interesting in the coming months to see how many enterprises move away from IIS. With an exodus away from IIS, Microsoft's .Net initiative is also likely to sputter and fail, unless the company does something unprecedented and truly makes .Net a framework that runs as well on UNIX-like operating systems as it does on Microsoft OSes. If you're running IIS servers in your organization and replacing them is not an option, please be sure to apply the necessary security patches. One reader wrote in last month to say that the patches sometimes broke other things, which can put an admin in a real pickle. If this has happened to you, and your options are either a broken system or an infected system, it's really time to consider migrating to another platform.

If you're running any Windows clients in your shop, you might also want to beware of the latest virus making the rounds. This one is a bit more evil than the last ones, as it actually erases files from the hard drive before passing itself on. This one is called the "War Vote" virus and has the subject line "Peace between America and Islam!" There's an attachment called "WTC.exe," which, when opened, apparently tries to delete all files on the hard drive. You really have to wonder how sad and pathetic a person's life has to be to spend time trying to ruin other people's work.

That's all for this month, enjoy the warm weather while it lasts and come back next month for another helping of Squid.

Resources:
Nimda Worm Shows You Can't Always Patch Fast Enough
Squid Glossary
Squid Configuration Manual
IRCache FAQ and Users Guide
Web Caching Reading List
Squid: Binary Distributions

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.