Q: I have been a Solaris administrator for many years. I have noticed a non-trivial number of revisions to patches that fix bugs caused by earlier versions of the same patch or by other patches. For this reason, I generally only install patches when there is a strong need for them as opposed to regularly installing all available patches. Do you consider it important to install all patches as they become available, and why?

A: In general, I recommend that where critical systems are involved, users let patches soak in the field for a period of time; in real mission-critical applications, periods of up to a year are not unheard of. On the other hand, where patches fix critical security issues and no workaround is available, then installing the patch proactively would be advised.

Dan Stutzman - December 05, 2007 Back to top

---

Q: What does Sun recommend regarding patching in multi-user vs. single-user mode?

A: Sun recommends that everyone go through the README file distributed with every patch. The README file highlights all these details, and it would mention if a particular patch needs to be installed in single-user mode. If so, you must install in "Single User" mode and follow the rest of the instructions, like immediate reboot or reconfigure reboot. Many of the READMEs also specify special instructions to install a patch. Again, these instructions should be followed.

Bill Jones - December 10, 2007 Back to top

---

Q: In the last year, a lot of documents were published about the new patching strategy. They are really interesting. But can you sum up recommendations for really big data centers? Now we work like this: If we have a known problem at the production server, we plan downtime and then install patches from EIS.

A: EIS is a good known and supported format, also the patches on EIS tend to have been field tested for some time. For a really big data center, I'd suggest using patches that are aged where possible. This can be up to one year, but in general it is very dependent on:

• The problem encountered
• The patch management strategy that is being used

The second item above is really site dependent. Every site should examine their own business requirements and decide what is appropriate: for example, when general maintenance can be carried out will vary from site to site. The same is true for when critical maintenance can be carried out.

The following (from another mail that I replied to) is relevant here as well.

In general I recommend that for patching a live critical server sys admins must develop a personal patch management plan for their own particular needs. I recommend a proactive patching strategy, where users monitor Sun Alerts, etc., and then decide on patches their particular setup requires. For instance not all security patches might be necessary, if, say, a user has physically hardened their system and removed the offending software.

Then once a patch has been identified, testing must occur. In the case of mission-critical systems, this would be on an identical hardware + software configuration. Only then would maintenance be planned for the production server, at which time a set of patches, or just one patch, would get applied. Backups, etc., would be inferred in this methodology at all times.

The other approach is reactive patching, but I would not recommend this, as usually this occurs when an unknown issue has occurred, and installing further software patches might only worsen the problem.

We strongly recommend the use of Live Upgrade where possible as this reduces downtime to a minimum and provides an easy way to revert systems back if necessary.

Anton - December 14, 2007 Back to top

---

Q: Is there an easy way to download all patches (at once, as a bundle) for a given version of Solaris? I've found that the "Recommended Patch Clusters" are often missing security and bug fixes that I'm interested in. I have a network that is disconnected from the Internet, so I'm unable to use Sun Update.

A: In general, the recommended cluster should have all the security patches that apply to the Solaris product.

Patches for other products that install on the Solaris OS are not included in this cluster.

So if you are running Sun Cluster software, security patches for this product are not be included in the Recommended Patch Cluster.

This is to keep the size of the patch cluster manageable since there are many products at different versions that may be installed on your Solaris system.

The best way to select all the required patches for your system is to use the patch management tools like the smpatch(1M) command or the UCE patch management tool. Alternatively you can use PCA from http://www.par.univie.ac.at/solaris/pca. This is free and uses patchdiag.xref, which is also freely available.

Editor's Note: This answer refers to UCE, which is now twice deprecated. UCE should be replaced by Sun Connection (now incorporated in xVM Ops Center).

Zachary Anthony - December 15, 2007 Back to top

---

Q: How can I know that my system is updated with latest patches, and is there any way to determine what critical patches are not on my system and need to be installed?

A: There are some good tools available, such as pca, which can analyze your system. This third-party tool is widely used: See the PCA home page at http://www.par.univie.ac.at/solaris/pca/.

There are other options. You could download the latest security cluster from SunSolve. Using the following command does a dry run and does not update any software: patchadd -a -M <patch dir where security cluster was expanded> -a.

This analyzes the installed patches and compares them to the directory containing the security cluster patches. It lists the patches that can be installed and those that are missing requirements, plus it lists the missing requirements. This can be an iterative process.

Kumanan - December 17, 2007 Back to top

---

Q: What happened with the Solaris 10 kernel patch? These days you have to run Recommended twice to get a complete patch update.

A: Unfortunately, due to the increased complexity of Solaris 10 Kernel updates, mostly due to the features being backported to earlier releases via patches, these patches required a lot of extra work to allow them install safely. The first such patch was 118833-36; it was felt that to allow further patching on top of this patch without a reboot would be too risky and the chance of corruption would be too high. Therefore, a forced reboot was introduced, such that post installing 118833-36 (or x86 equivalent 118855-36), no further patches can be installed until a reboot has occurred.

This was alleviated to some degree with the 8/07 Kernel patch 120011-14, which does not require a reboot, but due to a bug in the patch tools that is being fixed, if installing further Kernel updates such as 127111 9 (or x86 127112) a reboot post applying 120011/120012 should be done.

Once the bug is fixed in the patch tools, this reboot will no longer be necessary.

Harry Vinke - December 17, 2007 Back to top

---

Q: Sun has come up with (and EOL'd) different ways to centralize patching. What is the best way going forward to manage patches and patching from a single system, in a shop with a mix of Solaris 8, 9, and 10 systems, without having to purchase extra services?

A: One alternative is PCA from http://www.par.univie.ac.at/solaris/pca/. This tool is free and uses patchdiag.xref, which is also freely available. Now, of course, one needs a Sun Online Account (SOA) to be able to download non-free patches. But all security patches and some others are still free.

Jay - December 17, 2007 Back to top

---

Q: Why does Sun release seemingly unrelated "patches" in a patch? For example, I have seen patches to sendmail inside of kernel patches before.

A: Actually, they might appear unrelated, but they mostly are related. Due to how we construct kernel patches, patches tend to accumulate a large number of seemingly unrelated patches. This happens because sometimes new features, such as Solaris Trusted Extensions in Update 3 (the Solaris 11/06 release), actually affect a large portion of the code, both kernel and userland.

Jason Murray - December 17, 2007 Back to top

---

Q: Why do some patches overwrite custom configuration files? For example, there have been times when my custom sendmail configuration files have been overwritten causing my mail server to stop functioning.

A: If a configuration file is overwritten, this is a bug in general. Sendmail has been problematic because some of its configuration files were not delivered as editable, and they got overwritten.

Also, there are cases in which a patch, when installing a newer editable file, will move the existing file aside, and replace it with the new file. A warning is then flagged in /var/sadm/patch/<patchid>/log stating that the user needs to merge the old into the new. But in general, I dislike this particular approach, and tend to try to convert people to not moving the old file aside if at all possible.

Jason Murray - December 17, 2007 Back to top

---

Q: What is Sun's take on using third-party software, such as PCA, to patch systems? When using applications such as smpatch, I have run into numerous problems from the software not working to patches not being installed upon reboot. PCA has solved these problems for me; it always works, it has a simple interface, and it lets me easily control what patches I install. I personally like to install only the security patches and their dependencies on my systems.

A: I fully support your using PCA. It is a third-party tool, but it is quite well written and very useful. Over time, tools such as smpatch are being transitioned to other more robust solutions. But using PCA is a good option.

Jason Murray - December 17, 2007 Back to top

---