Patch Management User Guide for HP-UX 11.x Systems

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 ITRC. The ITRC's self-solve tools, such as the search
knowledge base link, can help with that query. For more information, see Chapter 6: “Using the
IT Resource Center” (page 55).
Next, using the ITRC 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 ITRC 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 ITRC. Because most patches that
fix a security problem fix only a single problem, this practice is not as risky as it might seem.
50 Patch management overview