On Tue, 10 May 2011 15:10:12 -0700, errno wrote:
I'll be doing major upgrades to a few of our old systems that are
running
older versions of squid (2.5 era). On each of these boxes, we have a
largish number of aliased virt ips. In the past it appeared that
squid
needed a separate .conf file for each ip; but we'll be moving to
squid
3.1... is it possible to get by with just one squid .conf... one
squid
instance for all the ips? Or will I still need one squid.conf per ip?
Depends on how you are using them. Probably only one config is needed.
NP: Each separate *instance* of Squid-3.1 should have its own
squid.conf file though, even if on the same box and sharing much of the
setup via "include" directive.
IIRC 2.5 could listen on a wildcard port. Which makes me a bit hesitant
to make a general answer here. You could have some non-Squid technical
or policy reasons for setting things up that way.
In general, since 2.6 one instance of Squid can listen on multiple IPs
and multiple ports for multiple different traffic types ("modes").
Converting the 2.5 concepts into 2.6+ config can be a little confusing
in some places. I've tried to make "-k parse" in the recent 3.x releases
as helpful for upgrade as possible. Though improvements are still
happening and extra checks and comments being added all the time as we
find new complexity with each upgrade.
Start with your scenario info and look through the wiki config examples
to see how Squid is configured in the post-2.6 era for those scenarios.
There are major differences (simpler config) in the reverse-proxy and
NAT interception configurations, not much in the forward-proxy.
http://wiki.squid-cache.org/ConfigExamples
Also, I'm thinking about using a db for user-authentication rather
than
files. If we had about 5 separate squid servers, on various separate
networks and separated geographically; would these servers all be
able
to use a single remote db for their authentication?
Yes. Authentication details like this are entirely up to the helper
processes/scripts used by Squid. Anything can be done, just make sure
the squid->authserver communication is more secure than the
client->Squid communication. Weakest-link failure etc.
Or does the db
effectively need to be local to the squid server, say, for
performance
and/or reliability reasons?
Performance and reliability are measures only you can judge. Comparing
resource usage on the Squid box when sharing versus network lag when
separately boxed.
For most usage I think a separate box is fine, if you have heavy
traffic between it and Squid then the closer together they are the
better. I use a dedicated DB box on local LAN shared by several Squid
and other processes at each POP. Global links have a bit too much lag
for me, but YMMV.
Ok, and I guess one other question; about moving from squid 2.5 to
squid 3.1... can I expect a fairly smooth transition between
configuration
directives? Or are there lots of deprecated or changed configuration
directives; meaning it might be best to start fresh rather and try to
start from our existing/old configs?
No and Yes. Getting off 2.5 is a fairly big jump to any of the current
versions, even 2.6, with LOTS of config changes. The config parser tries
its hardest to smooth that out, but there are still a few options which
need manual changes and more importantly knowledge of what to change
them to.
Make sure you run "squid -k parse -f squid.conf" with 3.1 beforehand
and read through the release notes for 2.6 and 3.1 (2.6 details the
2.5->2.6 changes, 3.1 details the 2.6->3.1 changes).
I and others here are generally happy to help with issues you can't
figure out yourself.
Amos
