HP UX Patch Management manual Testing the patches to be installed

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