Mike Raath wrote:
proxy.pac may be an option, but if possible I'd like to keep the zero
configuration element of a transparent proxy.
Amos - I'm not quite sure how to integrate your suggestion with what I
had. Bear in mind that the IP address specified in the request could
be anything from localhost (developer's own box although in this case
it won't hit the proxy), development server, test server or live
server. Defining a cache-peer as you have it there assumes everyone
will be looking at the same box at the same time, which would mean I
could define the entry in the DNS forwarding, unless I've
misunderstood you.
I can't do that simply because during a normal dev sprint developers
would be pointing at a dev server, testers at a test server, and
product owners/others would be looking at live.
Bear in mind that in almost all cases traffic will be normal browsing
traffic, and caching is exactly what I want. But in this specific case
I need to be able to bypass not only the cache, but also the proxy.
And everyone in the office has a laptop which means that they
regularly connect to different APs, so setting proxy information
manually would be a major pain.
The cache_peer_access options in Squid can be used with any of the
request ACL, and cache_peer can have multiple entries.
As long as you can define explicitly who is meant to be going where it
can be written as ACL in squid.conf and the same request from different
people routed anywhere.
May take a little getting your head around the possibilities, but once
you do you will find it an easier way to run things.
Arbitrarily complex:
ie
user B it goes to server B no matter the source
machines in subnet A aways go to server A
user C from machine D goes to Server B
etc, etc.
add on top external ACL feature, which can pull settings from a database
or arbitrary information source. And you have a real-time plug-n-play
access system for any number of source servers.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
