Q: What is the Sun recommended method for installing patches? I would like to see Sun publish a document that details real-world practices for patch management. Start from the initial system installation (partition layouts for Solaris Live Upgrade software), identify software to use, identify what patches should be installed (all patches or just security and recommended patches), and so on.

A: As you say, there are a lot of different scenarios that relate to patching. I have already replied to a different question on the topic of patching servers and a methodology for doing that.

In general, I recommend that for patching live, critical servers, sys admins develop a personal patch management plan for their own particular needs.

I recommend a patching strategy where users monitor Sun Alerts and so on, and then decide on the patches that their particular setups require. For instance, not all security patches might be necessary, if, say, a user has physically hardened a 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 and 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 and so on would be used in this methodology at all times.

We strongly recommend the use of Solaris Live Upgrade software, where possible, because this reduces downtime to a minimum and provides an easy way to revert a system back if necessary.

Jason Murray - December 17, 2007 Back to top

---

Q: Will patch management and software management ever be built into a common interface, similar to apt or yum in Linux?

A: Yes. Currently Sun has a product called UCE, which is a premium add-on. However, the current tools, such as smpatch, are planned to be moved over to a general release.

Jason Murray - December 17, 2007 Back to top

---

Q: In the Solaris 10 08/07 Operating System, is there a way to use luupgrade to apply patches to a system that uses Solstice DiskSuite to mirror the root? The only way I've been able to apply patches using luupgrade is to break the mirror, then use lucreate to copy the root environment, then apply the patches to the new root, and reboot on the just-patched root. After the reboot, I have to recreate the Solstice DiskSuite mirror, which requires one more reboot. I don't have enough disk space to create three copies of the root environment.

A: Have a look at the following information on BigAdmin about Patch Smack, which has an example of lucreate for a Solaris Volume Manager mirrored root and explains what resources you will need to have for lucreate, for example, the alternate mirror environment.

But since you have a mirror and are resource-constrained, why not break and patch one side of the mirror, and then reencapsulate (which requires two reboots)?

Say that metastat -p has this:

d/0 -m d10 d20 1
d10 1 1 c0t0d0s0
d20 1 1 c0t1d0s0
#
    

With vfstab as such:

/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no
    

Then you could do this:

# metadetach d0 d10
# metaclear d10
# mkdir /mnt
# mount /dev/dsk/c0t0d0s0 /mnt
    

Edit /mnt/etc/vfstab to make the "/" entry look like this:

dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no -/
    

/# cp /mnt/etc/system /mnt/etc/system.mirror/
edit /mnt/etc/system to remove the rootdev entry
	

Install the patches to /mnt using luupgrade (or just use patchadd -R /mnt).

unmount /mnt
/# shutdown -y -g0 -i6/

Then once rebooted and we are happy, just reencapsulate the root disk.

Delete the metadb's and recreate:

# metadb -d c0t0d0s7 c0t1d0s7
# metadb -a -c3 -f c0t0d0s7 c0t1d0s7
#
/* Clean the system metadevices always present. */
# metaclear d0
# metaclear d20
#
#
/* Re-create them as part of a mirror. */
# metainit -f d10 1 1 c0t0d0s0
# metainit d0 -m d10
#
/* Be able to boot on the new metadevices. */
# metaroot d0
#
/* Reboot, and create the second side of the mirror. */
# shutdown -y -g 0 -i 6
[...]
# metainit d20 1 1 c0t1d0s0
# metattach d0 d20/ 

And voila, now it takes two reboots. Please review this info carefully for any typos I might have made, as this is mostly from memory. But it does not use any more disk space than you already are using.

Joel Rem - December 17, 2007 Back to top

---

Q: To allow removal of patches, each patch stores various "material," and over time, disk space usage goes up and up. What's the official way to clear out some of this stuff and reclaim disk space? Do we need to upgrade rather than continue to patch?

A: There is no official way of clearing down this space. Although it is possible to remove the patch undo directories in /var/sadm/pkg/<pkgname>/save/ if required, you would need to be careful. A patch can patch multiple packages, and failure to remove all the particular patch revision undo directories can lead to problems.

On the other hand, an upgrade is a fully tested unit, as opposed to patching, where end users are free to install any combination of patches. For instance, the Solaris 8/07 Operating System (otherwise known as Update 4) is basically a combination of the latest patches and packages that are new. It is fully tested as a unit, whereas patches are tested either in isolation or with varying combinations of other patches. It is not possible to test each and every combination of available Solaris patches. In general, I would tend to recommend upgrading if at all possible, and Solaris Live Upgrade software can be used to make this process easier.

Another approach, if you want to keep the backout data, is to create a new file system for /var/sadm/patch and mount it to /var/sadm/patch.

Now you will need to remove the lost+found directory (assuming ufs, newfs, and so on were used). Otherwise, patch tools will give weird error messages.

Naturally, move the original to a backup location first, and then once the new file system is mounted (make sure to update vfstab to have it mount on every boot), use cp -r to copy the data from the original to the new file system.

