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 [email protected]. 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 "[email protected]". 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: [email protected] 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:[email protected] 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

31 Custom Patch Manager FIGURE 14. Results of Analysis of Selected Patch List Another method uses one system as representative of all systems supported by a single depot. The results of a CPM analysis of that system is used to update the depot and track status. This method provides the maximum coverage available from the existing CPM checks. Custom Patch Notification The Custom Patch Notification feature of Custom Patch Manager provides you with weekly or monthly notification of newly posted patches which apply to your configuration. This tool differs from the Support Information Digests by allowing you to narrow down the list of patches you are notified about (by using configuration files and filters) and customize the report contents. There are three main components of Custom Patch Notification: Profiles, Preferences, and Reports. Profiles are used to specify the different reports you want to receive. You may either select a CPM configuration file for notification, or take a broader approach and simply specify a platform and OS revision. Additionally, you may select one or more filters to have applied to your list including critical, keyword, and the different patch categories. You may create up to 10 profiles at which time you must remove an existing profile if you want to create a new one. To remove a profile, simply modify a profile, select the Remove Profile checkbox and press the OK button. The preference screen allows you to verify your HP Electronic Support Center address to which the notifications will be sent. If you need to modify this address, use the User Info link at the top of the screen. You only have one ESC address, so changing it will affect where all s you receive from the HP Electronic Support Center will be sent. HP-UX Patch Management 23

32 Support Plus Media You also have the ability to specify whether you want to receive your reports on a weekly or monthly basis. The reports are not cumulative from week to week or month to month. Weekly reports will be sent out on Sundays, while the monthly reports will be generated on the last day of the month. Finally, you have the ability to specify what patch text fields are displayed when you view your on-line report. These fields can be changed and the report re-loaded if you want to view the same report with different filters set. You will be notified via when new patches are posted which apply to your profile. This notification will include applicable patch names and one-line descriptions for each profile you maintain. To get more information about these patches, simply login to Custom Patch Manager and view the full reports on the Custom Patch Notification Main screen. You have the ability to specify which fields are displayed in the report by selecting the Patch Report Fields. Profile names may only contain alphanumeric characters (a-z,a-z,0-9,_). The first character of name must be a letter. A profile may be based off either a Custom Patch Manager configuration file or a platform and OS revision. To use a current configuration file, simply select the radio button next to the configuration file on which you want your notifications to be based. New configuration files can be added by downloading the cpm_collect.sh script and uploading the results as described in the instructions. Custom Patch Notification does not work with depot configuration files. Alternatively, you may specify a platform (i.e. 9000/735, 9000/855) and OS revision (i.e. A.09.07, B.10.20) for a profile. You can use the uname(1) command on your system to determine what values to enter in these fields. Platform field : uname -m OS Revision field : uname -r If you go from a configuration based profile to a Platform/OS revision based profile, you need to press the Reset button to clear the configuration file table so only the platform and revision fields are filled in. Custom Patch Notification makes use of the Critical filter and the four patch categories (Command, Kernel, Network, and Subsystem) to narrow patch notification lists down to only those patches you are interested in. Critical: Lists all patches which have been tagged as critical by the HP-UX patch administrator. Command, Kernel, Network, Subsystem: Display patches which relate to one or more of the major patch categories. All HP-UX patches are included in one of the four main patch categories: Command, Kernel, Network or Subsystem. Custom Patch Manager will not allow you to de-select all the categories as you would never receive any patch notifications. When used with each other, these category options act as a logical OR. For example, if you pick the Command and Kernel options, you are asking to be notified of all patches which are related to the Command OR Kernel patch categories. The logical relationship between the category options and the Critical filter is the AND operator. (i.e. If you pick the Critical, Kernel and Command filters, you are asking Custom Patch Manager to notify you of all patches tagged as Critical AND are in the Command OR Kernel categories.) Support Plus Media HP-UX Support Plus CD-ROMs deliver diagnostics and HP-UX system patches. This software enables new hardware and fixes known defects. In some cases, a patch may deliver new software functionality. Support Plus combines the contents of the former Diagnostic/Independent Product Release (IPR) and Extension Software Release (XSW) CDs. 24 Acquiring Patches

33 Support Plus Media Support Plus does not create a new HP-UX release. Existing HP-UX releases are updated by a dedicated version of the Support Plus media. Currently both HP-UX and versions of Support Plus are available. The Bundle Matrix A variety of patch bundles are provided on each Support Plus CD. They may be installed directly to a system, or used as the basis of a custom patch bundle. The Bundle Matrix (shown below in Table 2) lists the HP-recommended usage and description of each bundle. Please note that the bundles listed in the following table are supported on HP-UX workstations or servers running HP-UX Table 1: The Support Plus Bundle Matrix (HP-UX 10.20) If your platform is: And you want to: You should install: Updated: OnlineDiag bundle from the depot Quarterly /cdrom/diagnostics/b Install specific diagnostic tools EMS-Config, EMS-Core, Predictive, Sup-Tool-Mgr-700, Sup-Tool-Mgr-800, or other products from the depot Quarterly /cdrom/diagnostics/b Install stable, Y2K, critical, & third party recommended patches with full OS release testing for selected Core OS products Quality Pack (QPK) bundle delivered in /cdrom/700qpk1020 Semiannually HP-UX workstation Enable new add-on hardware (as directed by documentation with new hardware purchases) Hardware (HW) enablement bundle for HP-UX workstations: /cdrom/xsw700hw1020 Quarterly HP-UX workstation Get additional Core OS and Y2K patches from the full set of general release patches General Release (GR) bundle for HP- UX workstations: /cdrom/xsw700gr1020 Quarterly HP-UX server Bring all Core OS software to current patch level without custom patch selection General Release (GR) bundle for HP- UX servers: /cdrom/xsw800gr1020 Quarterly HP-UX server Enable new add-on hardware (as directed by documentation with new hardware purchases) and install critical or Y2K patches Hardware/Critical (HWCR) bundle: /cdrom/xsw800hwcr1020 Quarterly HP-UX Patch Management 25

34 Support Plus Media Table 2: The Support Plus Bundle Matrix (HP-UX 11.00) If you want to: You should install: Updated: Enable new add-on hardware (as directed by documentation with new hardware purchases) and install critical or Y2K patches Bring all Core OS software to current patch level (without custom patch selection), including current Core OS Y2K changes Install all of the latest diagnostic tools Install specific diagnostic tools Hardware/Critical (HWCR) bundle from: /cdrom/xswhwcr1100 General Release (GR) bundle from: /cdrom/xswgr1100 OnlineDiag bundle from /cdrom/diagnostics/b EMS-Config, EMS-Core, Predictive, Sup- Tool-Mgr-800, or other products from /cdrom/diagnostics/b Quarterly Quarterly Quarterly Quarterly Mounting the CD The Support Plus CD must be physically attached to a system and mounted before the contents can be installed. If the CD is not mounted on the system to be updated, any required depots may be registered once the CD has been mounted. The following steps can be used to mount a Support Plus CD: 1. Open a terminal window and become root on your system. 2. Put the Support Plus CD into the drive. Wait for the busy light to stop blinking. 3. Define a new directory as the mount point for the CD drive. For example, to define /cdrom as the mount point, enter: mkdir /cdrom 4. Identify the drive device file with ioscan. Root user privileges are required: # ioscan -fnc disk Class I H/W Path Driver S/W State H/W Type Description ======================================================================= disk 0 8/0/19/0.6.0 sdisk CLAIMED DEVICE SEAGATE ST34572WS /dev/dsk/c0t6d0 /dev/rdsk/c0t6d0 disk 1 8/16/5.2.0 sdisk CLAIMED DEVICE TOSHIBA CD-ROM XM-5401TA /dev/dsk/c1t2d0 /dev/rdsk/c1t2d0 The block device (dsk rather than rdsk) file is used. In the example above, the file is /dev/dsk/c1t2d0. 5. Mount the CD drive to the mount-point directory: mount -r /dev/dsk/c1t2d0 /cdrom If the CD drive s device-file name is not clt2d0, use the name you found using ioscan in Step 5 above. 6. You can now access the CD via the mount-point directory. For example: # ls /cdrom Support Plus CD-ROM Layout Support Plus is structured as a multiple depot CD. To support this functionality depots are provided within subdirectories. No software is delivered at the CD top level directory. When accessing these depots via the interactive versions of swinstall or swcopy on the system hosting the mounted CD, the source depot type is local directory, not local CDROM. 26 Acquiring Patches

