Some specific criteria to consider when planning your change:

—Backup of your system.

—System down time.

—When are your maintenance windows? What length of time are they?

—In the event of patches causing negative side effects, what steps will you take to back out changes, and how long will it take to execute these steps?

—To significantly reduce downtime, and to take advantage of the ability to easily switch back to your original image if the applied patches cause any negative side effects, consider using Dynamic Root Disk (DRD). With DRD, you create a copy of the root disk (or clone) that you can apply patches to, while your system is still up and running. Once all the patches are loaded on the clone, you can then reboot the system, using the clone as your active root volume. If for any reason you decide that the patched root volume does not perform as you desire, you can quickly reboot the original system image. For more information, please see Chapter 9 (page 86).

•Installing patches.

—Review Special Installation Instructions.

Prior to beginning the process of patch installation, review the patches to be installed to find any associated Special Installation Instructions. You can use the show_patches –itcommand directed at the source depot to list Special Installation Instructions documented within any patches in the depot. For more information, see show_patches(1).

—Install patches on the systems.

—Verify patches.

Verify that the patches installed correctly and that the patch had the desired effect.

—Recover disk space.

If disk space is an issue, you might find that you need to commit patches. This process recovers disk space consumed by files that were saved to allow patch rollback. Your organization should develop a formal plan to determine when and how patches should be committed. See Chapter 3: “HP-UX patch overview” (page 17) for more information.

•If you have opted to use DRD to reduce your downtime, you will need to create a clone and apply the patches to the clone, then boot the clone once all changes have been implemented. For more information, please see Chapter 9 (page 86).

4.Tracking the patch levels of the systems. (Patch level refers to the set of active patches on the system.)

•Patch level is important when determining which patches are needed on each system.

•You need to know the patch levels of the systems when interpreting patch testing results.

•If you need to open a support call, you might be asked for the current patch level to aid in troubleshooting.

You should keep all similarly configured production systems at the same patch level.

5.Managing patch-related changes to systems.

•You might find it helpful to log all patch-related system changes.

•You might find it helpful to document the results of patch testing and installation.

•Many customers find it helpful to have a formal change-request process associated with their patch management process.

44 Patch management overview