On Sat, 28 Aug 2004, Elsen Marc wrote:
There's no real notion of upgrading paths/mechanisms in SQUID distributions. In this case : start from a squid.conf.default coming with the distribution and 'merge' your requirements in there.
Do not simply use your 2.4 squid.conf.
There is and upgrade path. See the release notes.
If one pays attention to the release notes the intention is that one should be able to upgrade their old configuration without too much effort. The backwards compatible changes is quite rare and ther is only small modifications required to squid.conf when upgrading. When upgrading from 2.4 to 2.5 the most noticeable configuration changes is a new syntax for authentication directives.
Making sure the old configuration is cleaned from the documentation comments before the upgrade is a good advice. Makes it considerably easier to see the actual configuration.
grep "^ *[a-z]" squid.conf >squid.conf.clean
then annotate squid.conf.clean documenting why the configuration looks the way it does. When this is done move squid.conf.clean to squid.conf and then do the upgrade of Squid.
When or while upgrading Squid remember to update squid.conf according to the release notes and the new documentation in squid.conf.default, verify syntax with "squid -k parse".
When "squid -k parse" finds nothing to complain about, restart Squid to switch to the new version. Keep an eye on cache.log for errors.
You can keep the existing cache dirs however.
Yep.
Completely orthogonalizing the new installation could be achieved by specifying another installation prefix for the 2.5 tree for instance.
Indeed.
Regards Henrik
