Patch Management User Guide for HP-UX 11.x Systems
Advanced topic: scanning for security patches
You can use the SWA Tool to identify security patches for installation. This tool also identifies
patches that have associated warnings. For more information about SWA, see Chapter 8: “Using
HP-UX Software Assistant for patch management” (page 85).
Testing the patches to be installed
The single most important action that can ensure the success of a software patch is to first test
the changes in a nonproduction environment. Every environment is unique, and patch testing
can uncover potential problems unique to the environment in which the patches will be installed.
If you test thoroughly, you can reduce the chance of encountering problems with new patches.
The level of testing you perform depends in part on the patch management strategy you choose.
For example, because proactive patching involves installing patches before a problem occurs, it
allows more time than reactive patching to complete a sufficient level of patch testing.
HP subjects all General Release (GR) and Special Release (SR) patches to extensive
testing. See Chapter 3: “HP-UX patch overview” (page 17) for more information about GR and
SR patches. However, it is impossible to test all permutations of all patches on all hardware
configurations. Therefore, prior to deploying the patches on production systems, you should
test the set of patches you intend to install in a test environment that closely simulates the
production configuration. Even if you are deploying a standard HP-UX patch bundle, you should
still perform testing. Deploying any patch without first testing it in an environment increases a system's
exposure to risk.
The following is an outline of a basic patch test scenario:
1. The patches to be installed are identified and acquired.
2. The acquired patches are installed on a test system and tested to a standard that your
organization considers acceptable. Many organizations break this step into multiple levels
of testing to accomplish distinct goals. If testing results in unsatisfactory results, you must
perform an investigation to identify the root cause of the problem before proceeding.
3. The tested patches are installed on production systems.
The success of your testing approach relies heavily on how closely the configuration of the test
environment matches the configuration of the production systems on which the tested patches
will be installed. Within hardware limits, it is a best practice to duplicate the production
environment as closely as possible.
Ideally, you have a test system that is identical to the production system on which patches are
to be installed, and you have sufficient time available to test all patches prior to deploying them.
This situation allows you to perform very effective testing to verify that the patches to be installed
will not result in unexpected or undesirable system behavior.
Many customers have a two- or three-tiered approach to testing. Patches are initially installed
on a system that is often referred to as the development system. These types of systems are used
for local development. In a three-tiered system, after certain organization-specific rules have
been met, the patches are installed on another system that is often referred to as the test system.
The patches must then meet another set of organization-specific rules. For example, many
customers require that the patches be installed on the test system for some specified period of
time with no problems. The amount of time varies widely and can be as short as a week. However,
for many customers, one to three months is considered a reasonable time frame for testing. Once
these rules have been satisfied, the patches are installed on one or more production systems.
Customers who initially install the patches on only a subset of their production systems typically
monitor these systems for several weeks prior to installing the patches on the remaining
production systems. For reactive patching, the longer testing time frames are usually not
reasonable and a stripped-down approach to testing is usually required.
Testing the patches to be installed 51