Simple Configuration Tips Put Squid on the Menu
If you need to get a handle on your bandwidth with Web caching, but several thousand lines of configuration files make you queasy, here's a step-by-step guide to making Squid more appetizing.
If you've been running a network for any length of time, you know that merely connecting to the Internet, then sitting back and having fun, is simply not in the cards for us hardworking netadmins. No, for all those bits must not be allowed to flow unimpeded, but must be monitored, filtered, diverted, accepted, rejected, sniffed, throttled, chained, and logged. It's a wonder that any of them survive.
The Squid http proxy performs a large number of useful tasks. Today we'll look at http proxying and access controls. Squid's primary duty is to cache http requests. A typical LAN has much fatter internal pipes than external, so the bottleneck is usually your shared Internet connection. Caching Web pages speeds things up considerably, and conserves bandwidth. And you, the godlike admin, can restrict access to specific Web sites, networks, and users, as the whim ... I mean necessity ... dictates.
This article is aimed at Squids that are installed from RPM or .deb. If you build it from sources, be sure to read all the relevant READMEs and INSTALLs, because the steps are different. You'll have to create some files, and pay special attention to file permissions.
Squid runs on any Linux/Unix, and will even run on Windows NT/2000, with a little help from Cygwin. Though it's a mystery to me why anyone would want to do that. A Squid server needs a lot of RAM and a lot of storage. CPU speed is not all that important: A 500mHz processor will do nicely. Fast I/O is where you want to spend your money. Nice fast SCSI drives and lots of RAM will give the fastest performance.
As a very general rule, allow 32 megabytes RAM for each gigabyte of disk space. So a 30-gigabyte disk cache could be paired with 960 megabytes of memory. Calculating how much you really need comes from experience, because it depends on how much traffic your users generate. Most admins store 1-2 weeks of traffic. Keep track of your HTTP bandwidth use, and this will tell you how much you need.
Web caching and Squid logs eat up vast amounts of disk space. So you definitely want /var on its own partition, just in case it goes nuts and fills up uncontrollably and explodes. It's not necessary to use a journaling filesystem for the Web cache, because this is transient data. Plain ol' ext2 works nice and fast, especially when it's mounted with the noatime attribute, which this /etc/fstab entry demonstrates:
/dev/hda3 /var ext2 defaults,noatime