| Contents |
|---|
| Caching Proxy Server |
| Proxy Server Setup |
| Maintenance |
| Conclusion |
| Resources |
Caching Proxy Server
Most of the bandwidth available to the company was used up in browsing the Internet. By the very nature of their work, the hobbits found themselves visiting various sites on the WWW very often. However, most of the hobbits went to the same set of sites most of the time and therefore, there was an atrocious wastage of the bandwidth in downloading the same set of pages (and the associated images) as each hobbit individually visited a site. Sam wondered if there was a way to store the contents of these sites locally, so that precious bandwidth could be saved. This “caching” could tremendously reduce the load on the Internet connection and could provide a much better response time for content that hardly changed over time.
Sam found the solution in a caching web proxy server. And
Squid was the powerful and configurable proxy server that Sam chose.
Since Squid did not come bundled with his Linux distribution, Sam
had to download the sources and compile it himself. However,
the compilation was extremely simple and all that Sam had to
do was to follow the installation instructions included with
the software.
Proxy Server Setup
By default, Squid installed itself in the folder
“/usr/local/squid”. The configuration
file was called “squid.conf” and
was installed in the “etc” sub-folder.
The configuration file was very well documented (through
in-file comments) and Sam found it very easy to figure out
how to configure the server.
Sam let the port on the which the proxy server listened for
incoming requests, remain as the default 3128 (the
http_port parameter). Squid needs
a folder to cache the web pages, images, etc. and Sam specified
one as the value to the cache_dir parameter (along
with the total space used under this folder and the total
number of level-1 and level-2 sub-directories to create in this
folder). To allow everyone to use the proxy, he had to put in
a line saying “http_access allow all”.
He also set the value of the “cache_mgr”
parameter to “sam@internal.hobbitware.com”,
so that the users of the proxy servers would know who to contact
in case of an error or some other problem.
Squid prefers to run
as a non-root user and therefore Sam had to give the appropriate
values for the “cache_effective_user” and
the “cache_effective_group” parameters.
He chose to run Squid under his own identity (sam).
Of course he had to then ensure that his user-id had enough
quota for storing the cached objects as well as his own mails
(not to forget the big logs generated by Squid). Furthermore, the
designated cache dir had to have read-write-execute permissions
for his user id.
He set the value of the “append_domain”
parameter to “.internal.hobbitware.com”, so
that hostnames that were not fully-qualified could be resolved.
(There were a host of other parameters that would have enabled
Sam to further tweak Squid to his needs, but he did not bother
beyond this point.)
The next step was to create the folder that was designated for storing cached objects. Sam then gave the appropriate permissions (see above) to this folder. To create the cache indexing folder structure used by Squid under this folder, Sam had to run the command:
/usr/local/squid/bin/squid -z
That was it! Sam then added
“/usr/local/squid/bin/squid” to the startup
scripts so that Squid automatically started when the system
booted up. Then he asked the hobbits to configure their browsers
to use the intranet server as the “HTTP Proxy” and the
“FTP Proxy” (both on the same port 3128). The hobbits
could then immediately benefit from the immense speedups brought
about by the caching proxy server.
If Sam wished, he could have added filters to the proxy server to prohibit the hobbits from visiting “offensive” sites. However, being a liberal person valuing individual freedom, he refrained from doing anything like this.
The caching proxy server brought extremely good response times
for commonly visited sites, while freeing up the bandwidth for
the uncommon ones. The overall response times were thus improved
a lot due to the introduction of the caching proxy server.
Maintenance
Squid required a bit of maintenance from Sam from time to time. The cache access logs generated by Squid bloated rapidly and Sam had to periodically clear them. Moreover, the cache folder itself took a lot of space and Sam had to clean it up regularly.
This was a small price to pay however, for the immense benefits
that Squid brought. Together with the internal mail server, the
caching proxy server considerably reduced wasted bandwidth and
helped improve response times.
Conclusion
The caching proxy server proved to be the single biggest
saver of available bandwidth for the hobbits. It reduced
the effective browsing time for the common sites to a
minimum and surfing was no longer the drag it used to be.
Resources
The following resources proved immensely useful to Sam while setting up the proxy server:
- Squid: The caching proxy server that Sam used for his Intranet Server.
- Squid Configuration Manual: A guide that explained how to configure Squid and set it up for effective use.
- Squid FAQ: A set of documents that helped Sam out with most of the problems he had with Squid.