Dynamic Root Disk: Quick Start & Best Practices

12
Patch Planning and Alternative Patch Deployment Schemes
The offline patching scenario presents a straightforward progression from clone to boot in a fairly
short time period. However, a system administrator might benefit from some time and feedback to
craft the exact selection of patches to be applied to an inactive system image that is eventually
booted.
The drd clone and drd runcmd operations can be useful in helping a system administrator to
identify an appropriate patch selection, and, if desired, to test it before final deployment.
For example, a system administrator might create a clone, identify a patch selection, use drd runcmd
to apply it to the clone, and then investigate any unexpected messages. These messages could
include a need to acquire or extend license keys, identify conflicts with previously installed site-specific
patches, or just be notes about automatically selected patch filesets. The swlist and swverify
commands can be run against the clone. In addition, the system administrator could compare the
patch selection with that of a reference system.
If short test periods are available before the actual patch deployment, the system administrator can
boot the clone and perform application testing. With this mechanism, problems are identified before
the entire community is exposed to the changes.
When the system administrator is satisfied with the patch selection, one of the following two options
could be utilized to make sure the clone is up to date before activating and booting it. To determine
the best method, first run the drd sync command in preview mode:
# /opt/drd/bin/drd sync -p
• Using drd sync: Examine the
/var/opt/drd/files_to_be_copied_by_drd_sync
file. If the file is not large, create a shutdown script that runs drd sync so that files changed on
the original image after the clone was created will be propagated to the clone (See the “DRD sync”
section below for more details.)
• Re-creating the clone: If the
/var/opt/drd/files_to_be_copied_by_drd_sync file
is large, consider running drd clone to re-create the clone. This will ensure current copies of all
configuration files (for example: users, passwords, printer configurations) are included in the clone.
The final patch selection is then applied with the drd runcmd.
Regardless of the option used to bring the clone up to date, you can then activate and boot the clone.
If downtime is scarce, the system administrator could create a clone daily and apply the “known
good” patch selection to it. When an application outage was needed for other reasons, or an
unexpected outage occurred, the clone could be deployed as part of bringing the system up.
Best Practice 2 (BP2): Basic Maintenance – Patching & Security Bulletin
Management with DRD and Software Assistant (SWA)
As in Best Practice 1, this scenario will once again demonstrate how to use DRD to reduce downtime
during system maintenance. However in this scenario we will be utilizing Software Assistant (SWA)
to identify any required patches. SWA will identify missing patches/patch bundles, patches with
warnings, and fixes for published security issues. For this scenario, our setup is as follows:
Assumption: clone is already created and you are booted on the active image
Patches to apply: SWA will figure this out for you
Depot with patches: /var/depots/1131swa