Before you even install the operating system, it's best to get an idea as to how the system will look once Squid is up and running. This will allow you to partition the disks on the machine so that their mount path will match Squid's default configuration.
Normally Squid's directory tree looks like this:
Working through each directory below /usr/local/squid in the order presented above:/
usr/
local/
squid/
bin/
cache/
etc/
src/
squid-2.0/
bin. The Squid binary and associated tools are stored in this directory. Some tools are included with the Squid source to help you manage and tune your cache server.
cache. Squid has to store cached data on disk somewhere. The path /usr/local/squid/cache is the default location. You can change the location of this directory by editing the Squid config file.
etc. Squid configuration files are stored in this directory. The most commonly changed file in here is squid.conf. We discuss the basic tags in that file in the next chapter.
src. Since you are likely to download the source code for Squid from the net, it is useful to compile the code where you can find it easily. I generally create a src directory and extract the code in there. This way I can revert to a previous version (without downloading it all over again). If you wish, you can easily keep Squid in your /usr/local/src directory, or delete it completely once you have installed the binaries.
Back to the cache directory: if you have more than one partition for the cached data, you can make subdirectories for each of the filesystems in the cache directory. Normally people name these directories cache1, cache2', cache3 and so forth. Your cache directories should be mounted somewhere like /usr/local/squid/cache/1/ and /usr/local/squid/cache/2/. If you have only one cache disk, you can simply name the directory /usr/local/squid/cache/.
In Squid-1.1 cache directories had to be identical in size. This is no longer the case, so if you are upgrading to Squid 2.0 you may be able to resize your cache partitions. To do this, however, you may have to repartition disks and reformat.
When you upgrade to the latest version of Squid, it's a good idea to keep the old working compiled source tree somewhere. If you upgrade to the latest Squid and encounter problems, simply kill Squid, change to the previous source directory and reinstall the old binaries. This is a lot faster than trying to remember which source tree you were running, downloading it, compiling it, applying local patches and then reinstalling.
Squid, like most daemon processes on Unix machines, normally runs as the user nobody and with the group nogroup.
For the maximum flexibility in allowing root and non-root users to manipulate the Squid configuration, you should make both a new user and two new groups, specifically for the Squid system, rather than using the nobody and nogroup IDs. Throughout this book we assume that you have done so, and that a group and a user have been created, (both called squid) and a second admin group, called squidadm. The squid user's primary group should be squid, and the user's home directory should be /usr/local/squid (the default squid software install destination).
When you have multiple administrators of a cache machine, it is useful to have a dedicated squidadm group, with sub-administrators added to this group. This way, you don't have to change to the root user whenever you want to make changes to the Squid config. It's possible, for users in the squidadm group to gain root access, so you shouldn't place people without root access in the squidadm group.
When the config file has been changed, a signal has to be sent to the Squid process to inform it that that config files are to be re-read. Sending signals to running processes isn't possible when the signal sender isn't the same userid as the receiver. Other config file maintainers need permission to change their user-id (either by using the 'su' command, or by logging in with another session) to either the root user or to the user Squid is running as.
In some environments cache software maintainers aren't trusted with root access, and the user nobody isn't allowed to log in. The best solution is to allow users that need to make changes to the config file access to a reload script using sudo. Sudo is available for many systems, and source code is available.
In Chapter 4 we go through the process of changing the user-id that Squid runs as, so that files Squid creates are owned by the squid user-id, and by the group squid. Binaries are owned by root, and config files are changeable by the squidadm group.