Our servers are kept in warranty/hardware support so that hardware failures can be quickly replaced with minimum effect on the service. The webcache has had new hardware purchased for it to replace hardware going out of warranty. I’ve been preparing the new hardware installation for deployment. This includes working out which configuration from the existing service is needed and what is historical that can be dropped. The new software is also a newer operating system and proxy software so any configuration syntax has to be checked in case it’s deprecated or replaced.
The existing webcache configuration dates back to when traffic to the ja.net network was costed on usage, and so a interception large webcache cluster was in place to reduce costs. Since then the pricing model changed and the single webcache that replaced the cluster was made available via configuration only rather than transparently sitting between the Internet and the clients. The webcache that is about to be deployed will be with the university for 5 years, so although the configuration to replace the existing service is now complete, I’m also taking measures to make sure the new proxy will work correctly with IPv6 which will be with the university well before the server is retired.
We use Squid for our proxy, (there’s not much point in keeping that secret). For native IPv6 to work we need to deploy version 3.1 which is still currently in release candidate status, which roughly means beta testing has finished but the final release hasn’t quite been completed to their satisfaction. I’m not keen on deploying a release candidate in a production service (although it’s been fine in testing) so in the meantime
- I’ve worked on the packaging needed with the release candidate to match it to the operating system used
- I’m going to plan and configure the IPv6 configuration for the host, with an eye to deploying it with this configuration tested pre deployment but turned off at first
- I’m keeping an eye on the open issues with the release candidate on the squid developers mailing list
I’m hoping that by the time the first two are complete the final release will be deployed. If not we can deploy the distribution default version of squid and upgrade later but I’d like to get it all out of the way in one go.
Note that nothing will change with the core webcache behaviour and client configuration settings when the new hardware is introduced.