> I am not sure if I am using both my hardware resources and my squid.conf > properly, especially with regards to: cache_dir ufs /usr/squidcache 8192 16 > 256 In terms of cache_dir, it looks fine. (assuming you're not using veritas volume manager on the partition from which you're running your squid cache.) I have some issues with other portions of squid.conf, but they're noted below. > Many apologies for such a long email, but I have done my best to be as > informative as possible. Quite honestly better than the latter. I personally prefer too much information. :-) > acl all src 192.9.65.0/255.255.255.0 192.9.64.0/255.255.255.0 > acl all src 10.90.0.0-10.95.0.0/255.255.0.0 > 172.16.0.0-172.19.0.0/255.255.0.0 192.168.0.0/255.255.0.0 No offense at all, but this is hideous. "acl all src" needs to be exactly that. Something that pertains to everything. In fact, the default acl for "all" is really what should be left there. ie: acl all src 0.0.0.0/255.255.255.255 This accounts for "everything". The idea is that you deny anything that matches the "all" acl entry. The deny statement goes at the very bottom of your ACL. It states: If you haven't matched any of my allow acl's, you are denied access to my cache. As an example, consider the following: acl one_nine_two src 192.9.64.0/23 acl ten_ninety src 10.90.0.0/16 acl ten_ninety_five src 10.95.0.0/16 acl one_seven_two src 172.16.0.0/14 acl one_six_eight src 192.168.0.0/16 acl all src 0.0.0.0/255.255.255.255 http_access allow one_nine_two http_access allow ten_ninety http_access allow ten_ninety_five http_access allow one_seven_two http_access allow one_six_eight http_access deny all Concatenating all of your subnets into one acl makes for a real trouble-shooting nightmare. Plus, seeing the "http_access deny all" missing from any squid config really makes me cringe. I personally don't want people to be able to anonymously access my squid proxy (I don't care what kind of firewalls or physical securities are in place). Cisco routers, for example, have an assumed "deny all" at the botton of their acls (it's not over-rideable either) to serve the same purpose. The only other issue I have, that's worth noting, deals with my history and experience with solaris. I have multiple vendors that have written products that run on solaris. Three of them (names are not important here) have complained countless times about inconsistencies with how solaris terminates tcp sessions. At a mere glance of the problem, I've seen sockets opened for connections in solaris and those specific sockets remained open until the duration of the machines uptime. The sympton suggests that solaris or the application are not terminating the tcp connection properly (fin, fin-ack, etc). Regardless, I've seen a few vendors that have complained about this and wanted to warn you of that. Speaking of, anyone en-list experienced anything like this with squid on Solaris? I've a couple sparc machines here at work and wouldn't mind tinkering with squid if I found it to be worth my while. I guess that's enough for today. :-) Tim Rainier
