Patch Management User Guide for HP-UX 11.x Systems (5900-3011, April 2013)

Reactive patching has some important disadvantages as compared with proactive patching. The
process of identifying a problem fix can be made more difficult as your system falls further behind
the most recent patch levels available. In addition, the required patch will likely contain much more
new content than if you had performed frequent proactive updates. You might also find it difficult
to perform adequate testing in reactive patching situations, and this could lead to the introduction
of additional problems.
Acquiring patches for reactive patching
The easiest way to identify your required patch is to call the HP Response Center. This works only
if you have the appropriate support contract. Alternatively, you can carefully research the problem
using resources such as the HPSC. The HPSC's self-solve tools, such as the search knowledge base
link, can help with that query. For more information, see Chapter 6: “Using the HP Support Center”
(page 57).
Next, using the HPSC Patch Database, you must identify the patches needed to resolve the problem.
For reactive patch management, patch acquisition and installation should be strictly limited to the
smallest set of patches believed to provide a solution to a current system problem. Do not use the
unplanned down time as an opportunity to make unrelated changes. This is especially true for
mission-critical systems.
Once you know what patches are needed to solve the problem, you must determine when to patch
your system. In making this decision, you should consider the following factors:
• Severity of the problem
• Frequency of occurrence
• Availability of system down time for patching
Follow these steps to patch your system reactively:
1. Isolate the problem and identify the patches with the highest HP rating that represent a potential
fix.
2. Acquire the needed patches and any patches needed to satisfy dependencies.
3. If you have a patch depot, add these patches to it and use this as a test base.
4. Test the patch. In some cases the problem is so serious (such as a when a critical system is
down) that you might need to omit the test step. This is especially true if it takes a long time
to replicate the problem, or if the configuration is difficult to replicate. If you choose to omit
testing, do so only with the knowledge of the risks you might incur.
5. Determine a suitable time to install the patches.
6. Install the patches.
If you have multiple, similarly configured systems and you need to patch one of them reactively,
consider patching the remaining systems as soon as it is reasonably possible. This is because it is
likely that your other systems will suffer the same problems at some future point. Additionally, there
are benefits to maintain the same patch level on similar systems.
Advanced topic: security patching strategy
Security patching requires both urgency and a need to be proactive. It does not fit neatly into the
proactive or reactive patching strategies. At times, you might need to apply security patches
proactively prior to the next scheduled patch installation maintenance window.
When you use the HPSC to acquire patches, it is safe practice to obtain patches listed as
recommended. Because of the urgency associated with security fixes, there are many instances
when a security patch is too new to have this rating. However, many customers give a new security
fix priority over an older patch recommended by the HPSC. Because most patches that fix a security
problem fix only a single problem, this practice is not as risky as it might seem.
52 Patch management overview