HP-UX Patch Management

Transcription

1 HP-UX Patch Management A guide to patching HP-UX 11.X systems B January Hewlett-Packard Company

2 Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty. A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your local Sales and Service Office. Restricted Rights Legend. Use, duplication, or disclosure by the U.S. Government Department is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR for other agencies. HEWLETT-PACKARD COMPANY 3000 Hanover Street Palo Alto, California U.S.A. Copyright Notices Hewlett-Packard Company, all rights reserved. Reproduction, adaptation, or translation of this document without prior written permission is prohibited, except as allowed under the copyright laws. Trademark Notices. UNIX is a registered trademark of The Open Group. HP-UX Release and later and HP-UX Release and later (in both 32 and 64-bit configurations) on all HP 9000 computers are Open Group UNIX 95 branded products. Adobe and Acrobat are trademarks of Adobe Systems Incorporated. 2

3 Document History January Preliminary Edition. This Edition documents new features applicable to the HP-UX operating system. This guide's printing date and part number indicate its current edition. The printing date changes when a new edition is printed. (Minor corrections and updates which are incorporated at reprint do not cause the date to change.) The part number changes when extensive technical changes are incorporated. New editions of this manual will incorporate all material updated since the previous edition. Unix Development Lab Hewlett-Packard Co E. Harmony Rd. Fort Collins, CO HP-UX Patch Management 3

4 4

5 CHAPTER 1 Introduction 1 Overview Other Sources of Information Web Sites CHAPTER 2 Planning for Recovery 3 The Value of Recovery Options The Root Volume Group Practice Data Separation Preserving Configuration via NIS Ignite-UX Ignite-UX File System Guidelines Creating a Recovery Tape Loading a Recovery Image from Tape The make_net_recovery Utility System Reinstallation Installation Optimizations The Wish List CHAPTER 3 Acquiring Patches 9 The Patch Database Searching for HP-UX Patches Requesting a Known Patch Dependency Analysis and the Patch Database The Fulfillment Server Accessing the Fulfillment Server via ftp(1) Accessing the Fulfillment Server via web browser The FFS Directories Downloading the patch Custom Patch Manager Benefits of Custom Patch Manager Collect Configurations Perform Patch Analysis Managing Patch Depots with CPM Custom Patch Notification Support Plus Media The Bundle Matrix Mounting the CD Support Plus CD-ROM Layout Sharing Support Plus with Remote Systems Setting Up Hard Disk Access Requesting Support Plus CD-ROMs Software Depot The Support Plus Software Additional Core Enhancements (ACE) Hardware Enablement (HWE) Product Updates Specialty Patch Bundles HP-UX Patch Management v

6 CHAPTER 4 Depot Management 31 Custom Depots Benefits of Creating Depots Types of Depots HP-UX 10.X vs. 11.X Depots Patch Depots Periodic Patch Depot Critical Fix Patch Depot Patch Hubs Creating a Patch Depot Preparation Tasks Copying Existing Depots Combining Patch Depots Dependency Analysis Depot Access Depot Registration SD Access Control Lists (swacls) CHAPTER 5 Patch Installation 37 System Preparation Backups, Backups, Backups! A Note on Change Management System Activity Patch Committal Planning for System Reboot When is a Reboot Needed? Timing of the Reboot Installation Using the SD Matching Operations Installing to a Committed Patch State Finishing Touches The swverify command Checking the Logs Erroneous Errors and Warnings Appendix A Basic Patch Concepts 43 Patch Mechanics Ancestors and Patches Patch Supersession Patch Rollback Patch Commitment Patch Dependencies Dependency Types The HP-UX Patch Patch Status The Critical Patch Patch Identification The Patch Shar File vi