It's best to run a tool such as pkgchk before and after such a move and compare the results to make sure there were no glitches.

Then run patchadd -a <latest kernel patch>. The -a will do a dry run, and using a large patch such as a kernel will test that such a complex patch can be installed.

Naturally, the system must be quiet, because any updates to the pkg database while the previous command is in progress will lead to problems. So single-user mode is advised.

David Holmes - December 17, 2007 Back to top

---

Q: Is there a way to simulate patching? On IBM AIX, you can run the patching process and ask it to only show you what will actually be patched, what requirements are missing, etc... without touching the OS at all.

A: Yes you can run patchadd -a where -a although undocumented does a dry run and installs no software.

On the Solaris 10 OS, you also can pass -M <patchdir> where patchdir contains a set of patches. So patchadd -a -M will order this directory and produce a report of what can be installed and what cannot be installed due to dependency issues, and list the missing dependencies.

It's pretty verbose, but very useful, especially in a zones environment, as certain classes of problems can be caught this way.

Real Melancon - December 18, 2007 Back to top

---

Q: After a Solaris 10 kernel patch is applied, no patching operations can continue until a reboot occurs, which prevents further patches from being applied until the system is rebooted. Is there a workaround to this?

A: This is not a bug, it is the way this particular patch was designed. Due to the volume and the nature of the change that 118833/118855 revision 36 delivers, modifications had to be made to enable this patch to install safely on live partitions. Unfortunately these changes also meant that installing further patches on top of this KU could not be allowed, as it would risk compromising the system. Therefore no further patches can be installed till a reboot has taken place.

The Solaris 10 OS has seen a lot more features backported by way of patches from later updates than Solaris 9 has. For instance, Update 2 introduced ZFS, and Update 3 introduced Trusted Extensions plus more major changes to ZFS. Functionality such as Solaris Zones has introduced further complexity that differentiates the Solaris 10 release from Solaris 9. Work has taken place to make sure that Kernel Patches after 118833 can be installed without the need for a reboot.

Marcos Pagnucco - December 18, 2007 Back to top

---

Q: Patch 118855-36's NOTE 34 (Solaris 10 U2 x86 should be patched) states that the patch should be installed in single-user mode. Is there any way to install it remotely, or must I be in front of the machine physically while applying this patch? (It's a Dell PowerEdge 1800 system with two 73GB U320 disks, HW mirrored by a PERC controller, one 3.4GHz Intel Xeon, and 1GB RAM.)

A: I seem to remember these PowerEdges can be painful to console up remotely. Assuming that console access cannot be added, then the options are limited to sitting in front of the machine.

Basically the reasoning for single-user mode is to have as little as possible running on the machine at the time when the patch is being added. So while installing in multiuser mode is not advised, as long as the machine is as quiet as you can get it (i.e., applications have been stopped, users have been kicked off, etc.) then you could patch in multiuser mode. All non-essential stuff should be stopped.

But single-user mode is advised in the case of complex patches like 118833-36, so that networking has been brought down, and so on.

Attila Nagy - December 18, 2007 Back to top

---

Q: I currently use smpatch on the Solaris 10 OS by performing analyze, download, order, and add. I see in the documentation the Live Upgrade tool. I cannot determine from the doc which is the preferred method for patching. Which is the Sun preferred way to patch systems?

A: Solaris Live Upgrade does not do analysis of systems, but it is the preferred method of applying patches where possible. Basically it reduces downtime to the time needed to do a reboot. In simple terms, you:

• Create a copy of the current live partition (Alternate Boot Environment or ABE)
• Patch this copy using luupgrade
• Boot to the ABE

If there are problems with the patched ABE, you can simply revert to the original boot environment.

So using smpatch to analyze the system and luupgrade to patch it is a good combination.

Tony Odell - December 18, 2007 Back to top

---

Q: What about the content of the /var/sadm/spool directory? Could it be "cleaned" after patches have been installed?

A: Yes, once patches have been installed, any patches in spool can be deleted.

Nelson - December 18, 2007 Back to top

---

Q: A lot of people have given up on using Sun's own patch tools and use (for example) PCA instead. Non-Sun tools use the patchdiag.xref file to get information about all available patches. This file has always been freely available without a Sun Online Account. This changed in August this year -- suddenly a SOA was required ... Since November, the file is once again available without an SOA, again without any announcement. Even worse, the methods and URLs to download patches hands-off (e.g. with wget) have changed multiple times this year without any proper announcement. Will there ever be a stable and documented interface for hands-off downloads of the patchdiag.xref file, patches, and patch READMEs?

A: I can understand your frustration due to the less-than-ideal rollout and changes that occurred. Personally, I am not responsible for making decisions around SOAs and entitlements ... I would hope that patchdiag.xref stays freely available as tools like PCA are invaluable in terms of managing Solaris based systems.

This SunSolve doc outlines the current process: http://sunsolve.sun.com/search/document.do?assetkey=1-9-82023-1.

patchdiag is currently free as you stated.

Martin Paul - December 18, 2007 Back to top

---