Server Upgrade Policies - discussion

[dbiel]

The following was spilt off of a topic in the Email Forum as it is drifting a bit too far off topic

in the REAL world that most of us live in, that is usually not possible. You are happy if you can just keep them all working.

No offense, but I work in the REAL world. It sounds like you need better change management policies. The "fix" is not done until all servers are updated, especially for a software configuration file, which I am assuming SpamAssassin is using. Some systems, we keep the master file on a fileserver and the server itself checks there for updates. OSes are a bit more difficult, especially if they have different functions.

"It sounds like you need better change management policies." No argument there, but I still believe my basic point has merit. But before continuing, note that Steven has presented what would and is the best policy, I am simply stating that in some "many"? circumstances that is not possible.

You are in crises mode. You add equipment (newer software, newer hardware) You get it up and running fast. (By the way, this does seem to fit the description of the original subject) You can not afford to take all the servers down as you run 24/7. You are bound to run into some difference in setup in the process. Sometimes funds do not permit upgrading the entire system at one time and it has to be phased in over time. This is the REAL world that many live in.

Sometimes the "new" hardware is actually old hardware that is not compatible with all the new software running on the other servers, but it is put back in service due to increased capacity needs and lack of funds.

The point is that there are many reason why differences can happen

In your part of the REAL world, that may never happen, but in mine and and do know of many others, it does happen and one tries to the do the best they can with what they have available.

I feel confident that you do not support upgrade pirate software (the policy of buying one upgrade and using it on more servers than the licence permits). Due to funding issues, upgrades may need to be phased in over time. And remember staff issues as well. I do not know too many places where one can afford to take a entire system down and keep it down until all upgrades are complete and then bring it back on line.

Well enought for my soap box.

[StevenUnderwood]

dbiel: I agree with all that you said. Our desktops have a range of versions of software, but I was not talking about that.

I was more talking about scripts and configuration files in use on multiple server systems (like the blade servers JT is using). While the software may not always be 100% identical, any changes made to one system (switches, ini file changes, etc.) should be made to all systems in the process. This is usually done to one server and tested, then before that issue is closed, performed on all the remaining servers, usualy one by one so as not to bring the whole system down.

I have 2 different OpenVMS systems in or 2 divisions. One is runnng on an old single CPU Alpha with 4 disks while the other is running on a quad processor Alpha with RAID arrays, etc. However, the scripts in use on both are almost identical with only changes for the actual hardware.

SpamAssassin configuration file on server A should be the same as SpamAssassin configuration file on server B, no matter what hardware/OS it is running on. The only difference I could see is some setting that is not available in the older version, but if that is the case, then they all need to be at the same level.

I too am stepping off the soapbox.