Patch Management Best PracticesApril, 2008 This document presents some basic scenarios for creating a patch management strategy for any given organization. How to Leave Comments or Tag Pages1. Register. |
|
Patch Management Best PracticesApril, 2008 This document presents some basic scenarios for creating a patch management strategy for any given organization. How to Leave Comments or Tag Pages1. Register. |
|
The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.
Comments (5)
Apr 29, 2008
Jeff_Turner says:
This information is extremely useful. I shall definitely be pointing my Solaris ...This information is extremely useful. I shall definitely be pointing my Solaris administration students to this BigAdmin page when we're discussing patches and patching policies.
The article covers all scenarios in an easy-to-read format with plenty of examples. Great stuff, Enda. I really enjoyed reading this article
May 22, 2008
mark-az says:
I too enjoyed this informative article. I do have a couple of questions I hop...I too enjoyed this informative article.
I do have a couple of questions I hope Enda or someone might answer:
1) When should customers Upgrade to a later Solaris Update vs. just adding Patches for new functionality?
2) How do customers determine if functionality is available by patching; or if an Upgrade to a later Update is required to attain the new functionality?
May 23, 2008
eoconnor says:
1) When should customers Upgrade to a later Solaris Update vs. just adding Patch...1) When should customers Upgrade to a later Solaris Update vs. just adding Patches for new functionality?
In general I recommend upgrading for a number of reasons
a. The updates ie 8/07 for instance is unit tested quite extensively, as opposed to individual patches in combination with other patches. To put it another way, Sun tests patches individually and in combination with all other released OS patches, but we cannot test say Kernel patch 120011-14 with every combination of all other released patches, as it's just too large a matrix to test. So this means that most users are actually running combinations of patches that are untested by Sun. Whereas update releases are extensively tested over a period of many months during construction of the update, and then the final update release candidate is extensively tested on it's own. That is not to say that patches are poorer quality, just that they don't receive the same level of testing as an actual update release. But as in all cases sometimes upgrade is just not feasible for business reasons, whereas applying the patches that comprise the update is actually allowed. Sun also plan to release a new patch bundle which will update your system to the patch level for a given update release, for instance for update 5, we will be releasing a patch bundle that will patch a pre update 5 system to the same patch level as update 5.
2) How do customers determine if functionality is available by patching; or if an Upgrade to a later Update is required to attain the new functionality?
a. Not an easy question to answer. Basically there is no way currently of telling which features are delivered in new packages in say update 5, and so will not be available via patching. But in general the kernel patch released at the end of the update say 127127-11 for update 5 SPARC, will end up delivering most if not all of the new functionality that is being added to existing updates in term of the OS component anyway. i.e. this is how one would get the latest zfs version and features from update to update, same for zones i.e. cpu-caps for instance, or any enhancements to the kernel itself.
May 28, 2008
Colin_Taylor says:
This is an interesting article, but it seems to contradict the other "Best Pract...This is an interesting article, but it seems to contradict the other "Best Practice" guide referenced in last months newsletter. That one (http://dlc.sun.com/pdf/817-0574-12/817-0574-12.pdf) heavily implies that if you have a functioning system there is no good reason to patch it (apart from security patches if appropriate).
That article is rather old (2004) and was probably written for Solaris 8 & 9. Does this imply that there is a fundamental change in what is being delivered by patches in Solaris 10 and hence a change in strategy? Or, that update releases in Solaris 8/9 were regarded as extremely stable whereas Solaris 10 updates are inherently unstable and always in need of patching?
May 29, 2008
eoconnor says:
Hi Colin In general, Solaris 10 updates have introduced quite a lot of extra fun...Hi Colin
In general, Solaris 10 updates have introduced quite a lot of extra functionality that was not present in FCS release of Solaris 10. For instance zfs was introduced in update 2, and every subsequent update has introduced even newer functionality to zfs, along with bug fixes to the existing zfs code base, zfs was not the only new features introduced in updates, we also had Trusted Extensions, among others.
So you are quite right that patching in Solaris 10 has introduced a lot more complexity over Solaris 8 and 9.
If you are using zfs, then you will probably need to apply the latest patches ( kernel patches especially )that are released after every update release. This is certainly a different scenario that solaris 8 or 9.
But in saying that I strongly recommend that every customer examine their own business plan and determine the best solution with regard to system maintenance. In general I would always recommend a proactive approach to security patching, and aside from that, it really is a customer choice as to what strategy to follow. If a system is say running a metacluster like SUNWCreq that has been hardened and is not running zfs for instance, then it is debatable whether to be proactive in regards to applying non security patches, but it really must come down to the customer examining the system(s) and deciding the strategy to adopt.
Personally for Solaris 10, I recommend proactive patching, but as I stressed, all change should be appropriately tested before being put into production. Proactive patching does imply change, which in itself can introduce issues.
Enda