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
Continued on Page 2: Configuring Squid
Continued From Page 1
Rather than navigating through squid.conf, which is several
thousand lines, rename it squid.conf.bak, and create a new
squid.conf from scratch. The original squid.conf is
well-commented, and makes a good reference. We'll create a minimal
squid.conf that contains only our new directives.
If you elect to edit the original squid.conf, do not
uncomment the "default" lines when you want to keep the defaults. This
can cause Squid to behave oddly.
For Squid to even start, the server must have a fully qualified
domain name. Add this line to squid.conf:
Add the name you want your Squid server to have. It can be
different from the hostname, or the same, it doesn't matter.
The Squid User
Squid needs to run as an unprivileged user. By default, it gloms onto
nobody. But it's better to create a dedicated Squid user, and
not share nobody, which is overused, and a target for
crackers. The usual convention is the "squid" user:
# adduser --system --disabled-password --disabled-login --no-create-home --group squid
Now add the squid user to squid.conf:
cache_effective_user squid squid
You really don't want your nice Squid proxy to be abused by spammers
and other loathesome subhumans. Even when it's tucked away on your LAN
behind a firewall, it doesn't hurt anything to use these rules:
acl all src 0.0.0.0/0.0.0.0
acl localnet src 192.168.1.0/255.255.255.0
http_access deny all
http_access allow localnet
The default is port 3128:
If Squid is used on a firewall/gateway, with an internal-facing
NIC, and an external NIC, be sure to tell Squid to listen only on the
Logging options range from minimal output to torrential output,
numbered from 1-9. Trust me, it is better to start with minimal
logging, then increase the verbosity only if it's needed:
You probably want users to have a contact email, to report
problems. This address appears in error messages:
You can now save your changes, and run Squid's built-in configuration checker:
# squid -k parse
If it exits silently, you're in good shape. If it finds errors, it
helpfully tells you where:
2004/05/31 13:07:13| parseConfigFile: line 12 unrecognized: 'squidserver'
Make a habit of running squid -k parse every time you make
a change, because it will prevent many headaches.
Continued on Page 3: Running Squid
Continued From Page 2
This article was originally published on Wednesday Jun 2nd 2004
And now, the moment we've all been waiting for -- making Squid go:
# /etc/init.d/squid start
Starting proxy server: squid.
Squid tries hard to be helpful. It checks for errors at startup, and tells where they are.
A useful way to test Squid is to start it from the command line. Shut Squid down:
# squid -k shutdown
Restart it in a terminal with this command, and mounds of interesting output shall pour forth:
# squid -N -d1
2004/05/31 15:26:01| Starting Squid Cache version 2.5.STABLE5 for i386-debian-linux-gnu...
2004/05/31 15:26:01| Process ID 3807
2004/05/31 15:26:01| With 1024 file descriptors available
2004/05/31 15:26:01| Performing DNS Tests...
2004/05/31 15:26:01| Successful DNS name lookup tests...
2004/05/31 15:26:01| DNS Socket created at 0.0.0.0, port 32871, FD 4
2004/05/31 15:26:01| Adding nameserver 188.8.131.52 from /etc/resolv.conf
2004/05/31 15:26:01| Adding nameserver 184.108.40.206 from /etc/resolv.conf
The line we're most interested in seeing is
2004/05/31 15:26:02| Ready to serve requests.
Let's give it a test drive. Configure a Web browser on the Squid
server. Tell it "localhost" and "port 3128." Start Web surfing. You
should be able to cruise the Web without a care. To make sure it's
going through Squid, shut Squid down by hitting ctrl+c. Now
when you click a link, it should give an error message like "The
connection was refused when attempting to contact the proxy server."
Other clients on the LAN can connect either by the Squid server's
IP or hostname, and port. You now have a functioning http caching
server. Come back next week for more details on access control lists,
and additional Squid management tips and tricks.