The first high-performance proxy-cache program was developed as part of the Harvest project. The Harvest project was an NSF (?check this info for accuracy?) funded project to create a web indexing system. Part of this project included writing a high-performance cache daemon, or cached (pronounced "Cache-Dee") to speed the re-indexing of pages. Once the project was completed the cached source code was used as the basis for many commercial cache servers, as the source was freely available. Many of the cached developers moved on to or formed companies that developed commercial cache software.
I remember first installing cached: I was boggled at the number of options in the configuration file. I tried working through the options from top to bottom, deciding which to change and which to leave. I had no idea what they all meant. As I worked though the file, I figured more and more options out, though others remained mysteries.
After a lot of changes I tried to start cached, and had no luck. It spat out loads of errors, and I couldn't connect to the machine with my web browser at all. I had no idea what the real problem was - and I changed more and more options with time. This simply buried the real problem beneath hundreds of other possible problems.
Though Squid is now easier to install, the lessons I learned then are still relevant. The default configuration file is probably right for 90% of installations - once you have Squid running, you should change the configuration file one option at a time. Don't get over-ambitious in your changes quite yet! Leave things like refresh rules until you have experimented with the basic options - what port you want your to accept requests on, what user to run as, and where to keep cached pages on your drives.
So that you can get Squid running, this chapter works through the basic Squid options, giving you background information and introducing you to some of the basic concepts. In later chapters you'll move on to more advanced topics.
The Squid config file is not arranged in the order as this book. The config file also does not progress from basic to advanced config options in any specific order, but instead consists of related sections, with all hierarchy settings in a specific section of the file, all access controls in another and so forth.
To make changes detailed in this chapter you are going to have to skip around in the config file a bit. It's probably easiest to simply search for the options discussed in each subsection of this chapter, but if you have some time it will be best if you read through the config file, so that you have an idea of how sections fit together.
The chapter also points out options that may have to be changed on the other 10% of machines. If you have a firewall, for example, you will almost certainly have to configure Squid differently to someone that doesn't.
I recommend that you put all Squid configuration files and startup scripts under revision control. If you are like me, you love to play with new software. You change an option, get the program to re-read the configuration file, and see what difference it makes. By repeating this process, I learn what each option does, and at the same time I gain experience, and discover why the program is written the way it is. Quite often configuration files make no sense until you discover the overall structure of the underlying program.
The best way for you to understand each of the options in the Squid config file (and to understand Squid itself) is to experiment with the multitude of options. At some stage in the experimentation stage, you will find that you break something. It's useful to be able to revert to a previous version (or simply to be reminded what changes you have made).
Many readers will already have used a Revision Control System. The RCS
system is included with many Unix systems, and source is freely
available. For the few that haven't used RCS, however, it's worth
including some pointers to some manual pages:
ci(1) #!/bin/sh
One of the wonders of Unix is the ability to create scripts which reduce
the number of commands that you have to type to get something done. I have
a short script on all the machines I maintain called rvi. Using
rvi instead of vi allows me to use one command to edit files
under RCS (as opposed to the customary four). Put this file somewhere in
your path and make it executable chmod +x rvi. You can then simply
use a command like rvi squid.conf to edit files that are under
revision control. This is a lot quicker than running each of the co,
rcsdiff and ci commands.
co(1)
rcs(1)
rcsdiff(1)
rlog(1)
co -l $1
$VISUAL $1
rcsdiff -u $1
ci -u $1