7 Appendix B SD Tools & Objects 49 The Basic SD Object Types The Fileset The Product The Bundle The Depot Patch-related Object Attributes ancestor applied_patches applied_to category_tag is_patch is_sparse is_reboot patch_state readme software_spec state supersedes superseded_by Introduction to the SD Commands The swinstall Command Synopsis Patch-related Command Line Arguments Patch-related Options Examples The swcopy Command Synopsis Patch-related Command Line Arguments Patch-related Options Examples The swremove Command Synopsis Patch-related Command Line Arguments Patch-related Options Examples The swlist Command Synopsis Patch-related Command Line Arguments Patch-related Options Examples The swreg Command Synopsis Patch-related Command Line Arguments Patch-related Options Examples The swmodify command Synopsis Patch-related Command Line Arguments Patch-related Options Examples HP-UX Patch Management vii

8 The swpackage command Synopsis Patch-related Command Line Arguments Patch-related Options Examples The cleanup Command Synopsis Patch-related Command Line Arguments The show_patches Command Synopsis Patch-related Command Line Argument : Other Options and Aids to Using the SD Commands Software Specifications Session Files Setting Default Options Appendix C The Patch Text File 71 The Patch Text File Fields Patch Name Patch Description Creation Date Post Date Hardware Platforms - OS Releases Products Filesets Automatic Reboot? Status Critical Path Name Symptoms Defect Description SR Patch Files what(1) Output Patch Conflicts Patch Dependencies Hardware Dependencies Other Dependencies Supersedes Equivalent Patches Patch Package Size Installation Instructions Special Installation Instructions viii

9 CHAPTER 1 Introduction HP-UX system patching has historically been one of the most confusing areas for new administrators to come to terms with. Patching has its own terminology and tools and patch management its own motivations and methods. While some documentation exists, it is usually found piecemeal in the back sections of various manuals. This tutorial is intended to contain all of the technical information required to understand HP-UX patching. While still under development, this initial version is being released both to share information and to collect comments and requests for future content. This tutorial is not intended to communicate patch strategies. These will be covered in other white papers available for that purpose. Please send your questions and comments to patchguide@hp.com. If appropriate, include page numbers and document revision with your comments. Overview This tutorial is built around the concept of the patch depot. Patch depots are a mechanism through which systems can be managed as groups rather than as individual systems. The chapters provide information regarding the steps required to create and use patch depots, while supporting information is provided as the appendices. The current set of chapters and appendices are: Chapter 2: Planning for Recovery The first rule of system management should be to expect the best, but plan for the worst. Planning for recovery can create a virtual "Undo" button that allows a system to return to a previous state. Not only does it protect systems from the unexpected, by limiting risk it can provide the confidence needed to support a proactive patching methodology. This chapter discusses the basic requirements and some options for system recovery. Chapter 3: Acquiring Patches Patches are available from a wide variety of sources, each with different abilities. Some sources may require certain levels of support while others are free. This chapter describes an array of patch sources and how they may be used to acquire patches. Chapter 4: Depot Management However patches are acquired, to be used efficiently a patch depot should be created. In this chapter the types of patch depots and their use are covered. HP-UX Patch Management 1

10 Other Sources of Information Chapter 5: Patch Installation Once a depot has been created, its contents must be installed on the target systems. This chapter describes the recommended 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 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 available for browsing, download, or purchase. 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. 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. 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 ( should be reviewed to learn about all of the benefits of membership. 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 To join the list itself, send the command: subscribe hpux-admin-digest in the body of a message to "majordomo@dutchworks.nl". 2 Introduction

11 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 configuration 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 condition 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. As with so many things, the power and flexibility of LVM can be used in ways that can help or hinder system management. The volume group that contains the core system, also known as the root volume group (usually named vg00), must be set up properly in order to enable the recovery options discussed in this chapter. HP-UX Patch Management 3

12 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 minimum 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 critical data regardless of the volume group, what you consider to be critical 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 documents are available from 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, Ignite-UX is available free of charge. To download the latest version or browse Ignite- UX documentation, go to 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. 4 Planning for Recovery

13 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 volume group, plus data from any non-root volume 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 software 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 unacceptable, the previous environment can be restored from the image on the recovery tape. To load the image: HP-UX Patch Management 5

14 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 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 system (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 system. 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. 6 Planning for Recovery

15 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 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? Consider 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 systems 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 recovery 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 relatively 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 ( and HP OpenView ( Kernel Tuning If the system is going to be brought down, what kernel parameters were not changed in the past to avoid the system downtime? This is another area that monitoring tools such as HPs GlancePlus can help identify opportunities. HP-UX Patch Management 7

16 System Reinstallation 8 Planning for Recovery

17 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 several 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 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 systems. 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 customers. 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 HP-UX. In Figure 2, the checkbox for a series 700 running HP- UX 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 common words are ignored and up to 60 patches that best fit the remaining keywords are selected. This option allows for basic search strings in the form of a question without requiring special syntax. One example would state "Is there a JFS patch for Autoraid disks?". HP-UX Patch Management 9

18 The Patch Database FIGURE 1. Patch Database Main Screen 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 "Mirrored". Boolean search results are limited to displaying 200 documents of the total which qualify. The precedence of boolean operators in a search are: Expressions inside parentheses () NOT, AND OR Expressions are processed from the left to the right in the Search String. You can use parentheses to alter the order of evaluation whenever necessary. Where there is more than one expression inside parentheses, the expressions are evaluated following the same order of precedence. As an example, the search string "tape or compression and drive" will retrieve documents that contain "tape", and will also retrieve documents that contain both "compression" and "drive". 10 Acquiring Patches

19 The Patch Database FIGURE 2. Patch Database HP-UX Search Screen Note that case sensitivity may apply to the Search String. An all UPPERCASE or all lowercase search string yields a case-insensitive search. A MixedCase search string yields a case-sensitive search. The results of the boolean search are seen in Figure 3. Listed are the patch name, size in bytes, and a one line description of the patch. Each patch name is a link to the patch documentation. The pages for individual patches are discussed in the following section, Requesting a Known Patch. HP-UX Patch Management 11

20 The Patch Database FIGURE 3. Patch Search Results Requesting a Known Patch Often the name of a desired patch is known before entering the IT Resource Center. Rather than constructing a search for the known patch, it can be directly requested through the "Retrieve a Known Patch" section of the Patch Database. Figure 4 shows the patch identifier entered and the Retrieve button selected. FIGURE 4. Retrieve a Specific Patch 12 Acquiring Patches

21 The Patch Database The result of retrieving patch PHKL_16750 in this manner are identical to that encountered when the link to PHKL_16750 is selected after the patch search above. At the top of the page are two options for downloading the patch shar file. By pressing the Download button the patch will be retrieved via HTTP through the web browser. Also shown is a link to the Fulfillment Server (FFS) described in more detail on page 14. FIGURE 5. Listing of Individual Patch (PHKL_16750) HP-UX Patch Management 13

22 The Fulfillment Server The bottom section of the page contains the detailed patch documentation describing the structure and purpose for the patch. This documentation is described in Appendix C, The Patch Text File. Dependency Analysis and the Patch Database A recent improvement to the Patch Database is the availability of expanded patch dependency data. It was formerly required that the patch text file be checked for any listed dependencies, and each then be checked in turn for its own dependencies. This has changed with the introduction of the IT Resource Center. Any listed patch with known patch dependencies will display a "Find All Dependencies" button as seen in Figure 5. As a single patch may support more than one architecture and HP-UX release, a specific environment must be selected from a list of all supported environments in order to perform the dependency analysis. In the case of PHCO_16750 only HP-UX and series 700 systems are applicable. The patch dependencies in the.text file list the earliest patches to meet the requirements. Commonly listed patch dependencies are replaced with newer patches. When the patch database performs a dependency analysis, patch supersession and recalls are taken into account and the list of patches returned are the newest available to fulfill the requirements. The dependency analysis for PHKL_16750 can be seen in Figure 6 on page 15. This list is the minimum set of active patches required to be loaded with PHKL_ Each patch is listed using a link to its own documentation as well as the size and one line description of the patch. It is possible that a patch may currently be unavailable and this will be indicated in the "Patch Size" column. This should be a temporary situation and rarely encountered. The web page also allows individual downloads of each patch. These individual patches can then be combined into a single depot for installation within a single swinstall session. This is discussed in Chapter 4, Depot Management, on page 31. The Fulfillment Server The fulfillment server (FFS) is the patch repository used by the Patch Database. All of the patches that are directly accessible by customers are kept online and may be retrieved via FTP. Two FFS systems are currently available dedicated to different geographic locations, us-ffs.external.hp.com for the Americas and Asia/Pacific and europeffs.external.hp.com for Europe. There are several methods, including the Patch Database, to access the Fulfillment server. The best one to use will depend upon what access to the Internet is available. Other options involve direct access via the ftp(1) command or using an ftp URL in a web browser. Accessing the Fulfillment Server via ftp(1) If a system that supports the ftp(1) command is available with direct access to the Internet a link to an FFS server can be established. The FFS servers limit the number of ftp connections that may be active in parallel. A direct connection has the benefit of maintaining a single connection for the duration of the session. If the FFS system is under a high traffic load it may take several attempts to establish a connection, but that single connection can be used for many requests before it is terminated. In Figure 7, the /usr/bin/ftp command is used on an HP-UX system to connect to the Americas/AP FFS system. For general use, a personal account is not required and an anonymous session may be started. When prompted to enter a name, anonymous should be given. The anonymous account is used by convention to allow general access to a set of files and directories. When prompted for a password, proper nettiquette is to supply your current address. 14 Acquiring Patches

23 The Fulfillment Server FIGURE 6. Dependency Analysis Results (PHKL_16750) The session should be set to transfer files in binary mode (bi) and toggled to allow the transfer of multiple files (prom). HP-UX Patch Management 15

24 The Fulfillment Server FIGURE 7. Establishing an anonymous FTP session patchsvr(103)-> ftp us-ffs.external.hp.com Connected to hpcc933.external.hp.com Welcome to the HP Electronic Support Center ftp server You are user 0, and there is a limit of 200 simultaneous accesses Log in as user "anonymous" (using your address as your password) 220-to retrieve available patches for HP-UX, MPE/iX, and other platforms If you are a user of other HP ESC services, log in with your 220-HP ESC User ID and password to deposit or retrieve your files If you have questions, send to: support_feedback@us-ffs.external.hp.com hpcc933 FTP server (Version wu-2.4, HP ASL, w/cns fixes (277) Wed Jun 24 18:02:04 PDT 1998) ready. Name (us-ffs.external.hp.com:username): anonymous 331 Guest login ok, send your complete address as password. Password:username@hp.com 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> bi 200 Type set to I. ftp> prom Interactive mode off. ftp> Accessing the Fulfillment Server via web browser Most web browsers generally in use today support multiple protocols. While they spend most of their time following the Hypertext Transfer Protocol (HTTP) addresses used for web pages, several other protocols are usually available. The File Transfer Protocol (FTP) is one of the more useful protocols. By entering the address "ftp://us-ffs.external.hp.com" into a properly configured web browser, an anonymous ftp connection to the FFS system is established. This allows access through a firewall via a proxy server as well as providing a graphical interface for browsing the remote directories. One drawback of this type of access is that the connection must be reestablished for each request. If the server is busy the connection limit could require repeated attempts before any request is successful. The FFS Directories Once a connection is established, several subdirectories are of interest to anyone working on an HP-UX system. Please note that direct access of the FFS system works best when downloading a known patch. However, this method limits your options for patch selection. With that in mind, some of the more useful subdirectories are: 16 Acquiring Patches

25 The Fulfillment Server FIGURE 8. Connecting to the Fulfillment Server via Netscape /hp-ux_patches/architecture/os_release/ (HP-UX patches) All active HP-UX patches are found grouped by their architecture (s700, s800, and s700_800) and the version of HP-UX supported (10.X, 11.X). For example, patches for workstations (series 700 systems) on HP-UX are found in the /hp-ux_patches/s700/10.x subdirectory. Note that patches common to both architectures are found under s700_800. /firmware_patches/hp (Firmware patches for HP Hardware) Patches supplying firmware updates to HP hardware are found under this directory. Subdirectories exist for firmware specifically for CPUs, Fibre Channel, graphics cards, and I/O cards. /export/patches This directory does not deliver any patches, but provides useful data files. The hp-ux_obs_patch_list file contains a full list of every patch that has been superseded with the name of the active superseding patch. The hpux_patch_matrix lists all patches that address known security issues for each release. The hpux_patch_sums file contains the checksum for the.depot file of all HP-UX patches. HP-UX Patch Management 17

26 Custom Patch Manager Patch directories contain not only the full shar(1) archive, but also the patch text file. The text file contains the patch location within the FFS hierarchy as the Path Name field. Downloading the patch Download the patch via the get or mget commands within FTP, or by saving it to a file from the browser. Using Netscape, this can be done by right-clicking on the patch link and selecting the "Save Link As..." option from the popup menu. The shar(1) archive may deliver 8-bit (or binary) data, but is encoded to contain only 7-bit characters. When files of this type are transferred through other systems (such as personal computers) they may be treated as text and undergo a translation step. It is best to avoid this by specifying that a binary transfer method is to be used. This may be done with the bi command with the ftp(1) utility. Custom Patch Manager Custom Patch Manager (CPM) is a tool for selecting and downloading patches that are appropriate for a target system. CPM is accessed within the Electronic Support Center (ESC) section of the IT Resource Center (ITRC) as the "Customized Patch Bundles" link. CPM is currently provided at the phone-in level support agreement or above. Certain geographical areas now have the ability to access CPM on a pay-per-use basis (consult the ITRC for details). Benefits of Custom Patch Manager While not a free service, the Custom Patch Manager provides significant value. These include: Current Patches and Information The patches and patch information available to CPM are updated daily. A system analysis has access to all patch information that exists, no need to wait until morning for an expert. Automated Dependency & Conflict Analysis Even if you only want a single patch, by selecting it through the CPM process you will automatically have dependencies selected and available. While it is always recommended that you review the patch documentation, the need for a lengthy dependency analysis is eliminated. Registered Patch Usage When a patch is downloaded via CPM (or the Patch Database) the ITRC account used is registered as having acquired it. In the event of a critical issue or patch recall, a notification is sent directly to the account with full details. Status Checks With information updated daily, it is an easy task to update the collection script and perform an analysis on a regular schedule. For example, a weekly check of new critical patches could help identify a system risk before it is seen in production machines. This can be done manually, or through the Custom Patch Notification service.. 18 Acquiring Patches

27 Custom Patch Manager FIGURE 9. Custom Patch Manager Main Screen FIGURE 10. Executing the cpm_collect.sh script $ sh cpm_collect.sh Copyright (c) Hewlett-Packard All Rights Reserved. cpm_collect.sh version: A This script will collect information about filesets and installed patches from your system in the file /tmp/grendel.fs for subsequent transfer to Hewlett-Packard. Do you wish to continue, [Y] or N?Y removing /tmp/grendel.fs Creating list of patches in /tmp/grendel.fs... The file /tmp/grendel.fs has been created. HP-UX Patch Management 19

28 Custom Patch Manager Collect Configurations The first step requires that the cpm_collect.sh script be downloaded to your system. This shell script will collect the names and revisions of all the products installed on your system. It is available from the "Collect Configurations" section off of the main CPM page. It is recommended that the script be downloaded on a regular basis. It is a quick procedure that ensures the use of the latest version of the script. Once copied to the target system, it can be executed as shown in Figure 10. The script does not require special privileges, and creates a data file using the name of the system followed by a ".fs" suffix This data file must be returned to the ITRC via ftp(1). The ftp system to use will be identified on the same ITRC page used to download the collection script. When prompted by your ftp(1) client, your ITRC user and password should be supplied. Once connected, the data file produced by the collection script should be placed within the incoming subdirectory on the ftp server. Please note that this directory is subject to space limitations. Perform Patch Analysis Upon entering the "Perform Patch Analysis" section, a list of the current configuration files found within the incoming directory is displayed. After the appropriate configuration file is selected, the candidate patch list can be displayed. By default, this list will contain every active patch that is applicable to the target system. This default can be overridden by filters that can be set from any screen that can generate a candidate patch list as shown in Figure 11. These filters can be changed and the candidate list regenerated. At some point, some or all of the patches in the list must be selected. This can be done individually using the check box associated with each patch, or globally via the "select/deselect all" buttons at the bottom of the list. As an aid in this selection process, each patch in the list is hyperlinked to detailed information on its content (seen in Figure 12). The patches marked in the candidate list become the selected patch list seen in Figure 13. This list includes additional information on patch age, size, and dependencies. Also shown is if the patch will require a system reboot as a part of the installation process. If desired, patches can be removed from the list at this point. Below the selected patch list is an option to perform a conflict analysis. While optional, it is urged that the step is always a standard part of the CPM process. The results of this analysis for our list of critical patches is shown in Figure 14. Two conflicts are reported, one structural in nature and the other involving a missing dependency. The structural conflict is a warning that a file is found in more than one patch stream. This is a rare occurrence that when encountered can lead to unexpected behavior when a patch is effectively partially superseded. A structural conflict may not exclude the selected patch, but will generally imply special handling. In this example of a file collision, it may be sufficient to ensure that the currently installed patch is not removed unless the selected patch is removed first. The dependency conflict is fairly common. The generated patch list was filtered to include only critical patches, but patch PHNE_20021 has a dependency on a patch that is not itself critical in nature. This patch can be reviewed by following the link to its information page. From the individual patch page, a button is available to add the required patch to the selected list. Once all of the issues have been addressed, the Package button is used to begin preparing the patches for downloading. At this point, a script is generated and placed within the outgoing subdirectory for your account on one of the FTP servers (CPM will direct you to the appropriate server). This script is a self-extracting shell archive that (when executed on a Unix system) will extract scripts and instructions on acquiring the full list of selected patches. As patch availability is dynamic, the patches should be promptly retrieved. At this time the automated patch scripts are supported only from a standard Unix platform. When internet access is through a PC, the patches must be retrieved through the Patch Database or the FFS server. 20 Acquiring Patches

29 Custom Patch Manager FIGURE 11. Candidate Patch List and Filters The selected patches will be transferred individually to the local system. One of the scripts delivered in the shell archive is used to place all of these patches into a common depot for future installation. Managing Patch Depots with CPM Custom Patch Manager is a powerful tool, but tools can be used in many ways. The following sections will describe the mechanics of running CPM on a single system, but for many the need is to control groups of systems. Managing the patch level of these systems individually is possible, but Hewlett-Packard recomends managing them through a common patch depot (see Chapter 4, Depot Management, on page 31). CPM allows direct analysis of a software depot via the depot_collect.sh script. It is similar to the cpm_collect.sh script used for system analysis, and will not be described in depth. This can be a convenient method to update or check status on an existing depot, but dependency and conflict checking are not currently supported within depot analysis. HP-UX Patch Management 21

30 Custom Patch Manager FIGURE 12. Individual Patch Details (PHKL_20508) FIGURE 13. Selected Patch List 22 Acquiring Patches