Once a depot has been created, its contents must be installed on the target systems. This chapter describes the rec-ommended steps to execute and verify patch installation.
• Appendix A: Basic Patch Concepts
Patches are different from other types of HP-UX software. Patches have a terminology and operations all their own. This appendix provides a basic understanding of patch concepts.
• Appendix B: SD Tools & Objects
While Software Distributor (SD) has a wealth of documentation available, the sections that are of specific interest to patching are not always readily apparent. This appendix provides SD information related only to patching.
• Appendix C: The Patch Text File
The patch text file can be found in a variety of locations, but remains the core documentation of each patch. This appendix lists all of the fields within the .text file with a brief description.
Other Sources of Information
Web Sites
• http://docs.hp.com
The home page for H-P technical documentation, this source provides online access to HP-UX manuals, guides, and whitepapers. Information on particular hardware platforms, HP-UX releases, and software products are avail-able for browsing, download, or purchase.
• http://software.hp.com
Known as H-P’s Software Depot, a variety of HP-UX software is available. While some require purchase, many products such as Ignite-UX and the Support Plus patch bundles are available without charge.
• http://ITResourceCenter.hp.com
The primary source for all support information, the IT Resource Center (ITRC) and the Electronic Support Center (ESC) that it contains provide a variety of tools and information related to HP-UX systems. In addition, the ITRC is the official repository for all HP-UX patches.
• http://www.interex.org/tech/9000/index.html
The International Association of Hewlett-Packard Computing Professionals, known as Interex, maintains this list of technical resources for HP-UX systems. Not a part of Hewlett-Packard itself, Interex is also noted for its yearly trade shows Interworks and HPWorld and regional users groups. The main page (http://www.interex.org) should be reviewed to learn about all of the benefits of membership.
• http://www.dutchworks.nl/htbin/hpsysadmin
Another resource outside of Hewlett-Packard is the HP-UX Administrators Mailing List. This web page is an interface to the list archives dating back to 1995. To join the list itself, send the command:
subscribe hpux-admin-digest
in the body of a message to "[email protected]".
CHAPTER 2
Planning for Recovery
With complex systems, some amount of uncertainty is present with any change of state. Whether you are installing patches, upgrading to a new OS release, or tuning the kernel it is always possible that the original, known system con-figuration is preferable to the new state. That is why this guide to patch management begins with a discussion of the merits of planning for system recovery.
The Value of Recovery Options
Problems happen. The causes vary, and can range from hardware failures, operator errors, and even malicious attacks.
When a problem results in the failure of a critical system, the first order of business is to return to an operational con-dition as quickly as possible. When planning and resources are put in place to support system recovery the risk of a failure remains, but the associated cost of a failure can be controlled and calculated.
When the cost of failure is minimized, the value of proactive maintenance is increased. Proactive maintenance is the fixing of known problems before they are seen on a system. The value of a patch is listed within its documentation, with all of the defects or enhancements described. It is common for an administrator to avoid system change for fear of introducing a new failure. With a predictable recovery plan, the known cost to return to the original state can be weighed against the risk of encountering any of the documented conditions at an unknown time.
More than one option exists, and more than one option should be used. At different times, different options may be preferred. By planning for multiple methods you also protect yourself from the failure of any one of the recovery options, such as a bad tape or network failure.
The Root Volume Group
The Logical Volume Manager (LVM) allows a single disk to be split into pieces, or a group of disks to be treated as a single unit. This dramatically changes the way disk management can be done. This section will discuss issues with LVM root volumes, but the same concepts would generally apply to users of whole-disk HFS root disks.
Ignite-UX
Practice Data Separation
Several of the recovery options involve creating a frozen image of the root volume group to preserve a known state.
This is a powerful method for recovery as the environment is preserved as a whole, and not as a collection of parts.
Some restrictions must be placed upon the root volume group to enable recovery options.
• Limit the size of the root volume group
While placing all of the disks on the system into a single volume group simplifies the configuration process, it makes recovery images larger and raises the cost of mirroring.
• Do not place volatile data on the root volume group
To differing amounts, every recovery option requires that you choose a point in time to preserve. In the event of a critical problem, you can return to that point.
Any new data contained within the root volume group would be lost when the image was restored, or at a mini-mum would require an additional data recovery step.
• Keep all system data within the root volume group
It is not uncommon for a system administrator to free up disk space by relocating parts of a directory structure and replacing it with a symbolic link. While effective, it can be a recovery trap. While Ignite-UX will save system crit-ical data regardless of the volume group, what you consider to be critcrit-ical may not be the same things that Ignite-UX considers critical.
Tools and processes can allow some deviation from these rules (see “Ignite-UX File System Guidelines” on page 4) but any deviation should be done to meet a specific need, and with consideration given to the recovery mechanisms.
Preserving Configuration via NIS
While not as critical as data, system information such as networking configuration and password file entries may change on a frequent basis. If systems such as NIS and DNS are used to maintain configuration data off of the system, the recovery process will not require an additional step to restore configuration updates.
Refer to “Installing and Administering NFS Services” for more information on NIS and NIS+. This and related docu-ments are available from http://docs.hp.com.
Ignite-UX
Ignite-UX is a set of tools that can be used for system installation, recovery, and duplication. Used within Hewlett-Packard to preload software, UX is available free of charge. To download the latest version or browse Ignite-UX documentation, go to http://software.hp.com/products/IIgnite-UX.
Ignite-UX File System Guidelines
Be sure to follow these Ignite-UX guidelines for file system layout if a different method is chosen for the primary recovery mechanism:
• /, /sbin, /stand, /dev, and /etc
These directories contain the critical parts of the Core System required for booting. They must exist completely within the root volume group.
Ignite-UX
• /usr
The /usr directory tree contains those elements of the Core System that support the post-boot system functionality.
While not required to be included within the root volume group, it should not be placed within a volume group that includes volatile data. The Ignite-UX recovery tools will preserve the full contents of the volume group that includes the /usr directories.
• /opt and /var
Only certain parts of /opt and /var (such as /var/adm/sw) can be considered to be part of the Core System. Ignite-UX will preserve these areas regardless of the parent volume group.
• /home
This directory, normally used to hold the login or home directory for each user, is expected to hold dynamic user data and should be isolated from both the root volume group and /usr. This is often accomplished via NIS and the NFS automounter.
• backup & recovery tool
In the event that additional data will need to be restored from backup media, time can be saved by including all of the backup and recovery software (such as Omniback) within the system image.
Creating a Recovery Tape
The make_recovery(1m) tool creates a bootable system recovery tape for an LVM or whole disk system while it is up and running. When a system has a logical volume layout, the recovery tape will only include data from the root vol-ume group, plus data from any non-root volvol-ume group containing /usr. make_recovery is capable of creating system recovery tapes for all DDS tape devices, with the ability to span multiple tapes. For systems that support HSC SCSI cards, DLT tape devices can be used to create system recovery tapes. Root-user privileges are required to execute make_recovery.
1. With the Ignite-UX recovery tools installed on a system, insert a blank, writable tape into the default tape drive (usually found at /dev/rmt/0m) and run make_recovery:
# make_recovery -A -C
The -A option backs up every file in the root disk/volume. The -C option allows the check_recovery command to monitor how much has changed on the system since the tape was made.
It is recommended that the recovery tape be created when the system is quiescent to minimize change. No soft-ware should be installed or removed while the recovery tape is being created.
2. Ensure that you have a good full backup of your system. The make_recovery utility was not designed to replace standard backup procedures. The software required to restore data from the full backup should be included in the recovery image.
3. Review the log files:
/var/opt/ignite/logs/makrec.log1 #Logs progress reports
/var/opt/ignite/logs/makrec.log2 #Logs an Index of filesets stored on tape
Loading a Recovery Image from Tape
If it is determined that a new system state (such as that created through the loading of a new set of patches) is unac-ceptable, the previous environment can be restored from the image on the recovery tape. To load the image:
Ignite-UX
1. Insert desired system recovery tape into the tape drive and boot the system.
A running system may be rebooted with:
/sbin/shutdown -r or
/usr/sbin/reboot
The boot process will begin automatically when the system is initially turned on.
2. Interrupt the boot process.
The boot process can only be controlled from the system console. As the system begins to boot, the console will display a message describing how to halt the current boot. This usually involves pressing and holding a key down.
Consult the Owner’s Guide for your system for more information.
This should result in reaching a system prompt within the boot ROM code.
3. Locate the tape drive (if needed)
If the hardware path to the tape drive is not known, the system can search for all bootable devices at this point. The system firmware that provides this and other operations may vary. The Owner’s Guide for each system class may provided more information. They can be found at http://docs.hp.com/hpux/systems.
4. Boot from the recovery tape
Once the tape drive hardware path is known, or if the alternate boot path has be set to the tape drive, the system can be directed to load from the recovery tape:
Main Menu: boot scsi.#.0
5. Recover latest backups.
Some data or configuration information may not be included within the recovery image. Once the system has booted successfully, recover these files from alternate sources. Please note that critical files on the recovered sys-tem (such as /etc/lvmtab and /etc/fstab) should not be overwritten by those found on a backup. Use options that preserve newer versions of files during the restoration.
The make_net_recovery Utility
Ignite-UX A.2.0, B.2.0 and later versions allow you to create recovery archives via the network onto a specified sys-tem. You can either use the Ignite-UX server GUI (/opt/ignite/bin/ignite) or run /opt/ignite/bin/make_net_recovery on a client system. Use the Ignite-UX server interface to recover specified systems on the net. Systems can be recovered across subnets from a boot tape using make_boot_tape(1m), local boot server or the bootsys(1m) tool from an Ignite-UX server.
Archival and recovery using make_net_recovery(4) has several advantages over using tapes:
• Tape-management is eliminated, since system archives are centralized on a user-designated system disk. This results in less media-management time.
• Customization is possible, within the condition that no file or directory which is essential to HP-UX can be excluded. The Essentials List is visible to the user in /opt/ignite/recovery/mnr_essentials. This information can also be overridden by creating /var/opt/ignite/recovery/mnr_essentials
• Configuration of the recovery archive is controlled either via the Ignite-UX server user interface, or generated via a command-line/cron job from a client. For file, directory, or volume selection, an interactive selection screen (GUI mode) can be used on the server.
• Networked recovery is especially useful on systems which lack an internal tape drive, such as the A-Class and N-Class systems.
• Creation of recovery archives and associated config files can be monitored and inspected either from the Ignite-UX server, as with the install process, or at the client where make_net_recovery(4) is run.
System Reinstallation
The interactive setup is similar to that for an Ignite-UX server, requiring a networked system with enough disk space for the recovery archive and configuration information. For full information on make_net_recovery, consult the Ignite-UX Administrators Guide available from http://docs.hp.com.
System Reinstallation
While not the preferred method for system recovery, when no other options are available the final answer is to start over and perform a full system installation. Even this most basic of recovery strategies can benefit from planning.
Installation Optimizations
Think for a moment of your most critical system. Could you reinstall it right now? If so, how long might it take? Con-sider the following:
• Media Library
Where are the tapes and CDs that are required to rebuild the system? If they are kept in a central library, could you identify the person who is currently using the media that you need? Is there an index that lists which systems require a given set of media? Remember to account for systems and peripherals that require a specific patch level!
• Network Depots
While tapes and CDs should be available, they are not known for high performance. By creating depots on hard disk and sharing over the network it is likely that performance will be greatly enhanced. In addition, multiple sys-tems can share the network depot while media should be considered fit for only serial access.
• Ignite-UX
If Ignite-UX is used for the original system installation, it may be used to reinstall. Just as the network depots are an improvement over installation from media, Ignite-UX allows multiple network depots and archives of system
"golden" images to be used together as a part of a single installation.
The Wish List
When the need for system recovery arises, there is often only time available to take action. For this reason maintain a wish list of system changes to help you take advantage of the failure.
• File System Layout
If the recovery option requires that the root volume group be recreated (such as reinstallation or Ignite-UX recov-ery image) it is an opportunity to change the number and size of logical volumes. If any filesystems were built too small, such as /var, this is a great time to adjust the partitions. For best results with file system modifications, Ignite-UX version 2.2 or later should be used.
• Hardware Modifications
While the extent of the hardware changes will be limited by time, performance optimizations such as adding another SCSI controller or replacing an older root disk with a larger, faster model can be accomplished at a rela-tively small incremental cost.
Performance tools such as HPs GlancePlus can be used to identify performance bottlenecks. More information on GlancePlus may be found through the internet at Software Depot (http://software.hp.com) and HP OpenView (http://openview.hp.com/products/).
• Kernel Tuning
If the system is going to be brought down, what kernel parameters were not changed in the past to avoid the
sys-System Reinstallation
CHAPTER 3
Acquiring Patches
There are many reasons to patch an HP-UX system. The patches selected and the scheduling of their installation depend upon many factors, and different environments may lead to different but equally valid answers.
Once these factors are understood, you are left with a need to acquire the patch or patches to be loaded. There are sev-eral methods that can be used, with most playing some part within the IT Resource Center (ITRC). The ITRC is a web-based environment available at http://ITResourceCenter.hp.com.
For those with the highest levels of system support, Hewlett-Packard provides proactive patch analysis. These support levels limit the need for dedicated patch resources with H-P selecting and monitoring the correct patches for your sys-tems. These options are not within the scope of this document, consult with your local H-P sales representative for more information.
The Patch Database
The Patch Database is the primary mechanism for searching for and acquiring patches for Hewlett-Packard custom-ers. Listed within the IT Resource Center as the "Individual Patches" selection of the "Maintenance and Support"
area, it provides support for all operating systems and hardware. Figure 1 on page 10 shows the initial view seen when entering the Patch Database. This document will discuss two of the listed options, "HP-UX Patches" and
"Retrieve a Specific Patch".
As this document is being prepared (January 2000), significant enhancements to the Patch Database are underway.
These will be described in a future version of this document.
Searching for HP-UX Patches
The "HP-UX Patches" link of the main Patch Database screen leads to the "Searching and Browsing" screen. The first step identifies the system architecture and version of UX. In Figure 2, the checkbox for a series 700 running HP-UX 10.20 is selected. The next step requires the search string and mode.
Two search modes are currently supported. In the Descriptive mode, a phrase, sentence, or question is entered. The
The Patch Database
In a boolean search, the keywords are directly entered with optional logical operators. While not in conversational language, a well-built boolean search should provide the quickest method returning the fewest target patches.
Figure 2 shows the preparation for a boolean search that will return only patches that match both "LVM" and "Mir-rored". Boolean search results are limited to displaying 200 documents of the total which qualify.
The precedence of boolean operators in a search are:
The precedence of boolean operators in a search are: