Table of Contents for

Squid: The Definitive Guide

The Squid developers make periodic releases of the source code. Each release has a version number, such as 2.5.STABLE4. The third component starts either with STABLE or DEVEL (short for development).

As you can probably guess, the DEVEL releases tend to have newer, experimental features. They are also more likely to have bugs. Inexperienced users should not run DEVEL releases. If you choose to try a DEVEL release, and you encounter problems, please report them to the Squid maintainers.

After spending some time in the development state, the version number changes to STABLE. These releases are suitable for all users. Of course, even the stable releases may have some bugs. The higher-numbered stable versions (e.g., STABLE3, STABLE4) are likely to have fewer bugs. If you are really concerned about stability, you may want to wait for one of these later releases.

So why can’t you just copy a precompiled binary to your system and expect it to work perfectly? The primary reason is that the code needs to know about certain operating system parameters. In particular, the most important parameter is the maximum number of open file descriptors. Squid’s ./configure script (see Section 3.4) probes for these values before compiling. If you take a Squid binary built for one value and run it on a system with a different value, you may encounter problems.

Another reason is that many of Squid’s features must be enabled at compile time. If you take a binary that somebody else compiled, and it doesn’t include the code for the features that you want, you’ll need to compile your own version anyway.

Finally, note that shared libraries sometimes make it difficult to share executable files between systems. Shared libraries are loaded at runtime. This is also known as dynamic linking. Squid’s ./configure script probes your system to find out certain things about your C library functions (if they are present, if they work, etc.). Although library functions don’t usually change, it is possible that two different systems have slightly different shared C libraries. This may become a problem for Squid if the two systems are different enough.

Getting the Squid source code is really quite easy. To get it, visit the Squid home page, http://www.squid-cache.org/. The home page has links to the current stable and development releases. If you aren’t located in the United States, you can select one of the many mirror sites. The mirror sites are usually named “wwwN.CC.squid-cache.org,” where N is a number and CC is a two-letter country code. For example, www1.au.squid-cache.org is an Australian mirror site. The home page has links to the current mirror sites.

Each Squid release branch (e.g., Squid-2.5) has its own HTML page. This page has links to the source code releases and “diffs” between releases. If you are upgrading from one release to the next, you may want to download the diff file and apply the patch as described in Section 3.7. The release pages describe the new features and important changes in each version, and also have links to bugs that have been fixed.

When web access isn’t an option, you can get the source release from the ftp://ftp.squid-cache.org FTP server or one of the FTP mirror sites. For the current versions, look in the pub/squid-2/DEVEL or pub/squid-2/STABLE directories. The Squid FTP site is mirrored at many locations as well. You can use the same country-code trick to guess some mirror sites, such as ftp1.uk.squid-cache.org.

The current Squid release distributions are about 1 MB in size. After downloading the compressed tar file, you can proceed to Chapter 3.

Some Unix distributions include, or make available, precompiled Squid packages. For Linux, you can easily find Squid RPMs. Often the Squid RPM is included on Linux CD-ROMs you can buy. The FreeBSD/NetBSD/OpenBSD distributions also contain Squid in their ports and/or packages collections.

While RPMs and precompiled packages may initially save you some time, they also have some drawbacks. As I already mentioned, certain features must be enabled or disabled before you start compiling Squid. The precompiled package that you install may not have the particular feature you want. Furthermore, Squid’s ./configure script probes your operating system for certain parameters. These parameters may be configured differently on your machine on which Squid was compiled. Finally, if you want to apply a patch to Squid, you’ll either have to wait for someone to build a new RPM/package or get the source and do it yourself.

I strongly encourage you to compile Squid from the source, but the decision is yours to make.

The Concurrent Versioning System (CVS) is a nifty package that allows you to simultaneously edit and manage source code and other files. Almost every open source software project uses CVS.

You can anonymously access Squid’s CVS files (read-only) to keep your source code up to date. The nice thing about CVS is that you can easily retrieve only the changes (diffs) of your current version. Thus, it is easy to see what has changed recently. Applying the changes to your current files efficiently synchronizes your source code with the official version.

CVS uses a tree-like indexing system. The trunk of the tree is called the head branch. For Squid’s repository, this is where all new changes and features are placed. The head branch usually contains experimental and, possibly unstable, code. The stable code is typically found on other branches.

To effectively use Squid’s anonymous CVS server, you first need to understand how different versions and branches are tagged. For example, the Version 2.5 branch is named SQUID_2_5. Particular releases, which represent a snapshot in time, have longer names, such as SQUID_2_5_STABLE4. To get exactly Squid Version 2.5.STABLE4, use the SQUID_2_5_STABLE4 tag; to get the latest code on the 2.5 branch, use SQUID_2_5.

To use the Squid anonymous CVS server, you first need to set the CVSROOT environment variable:

csh% setenv CVSROOT :pserver:anoncvs@cvs.squid-cache.org:/squid

Or, for Bourne shell users:

sh$ CVSROOT=:pserver:anoncvs@cvs.squid-cache.org:/squid
sh$ export CVSROOT

You then log in to the server:

% cvs login
(Logging in to anoncvs@cvs.squid-cache.org)
CVS password:

At the prompt, enter anoncvs for the password. Now you can check out the source tree with this command:

% cvs checkout -r SQUID_2_5 -d squid-2.5 squid

The -r option specifies the revision tag to retrieve. Omitting the -r option gets you the head branch. The -d option changes the top-level directory name in which files are placed. If you omit the -d option, the top-level directory is the same as the module name. The final command-line argument (squid) is the name of the module to check out.

Once you have the Squid source tree checked out, you can run the cvs update command to update your files and synchronize with the master repository. Additional interesting commands are cvs diff, cvs log, and cvs annotate.

To learn more about CVS, visit http://www.cvshome.org/.

The Squid developers maintain a separate site, currently hosted at SourceForge, for experimental Squid features. Check it out at http://devel.squid-cache.org/. There you’ll find a number of cutting-edge development projects that haven’t yet been integrated into the official Squid code base. You can access these projects through SourceForge’s anonymous CVS server or download diff files based on the standard releases.