Les Mikesell wrote:
> On Thu, Mar 6, 2014 at 12:57 AM, Cliff Pratt <enkiduonthenet@xxxxxxxxx>
> wrote:
>> I have some sympathy for Michael. There are organisations which are so
>> paranoid that they will not allow updates between eg 6.4 and 6.5, either
>> because they insist on rigorous (ie lengthy and time consuming)
>> regression testing of applications or because a third party package vendor
>> specifies a particular level of OS for their product (I can think of at
least two).
>>
>> Who has not been caught in the "not supported here" trap? You install a
>> package from the OS supplier, and have an issue with it. You go to the
>> forum for the package and get the response "upgrade to the latest
>> release", but the OS supplier will not support the OS if you upgrade
the package
>> to the latest release!
>
> A strict requirement based on arbitrary version numbers may be
> foolish, but a requirement for thorough testing before any change to a
> production environment is not - even though the changes that happen
> through the minor releases of an 'enterprise' OS have already been
> vetted for changes to existing APIs. However, you really have to
> assume that whatever you are running has security flaws and you have
> to be prepared to roll out the fixes as soon as possible after they
> are released since at that point the vulnerabilities will be well
> known. So, you need a fairly agile testing/deployment process to
> match your policy and keep it from doing more harm than good.
As the guy who does that here, what I do is to
0) arrange a monthly maintenance window (saves a *lot* of pleading and
begging)
1) update the development system (or, in some cases, they prefer that I
update
the test system, making regression easier).
2) update the other (test or dev).
3) if everything looks ok, update the backup prod machine, for those
that have them
4) finally, in the prearranged window, so that users know what's happening,
update the prod machines and reboot.
I'd have to think long and hard to *ever* needing to downgrade a prod server.
mark
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
