Squid_ The Definitive Guide - Duane Wessels [35]
Rotating the Log Files
Squid writes to a number of log files unless you disable them in squid.conf. You must periodically rotate the log files to prevent them from consuming too much disk space. Squid places a lot of importance on log files and exits with an error message when it can't write to them. To keep disk space consumption under control, use the following command in a cron job:
% squid -k rotate
For example, this crontab entry rotates the logs every 24 hours, at 4 A.M.:
0 4 * * * /usr/local/squid/sbin/squid -k rotate
This command does two things. First, it closes the currently open log files. Then, it renames the cache.log, store.log, and access.log files by appending a numeric extension. For example, cache.log becomes cache.log.0, cache.log.0 becomes cache.log.1, and so on, up to the value of the logfile_rotate option.
Squid keeps only the last logfile_rotate versions of each log file. The older versions are simply removed during the renaming process. If you want to keep more copies, you need to increase the logfile_rotate limit or write some custom scripts that move the log files to a different location.
See Section 13.7 for additional information about rotating log files.
Exercises
Use Squid's -s option and verify that its messages are saved by your syslog daemon.
Run squid -X -d9, and examine some of the debugging messages.
Write a shell script that stops Squid but doesn't exit until all Squid processes exit.
Play with squid -k rotate. What happens if you have tail -f cache.log running when you rotate the log files?
Chapter 6. All About Access Controls
Access controls are the most important part of your Squid configuration file. You'll use them to grant access to your authorized users and to keep out the bad guys. You can use them to restrict, or prevent access to, certain material; to control request rewriting; to route requests through a hierarchy; and to support different qualities of service.
Access controls are built from two different components. First, you define a number of access control list (ACL) elements. These elements refer to specific aspects of client requests, such as IP addresses, URL hostnames, request methods, and origin server port numbers. After defining the necessary elements, you combine them into a number of access list rules. The rules apply to particular services or operations within Squid. For example, the http_access rules are applied to incoming HTTP requests. I cover the access control elements first, and then the rules later in this chapter.
Access Control Elements
ACL elements are the building blocks of Squid's access control implementation. These are how you specify things such as IP addresses, port numbers, hostnames, and URL patterns. Each ACL element has a name, which you refer to when writing the access list rules. The basic syntax of an ACL element is as follows:
acl name type value1 value2 ...
For example:
acl Workstations src 10.0.0.0/16
In most cases, you can list multiple values for one ACL element. You can also have multiple acl lines with the same name. For example, the following two configurations are equivalent:
acl Http_ports port 80 8000 8080
acl Http_ports port 80
acl Http_ports port 8000
acl Http_ports port 8080
A Few Base ACL Types
Squid has approximately 25 different ACL types, some of which have a common base type. For example, both src and dst ACLs use IP addresses as their base type. To avoid being redundant, I'll cover the base types first and then describe each type of ACL in the following sections.
IP addresses
Used by: src, dst, myip
Squid has a powerful syntax for specifying IP addresses in ACLs. You can write addresses as subnets, address ranges, and domain names. Squid supports both "dotted quad" and CIDR prefix[1] subnet specifications. In addition, if you omit a netmask, Squid calculates the appropriate netmask for you. For example, each group in the next example