Even if it really is a production machine, it's running Solaris Express Developer Edition 01/08. I decided to deploy a web proxy to save and control access to the network bandwith of my office and started looking for Sun Microsystem's solution: Sun Java System Web Proxy Server. Before downloading, I started to read the official documentation at Sun documentation center when I discovered that Solaris Express Developer Edition 01/08 ships with Squid.
I decided to spare a download and (yet another) setup giving Squid a try. Starting and configuring the service was really easy. The service is disabled by default and can be started with the SMF command:
# svcadm enable svc:/network/http:squid
Before doing that, you must configure Squid. I'm now just testing with the default values but at the very least you must grant access to the client machines. Squid configuration file is not complicated and, with the help of some googling (for example, this old O'Reilly article), I just ended up defining an ACL and granting access to it. I opened Squid configuration file, /etc/squid/squid.conf, with my favorite editor (vi) and added the following lines:
acl our_networks src 192.168.0.0/24
http_access allow our_networks
just before the last "deny all the rest" directive,
http_access deny all
The first line just defines an acl for my entire office network, which happens to be 192.168.0.0/24 and the second line grants HTTP access to all clients on that range. I then started Squid and tested that it worked examining its access log file, /var/squid/logs/access.log. If you see lines like this:
1208657695.111 239 192.168.0.128 TCP_MISS/304 255 GET http://www-cdn.sun.com/share/metrics/metrics_group1.js - DIRECT/87.248.220.12 text/javascript
it means that Squid is serving an unmodified page from its cache. The HTTP 304 status code indicates indeed that a "Not modified" page has been requested.
No comments:
Post a Comment