![]() |
![]() |
United States-English | ![]() |
|
|
![]() |
![]() |
HP Tru64 UNIX Version 5.1B-2 and Higher Patch Kits: Patch Kit Installation Instructions > Chapter 2 Preparing for the Installation![]() Creating a Baseline |
|
![]() |
The dupatch baselining process looks at the files installed on a system, compares them to the files it expects to find, and prevents the installation of any patch files that might cause an incompatibility among system files. This section provides an overview of the baselining process. See “Creating a Baseline” for instructions on setting a baseline. Unknown system files occur when the files are replaced through non-standard system file installation methods such as the following:
Missing system files result from a root user manually deleting system files that were installed during a standard full or update installation procedure or with the dupatch utility. The file is removed but the system inventory records are still in place. Unknown and missing system files will block patch installations until you take corrective action. However, before taking any action, it is important that you understand the origin of the unknown system files or why missing files are no longer present on your system. Changing the system without this knowledge could leave your operating system or layered product software environment in an inconsistent and nonoperational state. For example, a file whose origin is unknown that is blocking the installation of a Release patch could be part of a manually installed Customer-Specific Patch (CSP) that is not contained in the Release patch. Removing that one file will disrupt the operation of your CSP and possibly the operation of the system. When you run the dupatch system baseline feature, a baseline log file is captured in /var/adm/patch/log/baseline.log. (See Appendix A “Viewing Log files” for information about log files.) You may need to set the patch baseline for your system if you have manually installed system files or if dupatch informs you that patch installation is blocked by system files that are missing or unknown. Baselining is divided into seven phases that provide system information and optionally allow you to take actions that change the patch baseline of your system. You can run through all phases of baselining to get the system analysis without enabling changes to your system. You can run baselining in multi-user mode when you are the root user. The primary goal of Phase 1 is to evaluate your system relative to the patch kit that is being installed. However, the baselining feature will report all missing and unknown files to assist you in better understanding the state of the changed files on the system. The rest of the baselining phases use the information gathered in Phase 1 to inform you of any installation conflicts for patches contained in the patch kit. The amount of time needed to evaluate the state of the system varies depending on the size of the patch kit, the version of the software product, and the performance of the system. Phase 2 reports information for patches whose installation is blocked by system files that were installed by layered products. Baselining will not override layered product patch installation collision detection mechanisms as it is likely that the layered product or application customizations are not contained in the patch. Installation of the patch in this situation would leave the layered product or application nonoperational. To resolve this situation, contact your layered product or application Customer Services or HP Services if you have purchased Business Critical Services. Phase 3 reports patches that exactly match existing files on your system that are not marked as installed by the system inventory. For example, in earlier kits, TruCluster software Release patches were installed manually. This phase will report any manually installed Release patch files that exactly match a patch contained in the current dupatch-based TruCluster software patch kit. You can optionally enable dupatch to mark these patches as installed, which involves copying valid setld database information to your system. The dupatch utility will copy the appropriate patch_subset.inv, patch_subset.scp, and patch_subset.ctrl files into place for these patches. If you do not want to enable dupatch to mark these patches as installed, you must manually remove the patched system files so the normal dupatch installation can install the affected patches. Phase 4 reports information about any unknown and missing system files. These files should be considered as intentional customizations which are important to correct system operation. As such, care should be taken to understand why system files have been customized. Before enabling any patch installations in Phase 5, review the information reported in Phase 4 against your log of manual system changes to ensure you understand why the system was intentionally customized and to determine how to proceed. In some cases you may need to remove customizations to ensure proper system operation. To assist you in identifying the origin of changed system files, baselining now reports all missing or unknown system files. The following sections provide general guidance for some of the normal situations where system files are intentionally customized manually. In response to a problem report, you may receive a manually installable CSP from your service provider. CSPs are a set of compatible files that deliver fixes to the problems you reported. Additionally, the patch may include instrumentation necessary for debugging purposes. If your system was customized through a manual installation of CSPs, you must ensure that the fixes delivered by the CSPs are included in the current Release Patch Kit before enabling dupatch to overwrite any unknown or missing system files. If the unknown or missing files are attributable to manually installed CSPs that are included in a Release Patch Kit, perform one of the following steps:
To determine if your CSP is included in the Release Patch Kit, refer to the Patch Summary and Release Notes for the Release Patch Kit. See “Patch Process Resources” and “Related Documentation” for information about viewing patch documentation on the Web. For some software products, manual installation has been the practiced method for patch installation. For example, patches for TruCluster software used to be installed manually. You must determine whether the fixes delivered by the manually installed Release patches are included in the current dupatch-based Release Patch Kit before enabling dupatch to overwrite any unknown or missing system files. Once you have made this determination, proceed as follows:
Periodically, system administrators of production computing environments replace Tru64 UNIX commands or utilities with freeware or their own customized version of the command or utility. In this situation you must ensure the unknown or missing files are attributable to intentional replacement of commands, utilities, or other system files. If the unknown or missing system files are attributable to the replacement of commands, utilities, or other system files with customized versions for the computing environment, do not enable dupatch to overwrite the manually installed customized files. Instead, determine the reason for the customization and then decide how to proceed. Phase 5 reports patches that are blocked due to missing or unknown system files, and optionally allows you to override the dupatch conflict management mechanism so the dupatch-based patch may be installed. For each patch that is blocked by a missing or unknown system file you are presented with the following information:
Optionally, you can enable dupatch to override the collision detection mechanisms and install any of these patches. Use the missing and unknown file information presented in Phase 4 and your system administration log of manual system changes to make Phase 5 patch installation enabling decisions. We recommended that you do not enable dupatch to install patches over missing or unknown system files for which you do not know the origin. Doing so may leave your operating system and TruCluster software environment in an inconsistent and nonoperational state. We also recommend that you backup your operating system prior to the actual patch installation. Phase 6 provides the information about patches that have inventory conflict due to certain CSPs that are installed on the system. You will use this information when considering your decision in Phase 7. Phase 7 allows you to install patches whose inventory does not match the installed system when the system file changed originates from a CSP. Failing to determine the origin of the files that are in conflict can cause your operating system to be compromised. We therefore recommend that you track down the origin of those files. To assist you in this effort, this phase lists the additional files that have been installed with the files that cannot be superseded. You can run through this phase to get the analysis without enabling the installation of any of the listed patches. The following steps begin the baseline procedure:
The baselining procedure then runs through it's seven phases as follows:
|
![]() |
![]() |
|
![]() |
![]() |
![]() |
|||||||||||||||
|