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
Received on Wed May 11 2011 - 03:49:52 MDT
This archive was generated by hypermail 2.2.0 : Thu May 12 2011 - 12:00:02 MDT