35 Support Plus Media HP-UX Patch Management (PDF) A version of this document appropriate to the release of HP-UX is present at the top directory on the CD. PDF files can be read or printed from the Adobe Acrobat viewer. Viewers for HP-UX and other platforms are available from the Adobe web site ( Support Plus Users Guide (PDF) A brief, printed users manual is provided within the Support Plus CD packaging. This guide is also provided within the root directory of the CD in the PDF format. Patch Bundle Depots Each patch bundle described within the Patch Matrix is delivered within a top-level subdirectory that is given the same name as the bundle it contains. These depots and not the CD mount point should be used as the source for all swinstall or swcopy sessions. Patch Bundle Readme Files (text) Each bundle has its own.readme file, (for example, /cdrom/xswgr1100.readme). This file contains additional installation instructions, notes about problems in previous releases, a list of patches (and their dependencies) in the bundle, changes since the last release, and a listing of disk space usage. One exception is the documentation for the diagnostics bundle. This is found under the DIAGNOSTICS subdirectory. Diagnostics Directory Diagnostics provided include Support Tool Manager (STM) for online diagnostics, ODE (off-line diagnostics), EMS hardware monitors, Predictive Support (S800 only), and EMS Kernel Resource Monitor. Depots and documentation for all of these products are found in the DIAGNOSTICS subdirectory. Sharing Support Plus with Remote Systems To enable direct access from other systems, you must register a Support Plus bundle with the swreg(1m) command. For example, to register the XSW800GR1020 bundle if the Support Plus CD is mounted to /cdrom: 1. Register the depot: swreg -l depot /cdrom/xswgr When finished, disable remote access by unregistering the depot before unmounting the CD: swreg -u -l depot /cdrom/xswgr1100please be aware that most CD-ROM drives are not optimized for parallel access. If multiple installation sessions must be supported concurrently, it is recommended that depots be created on hard disks. Setting Up Hard Disk Access If more than two systems must access a depot, or if you cannot dedicate the CD drive to the Support Plus media, HP recommends that you copy the patch depots to a hard disk using the swcopy(1m) command. For example, with the CD mounted at /cdrom, use: swcopy -s /cdrom/xsw800gr1020 /var/tmp/mydepot This copies the contents of the XSW800GR1020 bundle and depot to the local system under the /var/tmp/mydepot directory. The new depot is automatically registered for use by remote systems. Requesting Support Plus CD-ROMs The contents of each Support Plus release is freely available (see Software Depot on page 28) but physical media is only available to customers with any level of HP-UX Software Support contract. A letter will be sent to announce the availability of each release. HP-UX Patch Management 27

36 Software Depot Included within the letter will be a request form. The form will list the support contract ID, or system handle, and number of copies currently entitled to that handle. After specifying the desired number of CDs and any address updates, the form can be returned by fax or using the provided prepaid envelope. Software Depot The HP Software Depot ( is an online store that provides you with instant access to HP software for free trial and for purchase. The store offers a highly satisfying shopping experience, since you may purchase products you need at your convenience, and, in many cases, you may also have the opportunity to evaluate the product through a free trial. Software Depot also provides a number of different patch products. These patch products are generally available at no charge and are found in the "Enhancement Releases" area of Software Depot. While free, registration may be required prior to any download of the software. The Support Plus Software The patch bundles and diagnostic utilities of the Support Plus CDs are provided for free download from Software Depot. The support contract restrictions related to the actual media do not apply to electronic access. As an added benefit, the bundles are available within Software Depot earlier than on media. For more information on Support Plus downloads, visit Additional Core Enhancements (ACE) An ACE bundle is a collection of enhancements to the HP-UX Operating System. Each ACE release extends HP-UX to support new hardware and software features for Hewlett-Packard workstations (s700). In addition to extending the capabilities of HP-UX, the ACE software corrects any critical or serious defects discovered since the original system release. Other than correcting defects, ACE software does not modify the behavior of the base operating system. After you load ACE software on your computer, the version of HP-UX will not change. Newly-released ACE bundles are cumulative; (i.e. each release of a particular ACE bundle supports everything the previous release of that bundle supported, plus the additional features that prompted the new release.) The Quality Pack bundles described above are associated with the ACE program and may be accessed from ACE pages and media. An ACE CD-ROM is an installation media, containing both the ACE patch bundles and the original HP-UX Core. Software Depot provides the ACE patch bundles alone for download, and they may be accessed from the web site found at the address. Hardware Enablement (HWE) HWE bundles and media are similar to the ACE products. They are created to provide support for new servers (s800) on existing releases. As with ACE, an HWE CD-ROM is an installation media, containing both the HWE patch bundles and the original HP-UX Core. Software Depot provides the HWE patch bundles alone for download, and they may be accessed from the web page. Product Updates Some HP-UX products release a new version rather than a patch. These can be downloaded from Software Depot. Some products available at this time include Ignite-UX , DNS-BIND 8.1.2, Sendmail 8.8.6, and JFS Acquiring Patches

37 Software Depot Specialty Patch Bundles Occaisionally, special needs dictate the creation of a unique patch bundle. Recent examples have included patches for year 2000 (Y2K) defects and support for the new european currency (Euro). These patch collections are primarily supported on special Hewlett-Packard web pages, but are also found within Software Depot as well. HP-UX Patch Management 29

38 Software Depot 30 Acquiring Patches

39 CHAPTER 4 Depot Management Depot management is a method to simplify systems management by defining a common reservoir of software to be shared by a group of systems. While the mechanics of system administration remain, the work of defining and testing a new configuration of software can be centrally managed. Custom Depots A depot is a software container present on disk, tape, CD-ROM, or network that is used as a software source for the swinstall(1m) installation utility. Custom depots can be constructed in a number of different ways, and are a powerful tool for managing software. Benefits of Creating Depots There are many reasons to create customized depots. Separation of Patch Management From System Management Patch management requires a number of unique skills and is an ongoing task. Adding the overhead of patch management to system administrators limits the number of systems that each can control. By defining a depot, a centralized team can define and support a standardized configuration to be used by many administrators. Streamlined Installation When software is acquired as multiple depots and/or media, combining all software into a single depot allows for a single installation session to load everything. For patches that cause kernel rebuilds, the combined depot would result in a single reboot regardless of the number of patches installed. Remote Administration It may be that the system is in a remote location, or maybe just far enough away to be annoying, but it is not uncommon to want to administer a system without ever seeing it. By creating registered depots, installations can take place without the need to mount media. Types of Depots There are two distinct types of depots: directory and tape. Both styles are common and while the basic function of each is identical there are advantages to each in certain situations. HP-UX Patch Management 31

40 Patch Depots A tape depot is a single data file that is accessed in a serial manner. While not only found on tape media, the format is specifically designed to support software delivery on tape media. It is also a convenient method to allow a depot to be transferred over a network without using the SD swcopy command. The best example of this is the.depot file delivered within any patch shell archive from the Patch Database or Fulfillment Server (see Chapter 3, Acquiring Patches, on page 9). A directory depot contains each packaged file, as well as SD infrastructure, as distinct files in a directory hierarchy. While this format is not readily transferable like the tape depot, it is much better suited to parallel access. Also known as a network depot, this type is recommended when creating a depot to be accessed from remote systems. When the term depot is used in this document, it can be assumed that a directory depot is implied. HP-UX 10.X vs. 11.X Depots Beginning with HP-UX 11.0, patching was significantly enhanced by extending the abilities of the Software Distributor tools. The price of these new abilities was to introduce several new attributes to the SD objects. The layout_version attribute is used to differentiate the between the old and new, with 10.X depots identified by the value 0.8 and 11.X depots marked by 1.0. It is possible to use depots of layout_version=0.8 on an HP-UX 11.X system to provide software for use on HP-UX 10.X systems. Several problems related to serving depots for HP-UX 10.X from HP-UX 11.X have been identified, and it is recommended that patch PHCO_20078 (or current replacement) is installed prior to creating the depots. If an HP-UX 11.X depot is copied to an HP-UX 10.X system or layout_version=0.8 depot, data will be lost and the depot corrupted. Patch Depots Patch selection, analysis, and monitoring are some of the more difficult administrative tasks required for HP-UX systems. Creating dedicated patch depots is a great way to avoid duplicating this effort. Several different types of patch depots have been shown to be valuable. Periodic Patch Depot A periodic patch depot is created to define the current recommended patch level. Periodic depots are generated on a regular basis that will vary according to the needs of a user. It may be done quarterly to match the availability of the Support Plus media, monthly to ensure a more timely inclusion of critical fixes, or just in advance of any scheduled system downtime to take advantage of the opportunity. The critical aspects of such a depot are that they have been tested on the target configuration, and no dependencies are missing. Once created, production systems need only install with an SD matching operation to load the required patches. Critical Fix Patch Depot When a periodic patch depot has been created, it often represents a significant investment in testing and analysis. There are many arguments against changing such a depot after it has been released, but it is also true that there is always the possibility that a system will encounter a problem requiring a new patch. In these environments, it may be useful to create a depot that contains fixes to known problems in the current environment. This depot can be used to update any system that encounters a known failure, as well as a starting point for the next version of the periodic depot. As with the periodic depots, dependencies of the patches in the depot should also be included. 32 Depot Management

41 Patch Depots Depending on the severity or probability of a given failure, it may be advisable to place a newer patch in both the periodic and the critical fix depot. Patch Hubs While not recommended for general use, it is not uncommon to desire a "kitchen sink" depot that contains every patch that may ever be needed. It may be used as a method to conserve disk space, or as a local resource to ensure local access to any needed patch. For whatever reason, such a patch hub is no longer suitable for general use and the results of an SD matching operation does not produce a defined or neccesarily tested environment. It is recommended that a patch hub is unregistered or be given restricted access (see Depot Access on page 36). Providing direct access to a patch hub can be done, but provides the system administrator with a variety of ways to perform an incorrect operation that could leave a system in an unknown state. If the risks are understood and are acceptable, alternate mechanisms may be used to define subsets of the full patch hub. Patch Bundles Patch bundles may be acquired from HP directly, or created using the IUX make_bundles command or externally available tools such as those available through the Interex Users Group (see the paper "Creating Custom Patch Bundles" by Dominguez & Scott in the Interworks 1998 proceedings or through Such a bundle can be explicitly selected for installation, but numerous issues exist. See Chapter 5, Patch Installation for more on this topic. Software/Session Files Both a software file (specified with the -f option) and a session file (specified with the -C option) provide a mechanism to explicitly select a set of software. Session files provide the additional ability to specify SD options in addition to the software list. This can be particularly useful when working with bundle wrappers. Category Tags Introduced to patches in HP-UX 11.00, category tags are attributes that can be used to mark a patch. The swmodify command can be used to add an arbitrary category tag to existing patches. The advantage of category tags over patch bundles or software/session files is that they may be used with the patch_filter and a matching operation to avoid the problems of explicit selection. For example, swinstall -x patch_match_target=true -x patch_filter=*.*,c=p2000_q1 -s /hub would select all of the patches in the /hub depot that include the category tag P2000_Q1. The requirement of including all dependencies remains. The swmodify command is used to create new category tags. To define the P2000_Q1 category used above, after listing all selected patch filesets in the file P2000_Q1.list issue the command: swmodify -a category_tag=p2000_q1 -f /hub At this time there are known issues with category tags, such as the lack of a working mechanism to delete them. With time it is expected that the value, robustness, and usage of category tags will increase. Directly specifying bundles, patches, or patch filesets from the swinstall user interface or a software or session file is known as explicit selection. For software to be explicitly specified within a swinstall session without reported errors, all of the filesets specified must be able to load. For example, this would require separate bundles containing only 32- or 64 bit filesets.. An alternative to explicit selection is to swcopy the patches included in the bundle or software/session file to its own depot where a matching operation can be used successfully. HP-UX Patch Management 33

42 Creating a Patch Depot Creating a Patch Depot Once the decision has been made to create a patch depot and the patches have been selected and acquired, it is time to create a depot to house them. The more individuals, systems, and depots involved, the more time and energy should be devoted to preparation. Even if you are the only person to use the depots, creating the right environment today can help support any changes the future may bring. Preparation Tasks There are a number of issues to consider before a depot is put into production. Naming a depot One of the features of the SD interactive user interfaces is the ability to select from a list of available depots on a system. It is particularly useful to specify a depot path that identifies the contents if several different depots and/or depot revisions are present. For example, /depots/order_db/y2000q1 might contain the periodic patch bundle for the first quarter of the year 2000 to be used on systems hosting the order entry database. Disk Considerations Depot operations can involve a significant amount of disk activity. Disk space must be available, and if the depot usage is expected to be high the performance of the disk devices and interface cards must be taken into account. If the availability of the depot is critical, high availability storage solutions such as disk arrays or mirroring should be considered. Network Considerations Not only should the performance of the networking interfaces be taken into account, location within the network should be considered. Both the performance of the server and the impact on others are to be addressed. If groups of remote systems are accessible only via a congested or expensive link, creating mirror depots may be a valuable option. Compression Depots are created in an uncompressed state by default. Both disk space and network bandwidth can be conserved by setting the swcopy option compress_files to true. Depot Access When a depot is created using swcopy, it is automatically registered. If the final form of the depot will require more than a single swcopy, the depot should be made inaccessible during the creation process. This can be done by setting the option register_new_depot to false during the initial swcopy session. Copying Existing Depots All SD packaged software exists in a depot. As this document will not address the creation of a patch, it can be assumed that an initial depot is always available. A depot can be copied to a directory depot using the swcopy command, or to a tape depot via the swpackage command. The following example shows how a depot on the default tape drive could be copied as /depots/testdepot to the current system while ensuring that all files are compressed: swcopy -s /dev/rmt/0m /depots/testdepot The swcopy command is described in more detail within the swcopy(1m) man page or in The swcopy Command on page 56. Combining Patch Depots When multiple patch depots are combined, each is simply copied in turn. This may result in the depot containing patches and their replacements together. While an installation using such a depot should be successful, the superseded patches will never be used and are a waste of disk space. 34 Depot Management

43 Creating a Patch Depot Superseded patches can be removed from a depot via the cleanup(1m) utility (delivered by patch PHCO_19550 or current replacement). When given the -d option and the full path to a depot, cleanup will remove any superseded patches within the depot. For testdepot created above, this would be done via: /usr/sbin/cleanup -d /depots/testdepot If any superseded patches are found, they will be listed and the user asked if they should be removed. Dependency Analysis When patches are manually selected, a critical step is to perform a dependency analysis of the selected patches. This section will describe a manual process to find all required dependencies. While other methods are available to perform this analysis, this description provides a clear understanding of the work involved. In Figure 15, two supersession chains are shown that have a mutual dependency. The supersession chains are each in a vertical column, with the older patches on the bottom. A patch dependency is indicated by a dashed arrow pointing from a patch to the patch it is dependent on. In this scenario, a critical fix found in PHNE_17051 is needed. The analysis goes through the following steps: 1. The PHNE_17051 text file is read, and the dependency on PHNE_17017 is noted. 2. PHNE_17017 is not available, and is in fact a recalled patch. It is determined via the Patch Database that the active member of the supersession chain is PHNE_ Patch PHNE_19899 has a dependency on PHNE_ The Supersedes section of the patch text file or Patch Database show that PHNE_18972 has replaced the originally desired patch PHNE_17051, and a dependency on PHNE_17662 is noted. 4. Checking PHNE_17662 indicates that it has been replaced by the previously selected PHNE_ At this point, no unresolved dependencies remain and patches PHNE_18972 and PHNE_19899 can be loaded onto the system. While the original patch (PHNE_17051) is not loaded in the end, the cumulative nature of HP-UX patches ensures that all of the needed functionality is included in the newer PHNE_ FIGURE 15. Example of Inter-Patch Dependencies PHNE_18972 PHNE_19899 Patch Dependency Supersession Chain PHNE_17662 PHNE_17051 PHNE_17017 HP-UX Patch Management 35

44 Depot Access Both the Patch Database and Custom Patch Manager sections of the IT Resource Center can help identify and acquire patch dependencies. Chapter 3, Acquiring Patches has more information on these and other areas. Depot Access It may be desirable to restrict access to depots. This could be due to entitlements, training, geography, or the depot not being prepared for production. Two mechanisms exist to restrict access, depot registration and access control lists. Depot Registration A registered depot is visible and accessible to remote systems. When unregistered, a depot remains accessible on its own system without being visible to remote systems. For patch depots, this is usually sufficient for most needs. Registration tasks are done using the swreg(1m) command. This is described in depth in The swremove Command on page 59. SD Access Control Lists (swacls) If complex access control is required, the swacl(1m) command provides the ability to restrict access to a high level of granularity. Access rights can be specified for individual products within a depot and given to individual users on specific systems. The rights can be further divided by the type of access granted. A full description of swacls is beyond the scope of this document. Consult the swacl(1m) man page or the Software Distributor documentation available from 36 Depot Management

45 CHAPTER 5 Patch Installation This chapter describes a basic process for performing the installation of patches onto an HP-UX system. While not the only method available, it provides a general checklist of tasks that can be used as a starting point for a local process. It is assumed that prior to installation the following tasks have been completed: A current system recovery image has been completed. Patches have been selected and acquired. The installation depot contains all dependencies. Information on these steps may be found in other sections of this document. System Preparation While the depot is ready, there is more to be done to prepare for any system modification. Backups, Backups, Backups! While this document only addresses issues involving system software, this is not meant to infer that data is not important. If there is any question regarding the stability or reproducibility of the user data it must be resolved before proceeding. While disk arrays and mirroring provide terrific protection from hardware failures, software failures and operator error are not hindered in their destructive ability. While the risks may be small, the costs can be huge. A Note on Change Management When working with multiple systems and system administrators, it can be easy for confusion to lead to mistakes and/or complicate analysis of system failures. Computer systems are complex environments and system administrators are often driven by constant and critical interruptions. In a large environment it may be beneficial to create a formal change control process for critical systems. Some of the aspects of such a process include: HP-UX Patch Management 37

46 System Preparation Clear Ownership of each Change The submitter of a change request becomes the initial owner of a task. By requiring a formal handoff to any new owners, the individual responsible for executing the change can quickly be identified. Change Review and Approval By requiring a period of review and authorization, senior administrators and management can provide guidance and ensure that business needs are not controlled by technical decisions. Centralized Change Database By keeping change records on a central system, they are not lost when a system failure is encountered. The database can be constructed to provide access to the experience of other administrators as well as visibility of upcoming changes to system users. While less valuable in smaller operations, a growing data center should consider implementing a change control process before it is needed. System Activity The Software Distributor tools rely on DCE and networking support for even the most basic functions. For this reason, most documentation has recommended that the system be in run-level (init) 2 or higher. These are multi-user states that are usually associated with active systems. This is not meant to indicate that updates should take place on active systems. Both the initial state prior to the installation and the final state upon completion should be supported and stable environments. During the installation process, system files, libraries, and commands are gradually changed. Scripts may kill and restart daemons. Commands and libraries may not match the currently running kernel. The system is between supportable configurations. Experience and recovery planning should be your guide. Applications that are not critical should be halted, and no new processing should be started. Remember that the risk is not only to the failure of an application, but to the system being left in a partially installed and corrupted state. Patch Committal When installing a large numbers of patches, such as a Support Plus patch bundle, it is not uncommon for some of the patches to already be present or superseded on the target system. If it becomes necessary to return to the initial state by removing the new patches, patches that were already there may be inadvertently removed. If a superseding patch present before the install is removed, the superseded patch that was to have been loaded will not be present. Each of these conditions can result in a patch required to fulfill a dependency being removed. One method that can be used to avoid these issues is to perform a system-wide commitment of all patches prior to the installation of the new set. This causes the initial patched state to become the minimum system environment. The committed patches cannot be removed, and the current patch level becomes a low-water mark. An attempt to remove all active patches can only delete those that are newly delivered. The recommended method for performing a system-wide patch committal is through the cleanup utility. Delivered by patch PHCO_19550, the -F option directs cleanup to commit active and superseded patches. This not only sets a hard floor to the patch level, it also reclaims the disk space required to support rollback operations. While patch committal has benefits, there is also a cost. If a committed patch must be removed, the patched products must be reinstalled to provide the older versions of files. Selected reinstallation and IPD modification can be a complex and risky operation. Prior to patch committal, it is strongly recommended that a recovery image is created. This image can be used if needed to return to the uncommitted state. Patches should also never be committed without an immediate need. 38 Patch Installation

47 Planning for System Reboot Planning for System Reboot The core of the HP-UX operating system is known as the kernel. Most kernel (PHKL) and many networking (PHNE) patches require that the kernel be rebuilt and restarted. While solutions for the future are under investigation, the only method currently available to restart an HP-UX kernel is to shut down and restart the system. When is a Reboot Needed? Each patch "knows" if it will require a system reboot to install on a system, but how can you tell? A flag is recorded both within the patch documentation as well as a fileset attribute within the patch itself. In addition, the interactive versions of the swinstall command will display a dialog that announces the required reboot. A depot can be checked for patches requiring a reboot by using the swlist command to display the is_reboot attribute of the patch filesets. Any filesets with this attribute set to true will reboot the system if loaded. The patches in a local depot (/MyDepot) can be checked with the following: swlist -d -l fileset -a is_reboot /MyDepot grep true Timing of the Reboot In System Activity, the fact that the system is in an unknown state until the installation process completes is discussed. It should now be made clear that this ambiguous condition exists until any required system reboot and configuration steps are completed. Not only is a reboot often required, but it should also not be unecessarily delayed. Despite this and the cautions regarding system activity, it is certain that at times users and applications will remain active during an install and need to be prepared before a reboot can occur. This becomes an issue when the swinstall command line interface (CLI) is used. The CLI will not allow an installation that will require a system reboot to begin unless the an override option (-x autoreboot=true) is specified. If specified, the autoreboot option instructs swinstall to reboot the system whenever it is required. While useful for automated and unattended installations, it does not allow any time or warning before the system is halted. Installation The work was concentrated in creating the depots and with the preparation complete the installation should be simple and quick. There are complex methods of patch installation, and some are mentioned in this document. Unless a special need exists, avoid using them unnecessarily. The goal is to have all systems at a common level with the least amount of overhead. Using the SD Matching Operations In the HP-UX 10.X releases, patches were generally selected and installed using the match_target option of swinstall. This was an improvement over manual selection of patches but there were several problems: The match_target option applied to both patches and non-patch software in the same depot and there was no way to ensure that the patches and non-patch software would be installed in the correct order. This complicated the process of software updates and required that patches be kept in a separate depot. SD had no way to determine whether some patches in a depot were superseded by other patches. Patches that were superseded had to be manually removed from a depot. All patches in the source depot that corresponded to software on the target system were selected. There was no way to filter them according to their type or level of severity. HP-UX Patch Management 39

48 Installation Three options were added in HP-UX to improve management of patches. These are: -x autoselect_patches=true false (default=true) -x patch_match_target=true false (default=false) -x patch_filter=<selection> (default="*.*") The autoselect_patches option is used when installing software. If patches that apply to the software selected (by a swinstall or swcopy command) are present in the source depot, they will be selected and installed with the software. For example, the command: swinstall -s /mydepot MYPRODUCT by default, also will select and install any patches applying to MYPRODUCT that also exist in the source depot. The benefit to the user is that a separate swinstall session is not required to install patches to a product; they can be applied during the initial installation or update of the software. Once a software product has been installed, the patch_match_target option is used to select patches from a depot which correspond to a product installed on the system. This is most often used to install the proper set of patches from a patch bundle. Note that in HP-UX 11.00, the match_target option has been modified so that it applies only to non-patch software (as identified by the is_patch attribute). For example, the following command installs patches from a depot which correspond to currently installed software products: swinstall -s /mydepot -x patch_match_target=true -x autoreboot=true Finally, you have additional control over patches selected when using either autoselect_patches or patch_match_target through the use of the patch_filter option. Each patch contains tags (the category_tag attribute) which characterize the patch. For example, to install only patches with a category_tag of "mytag" that apply to a system: swinstall -s /mydepot -x patch_match_target=true -x autoreboot=true -x patch_filter="*.*,c=mytag" The patch_filter option can also be applied in conjunction with the autoselect_patches option to control which patches are selected when software is initially installed. It must be emphasized that as with depots, any subset generated through a patch_filter operation must not have external dependencies. No current H-P provided categories meet this criteria, but users can create tags of their own. Installing to a Committed Patch State Patch commitment may take place during patch installation, or after the fact. If it is desired that the patches be installed directly into a committed state, the swinstall option "-x patch_save_files=false" may be used. From the interactive user interfaces, this is done by selecting the "Save files replaced by patch for later rollback" option. There are two different methods that may be used to commit patches after they have been installed. The cleanup utility (delivered via patch PHCO_19550 or current replacement) provides a simple interface consistent with the version provided on HP-UX 10.X releases, and the swmodify command allows the patch commitment to be managed down to the fileset level with the "patch_commit=true" option. Both commands are discussed in more detail in The cleanup Command on page Patch Installation

49 Finishing Touches Finishing Touches Once the installation has completed, a few final steps are required. These verify the actions taken and begin the preparations as the next cycle begins. The swverify command Software Distributor maintains a database of software that it controls known as the Installed Products Database or IPD. The swverify command is provided as a method to compare the data within the IPD with the actual system directories and files. When verifying installed software, swverify checks software states, dependency relationships, file existence and integrity. The swverify command can be used to verify a patch bundle or even a single patch, but it is recommended that a wildcard be used to verify all products and patches on the system. This can be done using: swverify \* Checking the Logs Each SD command logs messages to /var/adm/sw/sw<task>.log, where task is the name of the command. This contains a terse summary of command activity. (You can specify a different logfile by modifying the logfile option. See the SD manual for more information.) A swagent process performs the actual operations for each many SD commands, including swinstall, swcopy, and swremove. This log file is much more complete. For example, it includes the output from installation scripts, which would not be in the command log file for swinstall. This log is located at /var/adm/sw/swagent.log. For depot operations, swagent logs messages to the file swagent.log beneath the depot directory (for example, /var/spool/sw/swagent.log). If you experience problems with one of the SD commands, the swagent log is a good place to look for more information. The cleanup command can help you manage SD log files. See Cleanup Command on page 22. Erroneous Errors and Warnings Unfortunately, some errors and warnings output by a SD install or verify do not indicate serious problems. Hewlett- Packard is aggressively addressing and correcting this issue with newly created patches and software. Examples of false errors and warnings are shown below and most likely refer to incorrect mtime, cksum, mode, owner ID and group ID. These are usually artifacts of incorrect patch creation and are typically not indicative of a real system problem. Some examples: WARNING: Directory "/usr/sam" should have mode "555" but the actual mode is "755". WARNING: Directory "/usr/sam" should have group,gid "bin,2" but the actual group,gid is "sys,3". WARNING: Fileset "SW-DIST.SD-FAL,l=/,r=B.10.20" had file warnings. ERROR: File "/opt/graphics/common/bin/gamma" had a different mtime than expected. ERROR: File "/opt/graphics/common/bin/gamma" should have cksum " " but the actual cksum is " ". ERROR: Fileset "Xserver.AGRM,l=/,r=B.10.20" had file errors. HP-UX Patch Management 41

50 Finishing Touches Another potential false error involves missing files. This is often the result of the delivery of a file to and subsequent move from a temporary location or name. Some patches initially deliver files to a temporary location before moving them to the final location. When the file is delivered to this temporary location, the IPD is updated with this information. The file is then moved to its final destination by the patch scripts. Later, when the system is verified, the newly delivered file is looked for and not found in the initial delivery location resulting in a "file missing" error in the swagent.log file. A popular initial patch file delivery location is /usr/newconfig or as a.tmp file. Here is an example of a missing file error: ERROR: File "/usr/newconfig/usr/ccs/bin/ld" missing. ERROR: Fileset "PHSS_10764.PHSS_10764,l=/,r=B AA" had file errors. Missing files are a critical problem that deserves attention. However, at the current time, SD does not have a method for dealing with patches delivering files to and moving them from initial locations so it may be difficult to determine if a real problem exists. It is an issue that HP is working with patch creators to resolve in the future. In the meantime, you can resolve this problem if it occurs by looking for clues that the missing file was delivered under one name or location and then moved to a different name and location. Look for the /usr/newconfig and.tmp clues in the swagent.log file and locate the delivered file in its final destination to verify for yourself that it is not missing. For instance, in the above example, although the file /usr/newconfig/usr/ccs/bin/ld does not exist, the permanent file /usr/ccs/bin/ld will. A very similar false error to the above is the missing.o file. Before being archived into a library, a.o file will be delivered to a temporary location. The IPD is updated and then the file is archived to the appropriate library. When the system is verified, the.o is justly no longer found in the initial location resulting in a "file missing" error in the swagent.log file. An example is shown below: ERROR: File "/usr/conf/lib/vm_text.o" missing. ERROR: File "/usr/conf/lib/vm_vas.o" missing. ERROR: File "/usr/conf/lib/vm_vhand.o" missing. ERROR: Fileset "PHKL_10757.PHKL_10757,l=,r=B AA" had file errors. 42 Patch Installation

51 Appendix A Basic Patch Concepts Patch management differs in many ways from standard forms of software management. Certain terms and actions exist solely within the patch space. While it is possible to create a support solution without an understanding of these concepts, it would rely on external tools or people that do have an understanding. A patch is an incremental change to the released software. It may deliver defect fixes, performance enhancements, and in some cases new functionality. A patch may be loaded in reaction to a system failure, or to proactively avoid encountering a known problem in the future. This appendix defines the basic patch terminology and concepts. The specific details regarding execution are left to the following chapters. Patch Mechanics Ancestors and Patches Ancestry is one of the basic concepts of patch operations. The ancestor of a patch is defined as the preexisting software that is being modified or replaced. For a patch the delivers a new version of a single file, the ancestor delivered the original version of that file. While the concept of ancestry can be applied to a single file, in practice ancestors are managed between grouping of files known as filesets. Filesets will be discussed in detail in Appendix B: SD Tools & Objects. Working with groups of files, it is possible for several patches to modify a single product or for a single patch to modify several products. Figure 16 provides a simple example of the four filesets of product Prod being modified by the patch PHCO_0100. For HP-UX 11.X patches a fileset is created for each ancestor fileset, and is given the same name as that ancestor. The importance of this can be seen through a simple thought experiment of loading PHCO_0100 onto a system that has Prod installed without fileset FSD. When PHCO_0100 is installed, the system will determine that fileset Prod.FSD is not present, and will not load PHCO_0100.FSD. If Prod.FSD is loaded at a later date, the patch can be installed again, with only the PHCO_0100.FSD fileset actually being processed. HP-UX Patch Management 43

52 Patch Mechanics FIGURE 16. HP-UX 11.X Patch and Ancestors Product Prod Prod.FSA Prod.FSB Prod.FSC Prod.FSD Patch PHCO_0100 PHCO_0100.FSA PHCO_0100.FSB PHCO_0100.FSC PHCO_0100.FSD One Patch Multiple Filesets Patch Supersession Patches for HP-UX products are required to be cumulative. This means that any individual patch supplied by HP must completely contain all aspects of any preceding patch. The newer patch is said to supersede all earlier patches. A series of patches, each replacing the previous patch, forms a supersession chain. This is shown graphically in Figure 17. In general, the patch numbers will increase along a patch supersession chain. FIGURE 17. Patch Supersession Chain PROD.FS PHCO_1000 PHCO_2000 PHCO_3000 The SD-packaged product Prod, is initially patched by PHCO_1000. This patch is superseded by PHCO_2000 which is superseded in turn by PHCO_3000. When a patch is superseded, it remains on the system, but is not active. Only the top patch of the chain is in the active (applied) state.. Since patches are designed to be cumulative, it is not required to have all patches in a supersession chain installed. In fact, the presence of a superseding patch will prevent the installation of any preceding patch. If this were not the case, an older patch could replace files with older versions. Patch Rollback The installation of a patch differs from the installation of a product in several ways. One of the key differences is the ability to perform patch rollback to restore the pre-patched behavior. When a patch is loaded onto a system, the default behavior is to save copies of all files patched prior to loading the new versions. If the patch is removed, these saved files are restored. Only the active member of a supersession chain can be removed, but as each superseded patch returns to the active state it becomes a candidate for removal in future sessions. Figure 18 shows the save areas for the Prod.FS supersession chain of Figure

53 Patch Mechanics FIGURE 18. Patch Rollback PROD.FS foo.o,r=1.0 bar.o,r=1.0 PHCO_1000 PHCO_2000 PHCO_3000 foo.o,r=1.1 foo.o,r=1.1 foo.o,r=1.2 bar.o,r=1.1 bar.o,r=1.2 foo.o,r=1.0 foo.o,r=1.1 bar.o,r=1.0 foo.o,r=1.1 bar.o,r=1.1 Patch Save Area The Prod.FS fileset contains the relocatable object files foo.o and bar.o, both having a of revision 1.0. When PHCO_1000 is loaded, it delivers a new version of foo.o. When this happens, the version delivered with the original product (v1.0) is stored in a save area associated with PHCO_1000. When PHCO_2000 is loaded, it delivers a new version of bar.o. As a cumulative patch, it must also deliver the version of foo.o that was delivered by PHCO_1000, even though it did not change. The versions of foo.o and bar.o that are on the system before loading PHCO_2000 are then stored in the save area. Finally, patch PHCO_3000 delivers new version of both files, and the existing files on the system are preserved in a save area associated with PHCO_3000. If patch PHCO_3000 is removed from the system, the files found within its save area are restored to the system, and patch PHCO_2000 again becomes the active patch. Each patch could be removed in turn, eventually returning Prod.FS to the original state. Patch Commitment The rollback mechanism is not without cost. As can be seen in the diagram, cumulative patching ensures that the amount of change delivered by a patch will increase during the life of a supersession chain, and in some cases multiple copies of the same file will be preserved. The disk space used to support patch rollback may be reclaimed through patch commitment. When a patch is committed to the system, the associated save area is deleted and the patch cannot be directly removed. The product remains patched until updated to a new version or removed from the system. Because the information lost is of the state prior to the installation of the patch, reinstalling the committed patch will not restore the rollback ability. Also, if any patch in a supersession chain is committed, any prior patches lose the ability to be restored, and the save area disk space for those patches is also reclaimed. HP-UX Patch Management 45

54 Patch Dependencies Patch Dependencies To become fully active, a patch may require changes in other areas of the system. Because patches are cumulative, it is important that the areas affected by a single patch are limited. In these cases, a patch may document a dependency against patches responsible for these other areas. The different types of dependencies are documented in the text file or readme attribute of each patch. The.text file field(s) used will be noted as appropriate for each type. Dependency Types While the dependencies of a patch are generally quite simple, there are some cases where special types of dependencies may be encountered. Standard Dependency The standard dependency is an execution time software dependency without any exceptions or conditions. An example would be that the commands in PHCO_1000 cannot be used without the kernel support of patch PHKL_1234. Standard dependencies are documented in the Patch Dependencies field. Ordered Dependency An ordered dependency is an installation time software dependency without any exceptions or conditions, but the dependency must be loaded first for the requirement to be satisfied. These are documented in the Patch Dependencies field and/or the Special Installation Instructions field. Hardware Dependency Certain patches are only applicable to specific system models. These system-level dependencies are documented in the Hardware Dependencies field. Other Dependencies There are dependencies that cannot be described in a simple manner. These include optional dependencies that are required under specific circumstances or hardware dependencies below the system level. All such miscellaneous dependencies are explained in the Other Dependencies field. The HP-UX Patch An HP-UX patch is a partial delivery of software that fixes defects found in the original, or in some cases extends the original functionality. Each patch includes a set of properties that are documented in an associated text file. This section will examine some of these properties, the.text file is described in detail within Appendix C: The Patch Text File. Patch Status Almost every patch created is intended for general release to all customers, bu the patch may transition into different release states. The current release state, known as the patch status, can be found within the.text file and is also displayed when viewing patches within the ITRC. The data within the.text file reflects the initial state of the patch due to the static nature of the file. The ITRC data, and in particular the Patch Database itself, provide the current patch state. The following patch states are used by all patches that should be available to customers. Any value other than those listed here denotes a patch that should be restricted and used only with full understanding and great caution. 46

55 The HP-UX Patch General Release A status of General Release indicates a patch that is approved for widespread use and is the active member of the supersession chain. As the newest available patch, it will contain all known fixes to date for the target software. Special Release A special release patch is an active patch that was not intended for use by all customers. Patches may be created as special release if a set of customers require nonstandard behavior or configuration-specific change that would cause problems for others. General/Special Superseded When an active patch is replaced by a newer version, it enters the superseded state. Applicable to both General and Special Release patches, patch supersession should not be considered in a negative manner. While the newer patch should contain additional fixes, they may not be critical. The known qualities of an older patch may have greater value than the non-critical improvements. General/Special Recalled Under certain conditions, a patch may be recalled and removed from general distribution. As with superseded patches, each system administrator should review the issues documented in the recall notice with the value of the current patch fixes and cost of system change. Patches cannot be partially recalled, and while the generic recommendation will be to remove and replace the patch the correct action for a specific system may vary. The Critical Patch While each patch is created to improve upon the original version of the ancestor software, certain patches address issues of the highest priority and are considered critical. Patches are marked as being critical in response to the severity of a failure, and not the probability that it will be encountered. Examples of conditions that cause a patch to be marked critical include data loss, data corruption, system panic, or system hang. A patch can be classified into one of three categories: Not critical No part of the patch addresses a critical failure. While there may still be compelling reasons to install such a patch (such as a performance enhancment), there is no reason to take any immediate action. Critical The patch delivers a new fix for a critical failure. The severity of the defect is such that the patch should be evalutated for applicability to local systems and environments. Even customers that are extremely resistant to change may choose to proactively load the critical patch to avoid the associated failure. Not critical, but supersedes a critical patch The patch does not contain critical fixes, but delivers critical content that was introduced within a patch that has been superseded within the same patch chain. Patch Identification An HP-UX patch name consists of a four-character type identifier followed by an underscore followed by a four or five digit numeric field. The numeric field, called the patch number, is unique for a patch regardless of patch type. The currently defined patch types are: PHCO PHKL PHNE PHSS Commands and libraries Kernel Networking All other HP-UX subsystems HP-UX Patch Management 47

56 The HP-UX Patch This naming convention is not recognized by the HP-UX software management tools. HP-UX 11.X patches are also marked through the is_patch and is_sparse attributes and the patch category tag. For more information on these and other attributes, see Patch-related Object Attributes on page 50. The Patch Shar File The shar(1) utility is used to produce a shell archive file. Shell archives are a useful and portable method to package groups of files for transfer between Unix-based systems. When a patch is acquired individually from the Patch Database within the IT Resource Center (ITRC, formerly the Electronic Support Center or ESC) or from the Fulfillment Server (FFS), it is packaged as a shell archive. These sources are described in more detail in chapter 3, Acquiring Patches. When exercised by the shell, the patch shell archive will recreate two files within the current working directory. These are the.depot and.text files. The.depot file is an SD tape-style depot containing the actual patch. The.text file is the complete documentation for the patch, including descriptions of the symptoms and defects repaired by the patch, special installation instructions (if any), dependencies, and the list of files contained within the patch. 48

57 Appendix B SD Tools & Objects This appendix provides an overview of Software Distributor (SD) commands and concepts as they apply to patching. All patch operations involve some aspects of the SD tools. Although these tools are complex, you only need a small subset of SD functionality for patching operations. Some SD functionality is not appropriate for patching and you should avoid it (see Pitfalls and Traps on page 39). SD is included with the HP-UX Operating System and manages software on the local host only. To install and manage software simultaneously on multiple remote hosts from a central controller, you must purchase the HP OpenView Software Distributor, which provides extended software management capabilities. This appendix does not discuss SD operations involving alternate roots. This appendix does not present a comprehensive view of SD. For in-depth information, consult Managing HP-UX Software with SD. It is available from the Software Distributor web site ( or the Hewlett-Packard documentation web site ( The Basic SD Object Types Software Distributor uses a variety of object types. This section gives you a simplified view of the object types that relate to patches. You can find formal definitions in Managing HP-UX Software with SD and the sd(4) man page. The Fileset A fileset is one or more related files, grouped into a manageable unit. It describes a unique subset of the files that make up a product. A fileset may include scripts that control installation and removal. In general, patches are created and managed at the product level, and patch filesets are delivered only within a patch product. Therefore, you should avoid selecting patches at the fileset level, even though SD permits this kind of selection. Selecting patches by fileset level may cause a fix to be only partially applied. See Explicit Patch Selection on page 39 for more information. The Product An HP-UX patch is structured as a single SD product that contains one or more filesets. HP-UX 11.X patches that require customization include SD control scripts at the product level. HP-UX Patch Management 49

58 Patch-related Object Attributes The Bundle A bundle encapsulates products and filesets into a single software object. Bundles provide a convenient way to group software objects together for easy selection. More than one bundle can contain the same software objects. A bundle can be thought of as a virtual configuration of software. HP provides several types of standard patch bundles. See The Bundle Matrix on page 25 for more information. The Depot A depot is a directory that contains software products or bundles that are available for direct or remote installation. You can change the contents of a depot. A depot can also be a distribution media (e.g. tape or CD-ROM) or a single, serial file that contains products or bundles. Patch-related Object Attributes Each of the objects described in The Basic SD Object Types has a set of properties known as attributes. Attributes control aspects of patch behavior and define patch properties and relationships. The patch-related attributes are described below. You can view SD object attributes with the swlist command. See The swlist Command on page 60 for more information. ancestor Applies to filesets. Indicates the fileset that this fileset modifies. The following example shows patch PHKL_18543, which contains three filesets, each modifying a different fileset found on the HP-UX release. $ swlist -l fileset -a ancestor PHKL_18543 # PHKL_18543 PHKL_18543.C-INC PHKL_18543.VXFS-BASE-KRN PHKL_18543.VXFS-PRG ProgSupport.C-INC,fr=B.11.00,v=HP JournalFS.VXFS-BASE-KRN,fr=B.11.00,v=HP JournalFS.VXFS-PRG,fr=B.11.00,v=HP applied_patches Applies to base (non-patch) filesets. Lists all of the patch filesets that have modified this fileset. applied_to Applies to patch filesets. Contains the software_spec of the ancestor fileset that this patch fileset modified when it was installed. (See Software Specifications on page 67 for more information on software_spec.) category_tag Applies to filesets or products. 50

59 Patch-related Object Attributes Provides a label for a fileset or product. Several tags are defined during patch creation, and others may be created by customers with the swmodify command. A category_tag can be used as a selection mechanism (see Patch Hubs on page 33). is_patch Applies to both patch products and filesets. When set to true, is_patch indicates that the object is a patch. The is_patch attribute is required for patches to be managed via the autoselect_patches or patch_match_target options of swinstall and swcopy. is_sparse Applies to patch filesets. When set to true, is_sparse indicates that the current fileset is incomplete and cannot be loaded in the absence of the fileset s ancestor. This ensures that a patch fileset cannot be explicitly selected when not appropriate. is_reboot Applies to filesets. When set to true, is_reboot indicates that installation of the fileset will cause the system to reboot. patch_state Applies to patch filesets. In addition to the state attribute (also described in this section), which records the installation states of software, the patch_state attribute records the condition of patches. Patch filesets exist in one of three conditions, depending on the order of the patch operation: applied: An applied patch contains the software that is currently active on the system and is the most recent member of its supersession chain (of one or more patches) to have been loaded. A patch in the applied state has not been committed or superseded. committed: A committed patch cannot be directly removed from the system. A committed fileset is also in either the applied or superseded state (which state applies cannot be determined from the patch_state field). Common practice is to use the superseded_by field as a check for active patches. superseded: A patch in the superseded state has been replaced by a newer member of its supersession chain. A patch in the superseded state may or may not have been committed. readme Applied to products. The readme attribute of an HP-UX patch contains the text file. software_spec Applies to bundles, products, or filesets. The software_spec attribute (short for software specification) contains the fully qualified identifier for the bundle, product, or fileset. The software_spec contains the object name and any version or architecture information. See Software Specifications on page 67 for more information. HP-UX Patch Management 51

60 Patch-related Object Attributes state Applies to filesets. A fileset s state attribute (also used for non-patch software) provides useful information about the installation state of software. SD commands automatically keep track of software management operations by creating an Installed Products Database (IPD) and various "catalog files" that contain information about the software on the system. An SD operation leaves a fileset in one of the following states and records it in the fileset s state attribute. (Note that SD commands automatically keep track of software management operations by creating an Installed Products Database (IPD) and various catalog files that contain information about the software on the system. Some attributes are stored in the IPD only.): installed (IPD only): The software was successfully installed but not configured. Although not every patch requires configuration, HP recommends that you move all patches left in the installed state to the configured state with the swconfig command. The swconfig command is not discussed in this tutorial, consult the swconfig(1m) man page or Managing HP-UX Software with SD for more information. configured (IPD only): The product was successfully installed AND configured. No further operations are required. available (depot only): The software is ready for access. It can be used by a swinstall or swcopy session using the depot as the source. corrupt: Indicates that errors detected in the execution phase of a swcopy or swinstall process left the software in an unknown state and that the software should not be used. transient: Indicates that swinstall or swcopy was killed or aborted during the execution phase leaving the software in an unknown and incomplete state. The transient state differs from the corrupt state in that SD did not detect the failure when it initially occurred. supersedes Applies to patch filesets. Lists all prior filesets that a patch fileset supersedes. Note that all superseded filesets are included, but the ordering of the superseded filesets may not match the order of the supersession chain itself. superseded_by Applies to patch filesets. Records the software specification of the fileset that superseded the fileset on a given system. This attribute is only set for installed patch filesets, and never in software depots. 52

61 Introduction to the SD Commands Introduction to the SD Commands This appendix discusses the SD commands that relate to patching. The following list shows the commands, ordered by those most commonly used: swinstall - installs and configures software products. swcopy - copies software products for subsequent installation or distribution. swremove - unconfigures and removes software products. swlist - displays information about software products. swreg - registers or unregisters depots or roots. swmodify - modifies software product information in a target root or depot. swpackage - packages software products into a depot (directory or tape). All SD commands run from the command line. In addition, swinstall, swcopy, swremove, and swlist have an optional GUI mode. Additional concepts for using the SD commands are discussed in Other Options and Aids to Using the SD Commands on page 67. The swinstall Command The swinstall command is used to load patch software from a source depot and onto a target system. TIPS: Because many patches aren t designed for individual installation, the automatic matching options(autoselect_patches, patch_match_target) should be the preferred method for installing patches. swinstall has numerous options that you should not use for patching because they lack dependency support. HP recommends that you use only the options discussed below. Synopsis swinstall [-i] [-p] [-v] [-s source] [-x option=value]... [software_selections] Patch-related Command Line Arguments -i Use an interactive user interface. If the environment variable DISPLAY is set to a valid X windows display, a graphical user interface is invoked. Otherwise a terminal user interface (TUI) designed for use on ASCII terminals is invoked. The GUI starts by default if you enter swinstall without any software_selections. -p Previews the install operation without performing the actual installation. Preview mode is not enabled by default. -v Requests verbose mode. This option affects only standard output and not the log files. -s source Specifies the depot (source) containing the software to be installed. HP-UX Patch Management 53

62 The swinstall Command -x option=value Sets the specified default option to the value given, overriding any other values for that option. Patch-related default options are specified below. See Setting Default Options on page 68 for more information on setting defaults. software_selections One or more software specifications. See Software Specifications on page 67 for more information Patch-related Options You can change the command behavior by overriding the default options. These are changed on the command line with the -x option=value syntax, by various menu selections in the GUI, or by other methods (see Setting Default Options on page 68). The following options have the most relevance to patching. Where appropriate, default values are shown. (For the full set of available options, consult the swinstall(1m) man page or refer to Managing HP-UX Software with HP-UX. ). option=default value Menu Path in Interactive Interface Description autoreboot=false None (GUI waits for permission to reboot) Enables an automatic reboot upon completion of the software installation. autoselect_dependencies=true Actions: Autoselect dependencies (when marking software) When software is selected for installation with an SD-enforced dependency, that software will automatically be selected for installation if present in the source depot and autoselect_dependencies is set to true. While few patches exist with dependencies enforced by the SD tools, those that do employ them to enforce critical requirements of content and load order. This option should not be set to false unless directed by an HP Support Engineer. autoselect_patches=true Actions : Manage Patch Selection : Automatically select patches for software to be installed. When loading a software product, any patches within the same depot for that product will automatically be selected for installation. autoselect_reference_bundles=true None When set to true, any bundle wrappers within the source depot that contain software selected for installation will be automatically selected if the is_reference attribute set to true. Note that this does not mean all of the software listed in the wrapper will be selected, only the bundle wrapper itself. enforce_dependencies=true Options : Change Options : Enforce dependency analysis errors in agent Enforces software dependencies. When software is selected for installation with an SD-enforced dependency, if the dependency is not present on the target system and is not selected for installation from the source depot, installation will only proceed if enforce_dependencies is set to false. While few patches exist with dependencies enforced by the SD tools, those that do employ them are enforcing critical requirements of content and load order. This option should not be set to false unless directed by an HP Support Engineer. enforce_scripts=true Options : Change Options : Enforce script failures 54

63 The swinstall Command Each patch may have several installation scripts associated with it. These scripts may issue errors to protect the system from incorrect patch usage. This option should not be used unless directed by an HP Support Engineer. match_target=false Actions:Match What Target Has Selects all software within the source depot with an ancestor attribute that matches a fileset currently on the target system. While on HP-UX 10.X systems this option was used to select patches within a depot that applied to the target system, the patch_match_target option is the preferred method for HP-UX 11.X releases to provide this functionality. mount_all_filesystems=true Options : Change Options : Mount filesystems in /etc/fstab or /etc/checklist By default, swinstall requires that all filesystems listed in the systems /etc/fstab file are mounted prior to installation. Setting this option to false removes this restriction. patch_filter=software_specification Actions : Manage Patch Selection : Filter The patch_filter option can be used to specify a subset of software available to load. This option is not yet recommended for general use as no provision is made for dependencies. It can be a powerful tool for depot management when combined with user-defined category tags. patch_match_target=false Actions : Manage Patch Selection : Automatically select patches for software installed on the target Select all patches within the source depot that modify the existing system software. This is the recommended method to install patches from a managed depot (such as those provided by HP). patch_save_files=true Options : Change Options : Save files replaced by patch for later rollback If set to false, patches are loaded directly to the committed state and cannot be rolled back. While a convenient way to control disk usage, this option is not recommended unless alternative recovery mechanisms are available. See Chapter 2, Planning for Recovery, on page 3 for notes on other options. reinstall=false Options : Change Options : Reinstall filesets even if the same revision exists Prevents SD from re-installing (overwriting) an existing revision of a fileset. If set to true, filesets will be reinstalled. source_cdrom=/sd_cdrom None (default cannot be changed within GUI) Specify the device file of the CD-ROM to be used as the default. source_tape=/dev/rmt/0m None (default cannot be changed within GUI) Specify the device file of the tape drive to be used as the default. write_remote_files=false None Prevents installation of files to a target that exists on a remote (NFS) file system. By default, swinstall skips files that would be installed to a remote (NFS) file system (or that are already there). When set to true and superuser has write permission on the remote file system, the remote files are installed. HP-UX Patch Management 55

64 The swcopy Command Examples Install from a CD mounted and registered on the system grendel: swinstall -s grendel:/cdrom/xswgr1100 \ -x patch_match_target=true -x autoreboot=true Use the swinstall command s preview mode (-p option) to get an idea of what to expect for the bundle you want to install. For example: swinstall -p -s grendel:/cdrom/xswgr1100 \ -x patch_match_target=true -x autoreboot=true The swcopy Command The swcopy command copies software from one depot to another. This can be particularly useful if software exists in several depots. For example, you can copy all of the contents of individual patches into a single depot from which the group can be loaded in a single session and with a single reboot (if needed). Note that the swcopy command automatically registers (enables remote access to) any depot that it creates. You do not need to use the swreg command on depots created by swcopy. (See The swreg Command on page 63 for more information.) Synopsis swcopy [-i] [-p] [-v] [-s source] [-x option=value] [software_selections] [@ target_selection] 56

65 The swcopy Command Patch-related Command Line Arguments -i Use an interactive user interface. If the environment variable DISPLAY is set to a valid X windows display, a graphical user interface is invoked. Otherwise a terminal user interface (TUI) designed for use on ASCII terminals is invoked. The GUI starts by default if you enter swcopy without any software_selections. -p Previews the copy operation without performing the actual copy. Preview mode is not enabled by default. -v Requests verbose mode. This option affects only standard output and not the log files. -s source Specifies the depot (source) containing the software to be copied. -x option=value Sets the specified option to the value given, overriding any other values for that option. Patch-related options are specified below. See Setting Default Options on page 68 for more information on overriding defaults. software_selections target_selections One or more software specifications. See Software Specifications on page 67 for more information The absolute path name (directory location) to which you want the software_selections to be copied. If you specify a host with the directory, the syntax is host:/directory where the host name can be a name, domain name, or internet address. Patch-related Options You can change the command behavior by overriding the default options. These are changed on the command line with the -x option=value syntax, by various menu selections in the GUI, or by other methods (see Setting Default Options on page 68). The following default options have the most relevance to patching. Where appropriate, default values are shown. (For the full set of available options, consult the swcopy(1m) man page or refer to Managing HP-UX Software with HP-UX. ). option=default value Menu Path in Interactive Interface Description autoselect_dependencies=true Actions: Autoselect dependencies (when marking software) When software is selected for copying with a registered dependency on other software, that other software will automatically be selected to be copied if present in the source depot and autoselect_dependencies is set to true. autoselect_reference_bundles=true None(default cannot be changed within GUI) When set to true, any bundle wrappers within the source depot that contain software selected for copying will be automatically selected if the is_reference attribute set to true. Note that this does not mean all of the software listed in the wrapper will be selected, only the bundle wrapper itself. compress_files=false Options : Change Options : Compress files during transfer Setting this option to true causes swcopy to compress file before transfer to the target depot. This will conserve disk space and can enhance performance on slower networks (50 Kbytes/sec. or less), although it may not improve fast networks. HP-UX Patch Management 57

66 The swcopy Command enforce_dependencies=true Options : Change Options : Enforce dependency analysis errors in agent Enforces software dependencies. When software to be copied has an SD-enforced dependency, if that dependency is not present on the target system and is not marked for copying from the source depot the copy will only proceed if enforce_dependencies is set to false. While few patches currently exist with dependencies enforced by the SD tools, those that do employ them to enforce critical requirements of content and load order. This option should not be set to false unless directed by an HP Support Engineer. mount_all_filesystems=true Options : Change Options : Mount filesystems in /etc/fstab or /etc/checklist By default, swcopy requires that all filesystems listed in the systems /etc/fstab file are mounted prior to installation. Setting this option to false removes this restriction. reinstall=false Options : Change Options : Recopy filesets even if the same revision exists Prevents SD from overwriting an existing revision of a fileset. If set to true, filesets will be recopied. source_tape=/dev/rmt/0m None (default cannot be changed within GUI) Specifies the device file of the tape drive to be used as the default. uncompress_files=false Options : Change Options : Uncompress files after transfer When set to true, files are uncompressed before swcopy puts them into the target depot. See also the compress_files option. write_remote_files=false None Prevents copying of files to a target that exists on a remote (NFS) file system. By default, swcopy skips files that would be copied to an NFS file system (or that are already there). When set to true and superuser has write permission on the remote file system, files are copied to remote systems. Examples With the CD mounted at /cdrom, copy the contents of the XSWGR1100 depot to the local system under the /var/tmp/mydepot directory. swcopy -s /cdrom/xswgr1100 /var/tmp/mydepot Invoke an interactive session, using the default depot at hostx as the source: swcopy -i -s hostx Copy all patches in current directory to the depot /hub/patches (assuming root shell is /sbin/sh): for PATCHDEPOT in *.depot do swcopy -s $PATCHDEPOT /hub/patches done Copy a HP-UX 10.X style depot from the system oldsys to an HP-UX 11.X system. swcopy -s oldsys:/depot -x layout_version=0.8 /depots/oldsys 58

67 The swremove Command The swremove Command The swremove command deletes software that has been installed on your system. It also removes software from depots. Note that swremove has several limitations when used for patch operations: You cannot use swremove to remove committed patches. You should not use swremove to remove patch information that remains in the IPD after installing a new version of HP-UX, see The cleanup Command on page 66. If you use swremove to remove a patch, you must make sure you didn t break any software dependencies. If the patch was needed to fulfill a documented dependency then patches to satisfy the dependency must be activated via rollback or installation. Removal of a patch bundle does not automatically return you to the patch state prior to loading that bundle. swremove may not always be your first and best solution for error recovery. Make sure your other recovery methods are not more appropriate before you use this command. Synopsis swremove [-i] [-d] [-p] [-v] [-x option=value] [software_selections] target ] Patch-related Command Line Arguments -i Use an interactive user interface. If the environment variable DISPLAY is set to a valid X windows display, a graphical user interface is invoked. Otherwise a terminal user interface (TUI) designed for use on ASCII terminals is invoked. The GUI starts by default if you enter swremove without any software_selections. -d Operate on a depot rather than installed software. -p Previews the remove operation without performing the actual removal. Preview mode is not enabled by default. -v Requests verbose mode. This option affects only standard output and not the log files. Verbose mode is enabled by default. -x option=value Sets the specified default option to the value given, overriding any other values for that option. Patch-related default options are specified below. See Setting Default Options on page 68 for more information on setting defaults. software_selections target One or more software specifications. See Software Specifications on page 67 for more information The depot from which software is to be removed. If not specified, the target is assumed to be the system itself. Patch-related Options You can change the command behavior overriding the default options. These are changed on the command line with the -x option=value syntax, by various menu selections in the GUI, or by other methods (see Setting Default Options on page 68). The following options have the most relevance to patching. Where appropriate, default values are shown. (For the full set of available options, consult the swremove(1m) man page or refer to Managing HP-UX Software with HP-UX. ). HP-UX Patch Management 59

68 The swlist Command option=default value Menu Path in Interactive Interface Description autoselect_reference_bundles=true None If true, bundles that have the is_reference attribute set to true will be automatically removed when the last of its contents is removed. If false, the bundles will not be automatically removed. enforce_dependencies=true Options : Change Options : Enforce dependency analysis errors in agent Enforces software dependencies. When software selected for removal has a registered dependency, if the dependency is not present on the target system or also selected for removal from the source depot, removal only proceeds if enforce_dependencies is set to false. While few patches currently exist with dependencies enforced by the SD tools, those that do employ them to enforce critical requirements of content and removal order. Do not set this option to false unless directed to do so by an HP Support Engineer. enforce_scripts=true Options : Change Options : Enforce script failures Each patch may have several removal scripts associated with it. These scripts may issue errors to protect the system from incorrect patch usage. This option should not be used unless directed by an HP Support Engineer. mount_all_filesystems=true Options : Change Options : Mount filesystems in /etc/fstab or /etc/checklist By default, SD requires that all filesystems listed in the systems /etc/fstab file are mounted prior to removal. Setting this option to false removes this restriction. write_remote_files=false None (default cannot be changed within GUI) Prevents removal of files from a target that exists on a remote (NFS) file system. By default, swremove skips files that would be removed from an NFS file system. When set to true and superuser has write permission on the remote file system, files are removed from remote systems. Examples Remove only the bundle wrapper XSWHWCR1100 from the system, leaving any contents present (Note that the trailing period (.) is essential to removing the wrapper only): swremove XSWHWCR1100. Remove all contents of the depot /depots/mydepot: swremove -d /depots/mydepot The swlist Command The swlist(1m) command provides information on software installed on a system or located in a depot. More specifically: See what s installed on a system. See what software is in a depot. Check attributes of software. 60

69 The swlist Command Browse the patch documentation. See what depots are available on remote systems. Synopsis swlist [-i] [-d] [-v] [-a attribute] [-l level] [-s source] [software_selections] target ] Patch-related Command Line Arguments -i Invokes a GUI interface that lets you perform interactive software selections. If the environment variable DISPLAY is set to a valid X windows display, a graphical user interface is invoked. Otherwise a terminal user interface (TUI) designed for use on ASCII terminals is invoked. You must specify -i to invoke the GUI; it never starts by default. -d Lists software depots instead of software currently installed on the target system. -v If no -a options are specified, then list all the attributes for an object, one attribute per line. The attributes are listed in the format: keyword value If one or more -a options are specified, then list the selected attributes in the above format. -a attribute The named attribute is included in the listing when defined at the specified level. While this option may be specified multiple times, the ordering of the arguments does not control the format of the list. -s source Specifies the software source to list. This is an alternative way to list a source depot. You can also specify the sources as target depots and list them using the -d option. software_selections target One or more software specifications. See Software Specifications on page 67 for more information The depot to be listed. If not specified, the target is assumed to be the system itself. HP-UX Patch Management 61

70 The swlist Command -l level Specifies the detail of the swlist output. The values used include: file List all files recorded in the IPD. The listing may be limited in scope by the software_selections specification. Each file is preceded by the product and fileset that is the registered owner of that file. A comment (marked by a leading # character) precedes each block giving the name, revision, and description of the product or fileset to be listed. fileset List all filesets recorded in the IPD (in product.fileset format) with the associated revision and description. A comment (marked by a leading # character) precedes each block giving the name, revision, and description of the product. product List all products with revision and description for each. bundle List all bundles with revision and description for each. depot List all registered depots on the target system. patch List all patch filesets using the full software specification, followed by the associated description and current patch_state. The listing is sorted by ancestor, and all products and filesets are listed as a comment showing revision and description before any patch fileset that apply to it. category List all category tags currently defined within the target depot. default (no level specified) When no level is specified, swlist displays all bundles within the depot followed by any products not contained within a bundle. As is the case with their respective levels, the bundles and products are listed with revision and one-line description. Patch-related Options None. (For the full set of available options, consult the swlist(1m) man page or refer to Managing HP-UX Software with HP-UX. ) Examples List all patches in the depot /var/mydepot on the system grendel swlist -d -l product grendel:/var/mydepot List the filesets modified by installed patch PHSS_8675 swlist -a ancestor PHSS_8675 List all of the files delivered within patch PHCO_12140 after downloading from the ITRC: swlist -d -l /tmp/phco_12140.depot List all patches that have modified the LVM product swlist -l patch LVM Display the documentation for all patches containing critical functionality swlist -a readme -l product *,c=critical List all category tags defined in the depot /var/mydepot on the system grendel swlist -d -l grendel:/var/mydepot 62

71 The swreg Command Also see Software Specifications on page 67 for more examples. The swreg Command The swreg command registers or unregisters an existing depot. When a depot is registered, it can be accessed from remote systems. Unregistration of a depot can be a convenient way to limit access during development. (Note that unregistered depots are still available locally.) Synopsis swreg -l depot [-u] [-v] [objects] Patch-related Command Line Arguments -l depot Perform operations on depots. While other levels of SD objects may be modified by swreg, they are not within the scope of this tutorial. -u Causes swreg to unregister the specified objects instead of registering them. -v Requests verbose mode. This option affects only standard output and not the log files. objects Specifies the path to the object[s] to be registered or unregistered. Patch-related Options None. (For the full set of available options, consult the swreg(1m) man page or refer to Managing HP-UX Software with HP-UX. Refer to Managing HP-UX Software with SD-UX ) Examples Register the patch depot XSWGR1100: swreg -l depot /cdrom/xswgr1100 Disable remote access by unregistering the depot XSWGR1100 (local access is still enabled): swreg -u -l depot /cdrom/xswgr1100 The swmodify command SD commands automatically keep track of software management operations by creating an Installed Products Database (IPD) and various "catalog files" that contain information about the software on the system. Although you cannot edit the IPD or catalog files directly, the swmodify command lets you change the contents of these files via the command line. WARNING: With the exception of committing patches and creating category tags, the swmodify command is not recommended for general usage. Improper alteration of the information in the IPD could cause unexpected behavior during subsequent patching or system updates and leave your system in an unsupportable state. HP-UX Patch Management 63

72 The swmodify command Synopsis swmodify [-d] [-p] [-v] ]-a attribute[=value]] [-x option=value] [software_selections] target ] Patch-related Command Line Arguments -a attribute[=value] Add, modify, or delete the value of the given attribute. If the -u option is specified, then delete the attribute from the given software_selections (or delete the value from the set of values currently defined for the attribute). Otherwise add/modify the attribute for each software_selection by setting it to the given value. Multiple -a options can be specified. Each attribute modification will be applied to every software_selection. -d Perform modifications on a depot. The given target must be a depot. -p Previews the modify operation without modifying anything. Preview mode is not enabled by default. -v Requests verbose mode. This option affects only standard output and not the log files. -x option=value Sets the specified default option to the value given, overriding any other values for that option. Patch-related default options are specified below. See Setting Default Options on page 68 for more information on setting defaults. software_selections One or more software specifications. See Software Specifications on page 67 for more information target The depot to be modified. If not specified, the target is assumed to be the system itself. Patch-related Options You can change the command behavior by overriding the default options. These are changed on the command line with the -x option=value syntax. option=default value Menu Path in Interactive Interface Description patch_commit=false None Commits a patch by removing files saved for patch rollback. The default value is false. When set to true, this option removes the saved files for the patches specified in the software selections for the command. Once you have run this option on a patch, you cannot remove the patch unless you remove the associated base software that the patch modified. Examples Commit the patch PHKL_1234 and remove its corresponding rollback files: swmodify -x patch_commit=true PHKL_1234 Mark all patches in the depot /depots/newpatches with a new category tag to indicate that they have been approved: swmodify -a category=approved /depots/newpatches 64

73 The swpackage command The swpackage command While primarily used to create depots from source files, this command allows the transfer of software onto a tape or into a tape depot which can then be used as a software source. Either method can be used to transport the contents of a depot to another system for local access. The tape can be used in the absence of networking support, and the tape depot could be provided via ftp(1). Synopsis swpackage [-p] [-v] [-s directory] [-x option=value] [software_selections] [@ target] Patch-related Command Line Arguments -p Previews the package operation without performing the actual packaging. Preview mode is not enabled by default. -v Requests verbose mode. This option affects only standard output and not the log files. -s directory An existing directory depot (which already contains products) to be used as the source. -x option=value Sets the specified default option to the value given, overriding any other values for that option. Patch-related default options are specified below. See Setting Default Options on page 68 for more information on setting defaults. software_selections target One or more software specifications. See Software Specifications on page 67 for more information If you are creating a distribution depot (directory), this operand defines the location of the directory. Without this operand, /var/spool/sw is used as the default depot directory. If you are creating a distribution tape, this operand names the device file on which to write the tar archive. The device file must exist so that swpackage can determine if the media is a DDS tape or a disk file. Without this operand, swpackage uses the device file /dev/swtape. Patch-related Options You can change the command behavior using the default options. These are changed with the -x option=value syntax or by other methods (see Setting Default Options on page 68). The following default options have the most relevance to patching. Where appropriate, default values are shown. (For the full set of available options, consult the swpackage(1m) man page or refer to Managing HP-UX Software with HP-UX. ). option=default value Menu Path in Interactive Interface Description compress_files=false None Setting this option to true causes swpackage to compress files before packaging them. This creates smaller depots. layout_version=1.0 None HP-UX Patch Management 65

74 The cleanup Command Specifies the POSIX layout version to which the SD commands conform when writing distributions. Supported values are 1.0 (default) and 0.8. Refer to the swpackage(1m) or SD manual for more information. target_type=directory None Defines the type of distribution to create. The recognized types are directory and tape. Examples Re-package the entire contents of the depot /var/spool/sw onto the tape at /dev/rmt/0m: swpackage -s /var/spool/sw -x /dev/rmt/0m The cleanup Command The cleanup command provides functions useful when dealing with HP-UX patches. It is used to remove any patches for earlier releases from the Installed Product Database after updating to a newer version of HP-UX. It is also used to remove patches from a software depot if they have been superseded by patches also available in the same depot. The cleanup utility also allows patches to be committed across the entire system. The cleanup command is not delivered with HP-UX, but as a patch. Currently available as patch PHCO_ The cleanup command logs all information to /var/adm/cleanup.log. Synopsis cleanup [-n -p] -i cleanup [-n -p] -d <depot> Patch-related Command Line Arguments -p Preview the cleanup task but do not actually remove any patch information. -n Notify the user of cleanup tasks and request confirmation before actually removing any patch information. -i Determine which patches that are included in the Installed Product Database are 10.X patches that are remnants from an upgrade to HP-UX 11.X. These patches are removed from the IPD so that they are no longer displayed in the output of the swlist(1m) command. -d Determine which patches in the software depot have been superseded by patches also available from the depot. These superseded patches will be removed from the software depot. The show_patches Command The show_patches utility displays active and superseded patches in a formatted output, which may be easier to interpret than the output of the swlist(1m) command. The utility uses the SD patch attributes patch_state and superseded_by to determine which patches are active and which are superseded. 66

75 Other Options and Aids to Using the SD Commands Synopsis show_patches [-a] [-s] [-l product fileset] Patch-related Command Line Argument : default If no options are specified, show_patches displays the active patches at the SD product level. -a Display the active patches on the system. Active patches are those which have not been superseded by newer patches on the system. -s Display the superseded patches on the system. Superseded patches are those that have been replaced by newer patches on the system. -l level Display the patch information at the SD product or fileset level. Other Options and Aids to Using the SD Commands Software Specifications When an SD command can be supplied a software selection, the selection is comprised of one or more software specifications. A software specification is a unique identifier for an SD software object. A software specification must name either a product or a bundle, and filesets can be specified only within a product. If you explicitly select a bundle, all products within the bundle are also selected. If you select a product, all filesets within that product are also selected. For patch operations, you usually only need to refer to a patch or bundle name. The software specification takes one of the following formats: product[.fileset][,version] bundle[.product[.fileset]][,version] where the version has the form: [r=revision][,a=arch][,v=vendor][,c=category] (The version may also have a l=location component that applies only to installed software and refers to software installed to a location other than the default product directory.) The software_spec attribute contains the full software specification for any bundle, product, or patch (see Patch-related Object Attributes on page 50). You can use the swlist command to display this information. The following example shows how swlist can create a list of the software specifications for a patch at the fileset level. The software specification for the patch product appears in the output as a comment. # swlist -l fileset -a software_spec PHKL_18543 # PHKL_18543 PHKL_18543,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP PHKL_18543.C-INC PHKL_18543.C-INC,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP,fa=HP-UX_B.11.00_32/64 PHKL_18543.CORE-KRN PHKL_18543.CORE-KRN,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP,fa=HP-UX_B.11.00_32/64 PHKL_18543.CORE2-KRN PHKL_18543.CORE2-KRN,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP,fa=HP-UX_B.11.00_32 PHKL_18543.KERN2-RUN PHKL_18543.KERN2-RUN,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP,fa=HP-UX_B.11.00_32 PHKL_18543.VXFS-ADV-KRN PHKL_18543.VXFS-ADV-KRN,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP,fa=HP-UX_B.11.00_32 PHKL_18543.VXFS-BASE-KRN PHKL_18543.VXFS-BASE-KRN,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP,fa=HP-UX_B.11.00_32 PHKL_18543.VXFS-PRG PHKL_18543.VXFS-PRG,l=/,r=1.0,a=HP-UX_B.11.00_32/64,v=HP,fa=HP-UX_B.11.00_32/64 HP-UX Patch Management 67

76 Other Options and Aids to Using the SD Commands Session Files Session files let you save your work from a command session. Each invocation of an SD command defines a session. The invocation options, source information, software selections, and target hosts are saved before command execution actually commences. This lets you re- execute the command even if the session ends before proper completion. Each session is saved to the file $HOME/.sw/sessions/{command}.last. This file is overwritten on each invocation. You can also save session information from interactive or command-line sessions. From an interactive session, you can save session information into a file at any time by selecting the Save Session or Save Session As option from the File menu. From a command-line session, you can save session information by executing swinstall or swcopy with the -C session file option. A session file uses the same syntax as the defaults files (see Setting Default Options on page 68). You can specify an absolute path for a session file. If you do not specify a directory, the default location for a session file is $HOME/.sw/sessions/. To re-execute a saved session from an interactive session, use the Recall Session option from the File menu. To reexecute a session from a command-line, specify the session file as the argument for the -S session file option of swinstall or swcopy. Note that when you re-execute a session file, the values in the session file take precedence over values in the system defaults file. Likewise, any command line options or parameters that you specify when you invoke swinstall or swcopy take precedence over the values in the session file. NOTE: Use of session files is not recommended with swremove. The session file because the session file could include software selections that you do not want included in the removal operation. Setting Default Options SD commands have extensive options that alter command behavior. The default option values are listed within the file /usr/lib/sw/sys.defaults, a template that lists and explains each option, all possible values, and the resulting system behavior. These options are listed as comments that you can copy into the system defaults file (/var/adm/sw/defaults) or your personal defaults file ($HOME/.sw.defaults). Values in these option files are specified using this syntax: [command.]option=value These rules govern the way the defaults work: 1. Option values in /usr/lib/sw/sys.defaults are hard-coded and are used only when there are no other option files or session files that contain different values. 2. Option values in /var/adm/sw/defaults file affect all users in a system. 3. Option values in your personal $HOME/.sw/defaults file affect only you and not the entire system. 4. Option values in a session file affect activities only for that session and revert when that session is completed. 5. Option values changed on the command line affect only that activity. For system-wide policy setting, use the /var/adm/sw/defaults file. Keep in mind, however, that individual users may override these values with their own $HOME/.sw/defaults file, session files, or command line changes. 68

77 Other Options and Aids to Using the SD Commands These values can also be overridden by specifying an options file with the -X option (same format as the files) or with one or more -x option=value options directly on the command line. They can also be changed using the GUI Options Editor. Altering option values and storing them in a defaults file can help when you want the SD command to behave the same way each time the command is invoked. Options in the defaults file are read as part of command initialization. Because the daemon is already running, after changing daemon options, the daemon must be restarted in order for these options to be recognized. To restart the daemon, type: /usr/sbin/swagentd -r HP-UX Patch Management 69

78 Other Options and Aids to Using the SD Commands 70

79 Appendix C The Patch Text File The Patch Text File Fields Patch Name The name of the patch. This identifier is used for the patch shar, text, and depot files as well as the patch product and in HP-UX 10.X releases the patch fileset. Format is: PHxx_yyyy where: PH = Patch HP-UX. xx = area patched: CO - general HP-UX commands. KL - kernel patches. NE - network specific patches. SS - all other subsystems: X11, Starbase, etc. yyyyy = a unique number Example: PHSS_ an HP-UX subsystem patch name. Patch Description A one-line description that describes this cumulative patch. Creation Date The date that the patch was created. HP-UX Patch Management 71

80 The Patch Text File Fields Post Date The date that the patch was posted for general distribution. Hardware Platforms - OS Releases The hardware platforms and HP-UX OS releases on which this patch can be installed. Products This field lists the product name and all product revisions to which this patch applies if it is a patch for an optional product, i.e. a non-core operating system product. If the patch is for the core operating system, the value in this field is "N/A". Filesets This is a list of all the filesets which contain one or more files included in this patch. Automatic Reboot? Yes/No (whether or not this patch requires a reboot after installation). Status This is the support status of the patch. GR SP where: GR = General Release patch should be installed on all systems meeting the OS, product, and dependency requirements. SP = Special Release site-specific patches for installation at one specific customer or set of customers, and other non-gr patches. Critical Yes/No followed by text. This flags the Critical status of this patch and all superseded patches. A patch is considered "critical" if it fixes a critical problem or it supersedes a patch fixing a critical problem. A problem is critical if it: Causes the system (OS/kernel) to fail/crash/panic. Causes a major application to fail such that the system s operation is severely impacted. Causes data loss or corruption. Delivers a fix related to processing dates in the year 2000 and beyond. Path Name The path name is the patch s storage location on the HP Electronic Support Center ftp server (ftp://us-ffs.external.hp.com). The current choices for supported releases are: /hp-ux_patches/s700_800/11.x/phxx_yyyy 72

81 The Patch Text File Fields Symptoms The external symptoms of the problem, specifically what a user would experience. Defect Description A detailed description of the defect that specifically addresses the explicit conditions which caused the problem (if known), and how to reproduce the problem (if known). Also include methods to verify if the patch needs to be installed. SR All Service Request (SR) numbers addressed by this patch and all its predecessors. An SR is a formal request from a customer to have a defect resolved or a feature added to HP software. Patch Files The full installed path name of all files in this patch. If the patch replaces an object module in a library, the full path of the library is listed with the object module following in parentheses. For example, if a patch replaces the object module "vers.o" in the library "/usr/conf/lib/libhp-ux.a" the path listed would be "/usr/conf/lib/libhp-ux.a(vers.o)". what(1) Output The output from what(1) for each file or library object file listed in the Patch Files field. The what string is a way to identify the software version, and thereby, verify that the patch is installed. Example : $Revision: 1.13 $ Patch Conflicts All known patch conflicts, both on a file basis as well as on a behavioral basis. Patch Dependencies All patches that must be installed to insure proper operation of this patch. Hardware Dependencies Specific system models to which this patch is limited. Other Dependencies Any non-patch and non-hardware dependencies that may exist. Supersedes A list of all patches replaced by this patch. HP-UX Patch Management 73

82 The Patch Text File Fields Equivalent Patches All equivalent patches for other hardware platforms and OS releases not including this patch. Patch Package Size The SD depot size in Kbytes. Installation Instructions The standard installation instructions common to all patches. These instructions have been included in this tutorial. Special Installation Instructions Any special instructions not included in those mentioned above. 74