HP-UX Patch Management

(1)

HP-UX Patch Management

A guide to patching HP-UX 11.X systems

B3782-90829 January 2000

(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 restric-tions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies.

HEWLETT-PACKARD COMPANY 3000 Hanover Street Palo Alto, California 94304 U.S.A.

Copyright Notices.

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 10.20 and later and HP-UX Release 11.00 and later (in both 32 and 64-bit configurations) on all HP 9000 computers are Open Group UNIX 95 branded products.

(3)

Document History

January 2000 ... Preliminary Edition.

This Edition documents new features applicable to the HP-UX 11.00 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. 3404 E. Harmony Rd. Fort Collins, CO 80525.

(4)

(5)

CHAPTER 1

Introduction

1

Overview - - - - 1

Other Sources of Information - - - - 2

Web Sites - - - -2

CHAPTER 2

Planning for Recovery

3

The Value of Recovery Options - - - - 3

The Root Volume Group - - - - 3

Practice Data Separation- - - -4

Preserving Configuration via NIS - - - -4

Ignite-UX - - - - 4

Ignite-UX File System Guidelines - - - -4

Creating a Recovery Tape - - - -5

Loading a Recovery Image from Tape - - - -5

The make_net_recovery Utility - - - -6

System Reinstallation - - - - 7

Installation Optimizations - - - -7

The Wish List - - - -7

CHAPTER 3

Acquiring Patches

9

The Patch Database - - - - 9

Searching for HP-UX Patches - - - -9

Requesting a Known Patch - - - - 12

Dependency Analysis and the Patch Database - - - - 14

The Fulfillment Server - - - - 14

Accessing the Fulfillment Server via ftp(1)- - - - 14

Accessing the Fulfillment Server via web browser - - - - 16

The FFS Directories - - - - 16

Downloading the patch - - - - 18

Custom Patch Manager - - - - 18

Benefits of Custom Patch Manager - - - - 18

Collect Configurations - - - - 20

Perform Patch Analysis- - - - 20

Managing Patch Depots with CPM - - - - 21

Custom Patch Notification - - - - 23

Support Plus Media - - - - 24

The Bundle Matrix - - - - 25

Mounting the CD - - - - 26

Support Plus CD-ROM Layout - - - - 26

Sharing Support Plus with Remote Systems - - - - 27

Setting Up Hard Disk Access - - - - 27

Requesting Support Plus CD-ROMs- - - - 27

Software Depot - - - - 28

(6)

CHAPTER 4

Depot Management

31

Custom Depots - - - - 31

Benefits of Creating Depots - - - - 31

Types of Depots - - - - 31

HP-UX 10.X vs. 11.X Depots - - - - 32

Patch Depots - - - - 32

Periodic Patch Depot - - - - 32

Critical Fix Patch Depot - - - - 32

Patch Hubs - - - - 33

Creating a Patch Depot - - - - 34

Preparation Tasks - - - - 34

Copying Existing Depots - - - - 34

Combining Patch Depots - - - - 34

Dependency Analysis - - - - 35

Depot Access - - - - 36

Depot Registration- - - - 36

SD Access Control Lists (swacls) - - - - 36

CHAPTER 5

Patch Installation

37

System Preparation - - - - 37

Backups, Backups, Backups! - - - - 37

A Note on Change Management - - - - 37

System Activity - - - - 38

Patch Committal - - - - 38

Planning for System Reboot - - - - 39

When is a Reboot Needed? - - - - 39

Timing of the Reboot - - - - 39

Installation - - - - 39

Using the SD Matching Operations - - - - 39

Installing to a Committed Patch State - - - - 40

Finishing Touches - - - - 41

The swverify command - - - - 41

Checking the Logs - - - - 41

Erroneous Errors and Warnings - - - - 41

Appendix A

Basic Patch Concepts

43

Patch Mechanics - - - - 43

Ancestors and Patches - - - - 43

Patch Supersession - - - - 44

Patch Rollback - - - - 44

Patch Commitment- - - - 45

Patch Dependencies - - - - 46

Dependency Types - - - - 46

The HP-UX Patch - - - - 46

Patch Status - - - - 46

The Critical Patch - - - - 47

Patch Identification - - - - 47

(7)

Appendix B

SD Tools & Objects

49

The Basic SD Object Types - - - - 49

The Fileset- - - - 49

The Product - - - - 49

The Bundle - - - - 50

The Depot - - - - 50

Patch-related Object Attributes - - - - 50

ancestor - - - - 50 applied_patches - - - - 50 applied_to - - - - 50 category_tag- - - - 50 is_patch - - - - 51 is_sparse - - - - 51 is_reboot - - - - 51 patch_state - - - - 51 readme - - - - 51 software_spec - - - - 51 state- - - - 52 supersedes- - - - 52 superseded_by - - - - 52

Introduction to the SD Commands - - - - 53

The swinstall Command - - - - 53

Synopsis - - - - 53

Patch-related Command Line Arguments - - - - 53

Patch-related Options - - - - 54

Examples - - - - 56

The swcopy Command - - - - 56

Synopsis - - - - 56

Examples - - - - 58

The swremove Command- - - - 59

Synopsis - - - - 59

Examples - - - - 60

The swlist Command - - - - 60

Synopsis - - - - 61

Examples - - - - 62

The swreg Command - - - - 63

Synopsis - - - - 63

Examples - - - - 63

The swmodify command - - - - 63

(8)

The swpackage command - - - - 65

Synopsis - - - - 65

Examples - - - - 66

The cleanup Command - - - - 66

Synopsis - - - - 66

The show_patches Command - - - - 66

Synopsis - - - - 67

Patch-related Command Line Argument : - - - - 67

Other Options and Aids to Using the SD Commands- - - - 67

Software Specifications - - - - 67

Session Files - - - - 68

Setting Default Options - - - - 68

Appendix C

The Patch Text File

71

The Patch Text File Fields - - - - 71

Patch Name - - - - 71

Patch Description - - - - 71

Creation Date - - - - 71

Post Date - - - - 72

Hardware Platforms - OS Releases - - - - 72

Products - - - - 72 Filesets - - - - 72 Automatic Reboot? - - - - 72 Status - - - - 72 Critical - - - - 72 Path Name - - - - 72 Symptoms - - - - 73 Defect Description- - - - 73 SR - - - - 73 Patch Files - - - - 73 what(1) Output - - - - 73 Patch Conflicts - - - - 73 Patch Dependencies - - - - 73 Hardware Dependencies - - - - 73 Other Dependencies - - - - 73 Supersedes - - - - 73 Equivalent Patches - - - - 74

Patch Package Size - - - - 74

Installation Instructions - - - - 74

(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 docu-ment revision with your comdocu-ments.

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 meth-odology. 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 cer-tain levels of support while others are free. This chapter describes an array of patch sources and how they may be used to acquire patches.

(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 rec-ommended steps to execute and verify patch installation.

• Appendix A: Basic Patch Concepts

Patches are different from other types of HP-UX software. Patches have a terminology and operations all their own. This appendix provides a basic understanding of patch concepts.

• Appendix B: SD Tools & Objects

While Software Distributor (SD) has a wealth of documentation available, the sections that are of specific interest to patching are not always readily apparent. This appendix provides SD information related only to patching.

• Appendix C: The Patch Text File

The patch text file can be found in a variety of locations, but remains the core documentation of each patch. This appendix lists all of the fields within the .text file with a brief description.

Other Sources of Information

Web Sites

• http://docs.hp.com

The home page for H-P technical documentation, this source provides online access to HP-UX manuals, guides, and whitepapers. Information on particular hardware platforms, HP-UX releases, and software products are avail-able for browsing, download, or purchase.

• http://software.hp.com

Known as H-P’s Software Depot, a variety of HP-UX software is available. While some require purchase, many products such as Ignite-UX and the Support Plus patch bundles are available without charge.

• http://ITResourceCenter.hp.com

The primary source for all support information, the IT Resource Center (ITRC) and the Electronic Support Center (ESC) that it contains provide a variety of tools and information related to HP-UX systems. In addition, the ITRC is the official repository for all HP-UX patches.

• http://www.interex.org/tech/9000/index.html

The International Association of Hewlett-Packard Computing Professionals, known as Interex, maintains this list of technical resources for HP-UX systems. Not a part of Hewlett-Packard itself, Interex is also noted for its yearly trade shows Interworks and HPWorld and regional users groups. The main page (http://www.interex.org) should be reviewed to learn about all of the benefits of membership.

• http://www.dutchworks.nl/htbin/hpsysadmin

Another resource outside of Hewlett-Packard is the HP-UX Administrators Mailing List. This web page is an interface to the list archives dating back to 1995. To join the list itself, send the command:

subscribe hpux-admin-digest

(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 con-figuration is preferable to the new state. That is why this guide to patch management begins with a discussion of the merits of planning for system recovery.

The Value of Recovery Options

Problems happen. The causes vary, and can range from hardware failures, operator errors, and even malicious attacks. When a problem results in the failure of a critical system, the first order of business is to return to an operational con-dition as quickly as possible. When planning and resources are put in place to support system recovery the risk of a failure remains, but the associated cost of a failure can be controlled and calculated.

When the cost of failure is minimized, the value of proactive maintenance is increased. Proactive maintenance is the fixing of known problems before they are seen on a system. The value of a patch is listed within its documentation, with all of the defects or enhancements described. It is common for an administrator to avoid system change for fear of introducing a new failure. With a predictable recovery plan, the known cost to return to the original state can be weighed against the risk of encountering any of the documented conditions at an unknown time.

More than one option exists, and more than one option should be used. At different times, different options may be preferred. By planning for multiple methods you also protect yourself from the failure of any one of the recovery options, such as a bad tape or network failure.

The Root Volume Group

The Logical Volume Manager (LVM) allows a single disk to be split into pieces, or a group of disks to be treated as a single unit. This dramatically changes the way disk management can be done. This section will discuss issues with LVM root volumes, but the same concepts would generally apply to users of whole-disk HFS root disks.

(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 mini-mum would require an additional data recovery step.

• Keep all system data within the root volume group

It is not uncommon for a system administrator to free up disk space by relocating parts of a directory structure and replacing it with a symbolic link. While effective, it can be a recovery trap. While Ignite-UX will save system crit-ical data regardless of the volume group, what you consider to be critcrit-ical may not be the same things that Ignite-UX considers critical.

Tools and processes can allow some deviation from these rules (see “Ignite-UX File System Guidelines” on page 4) but any deviation should be done to meet a specific need, and with consideration given to the recovery mechanisms.

Preserving Configuration via NIS

While not as critical as data, system information such as networking configuration and password file entries may change on a frequent basis. If systems such as NIS and DNS are used to maintain configuration data off of the system, the recovery process will not require an additional step to restore configuration updates.

Refer to “Installing and Administering NFS Services” for more information on NIS and NIS+. This and related docu-ments are available from http://docs.hp.com.

Ignite-UX

Ignite-UX is a set of tools that can be used for system installation, recovery, and duplication. Used within Hewlett-Packard to preload software, UX is available free of charge. To download the latest version or browse Ignite-UX documentation, go to http://software.hp.com/products/IIgnite-UX.

Ignite-UX File System Guidelines

Be sure to follow these Ignite-UX guidelines for file system layout if a different method is chosen for the primary recovery mechanism:

• /, /sbin, /stand, /dev, and /etc

These directories contain the critical parts of the Core System required for booting. They must exist completely within the root volume group.

(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 vol-ume group, plus data from any non-root volvol-ume group containing /usr. make_recovery is capable of creating system recovery tapes for all DDS tape devices, with the ability to span multiple tapes. For systems that support HSC SCSI cards, DLT tape devices can be used to create system recovery tapes. Root-user privileges are required to execute make_recovery.

1. With the Ignite-UX recovery tools installed on a system, insert a blank, writable tape into the default tape drive (usually found at /dev/rmt/0m) and run make_recovery:

# make_recovery -A -C

The -A option backs up every file in the root disk/volume. The -C option allows the check_recovery command to monitor how much has changed on the system since the tape was made.

It is recommended that the recovery tape be created when the system is quiescent to minimize change. No soft-ware should be installed or removed while the recovery tape is being created.

2. Ensure that you have a good full backup of your system. The make_recovery utility was not designed to replace standard backup procedures. The software required to restore data from the full backup should be included in the recovery image.

3. Review the log files:

/var/opt/ignite/logs/makrec.log1 #Logs progress reports

/var/opt/ignite/logs/makrec.log2 #Logs an Index of filesets stored on tape

Loading a Recovery Image from Tape

If it is determined that a new system state (such as that created through the loading of a new set of patches) is unac-ceptable, the previous environment can be restored from the image on the recovery tape. To load the image:

(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 http://docs.hp.com/hpux/systems.

4. Boot from the recovery tape

Once the tape drive hardware path is known, or if the alternate boot path has be set to the tape drive, the system can be directed to load from the recovery tape:

Main Menu: boot scsi.#.0

5. Recover latest backups.

Some data or configuration information may not be included within the recovery image. Once the system has booted successfully, recover these files from alternate sources. Please note that critical files on the recovered sys-tem (such as /etc/lvmtab and /etc/fstab) should not be overwritten by those found on a backup. Use options that preserve newer versions of files during the restoration.

The make_net_recovery Utility

Ignite-UX A.2.0, B.2.0 and later versions allow you to create recovery archives via the network onto a specified sys-tem. You can either use the Ignite-UX server GUI (/opt/ignite/bin/ignite) or run /opt/ignite/bin/make_net_recovery on a client system. Use the Ignite-UX server interface to recover specified systems on the net. Systems can be recovered across subnets from a boot tape using make_boot_tape(1m), local boot server or the bootsys(1m) tool from an Ignite-UX server.

Archival and recovery using make_net_recovery(4) has several advantages over using tapes:

• Tape-management is eliminated, since system archives are centralized on a user-designated system disk. This results in less media-management time.

• Customization is possible, within the condition that no file or directory which is essential to HP-UX can be excluded. The Essentials List is visible to the user in /opt/ignite/recovery/mnr_essentials. This information can also be overridden by creating /var/opt/ignite/recovery/mnr_essentials

• Configuration of the recovery archive is controlled either via the Ignite-UX server user interface, or generated via a command-line/cron job from a client. For file, directory, or volume selection, an interactive selection screen (GUI mode) can be used on the server.

• Networked recovery is especially useful on systems which lack an internal tape drive, such as the A-Class and N-Class systems.

• Creation of recovery archives and associated config files can be monitored and inspected either from the Ignite-UX server, as with the install process, or at the client where make_net_recovery(4) is run.

(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 http://docs.hp.com.

System Reinstallation

While not the preferred method for system recovery, when no other options are available the final answer is to start over and perform a full system installation. Even this most basic of recovery strategies can benefit from planning.

Installation Optimizations

Think for a moment of your most critical system. Could you reinstall it right now? If so, how long might it take? Con-sider the following:

• Media Library

Where are the tapes and CDs that are required to rebuild the system? If they are kept in a central library, could you identify the person who is currently using the media that you need? Is there an index that lists which systems require a given set of media? Remember to account for systems and peripherals that require a specific patch level!

• Network Depots

While tapes and CDs should be available, they are not known for high performance. By creating depots on hard disk and sharing over the network it is likely that performance will be greatly enhanced. In addition, multiple sys-tems can share the network depot while media should be considered fit for only serial access.

• Ignite-UX

If Ignite-UX is used for the original system installation, it may be used to reinstall. Just as the network depots are an improvement over installation from media, Ignite-UX allows multiple network depots and archives of system "golden" images to be used together as a part of a single installation.

The Wish List

When the need for system recovery arises, there is often only time available to take action. For this reason maintain a wish list of system changes to help you take advantage of the failure.

• File System Layout

If the recovery option requires that the root volume group be recreated (such as reinstallation or Ignite-UX recov-ery image) it is an opportunity to change the number and size of logical volumes. If any filesystems were built too small, such as /var, this is a great time to adjust the partitions. For best results with file system modifications, Ignite-UX version 2.2 or later should be used.

• Hardware Modifications

While the extent of the hardware changes will be limited by time, performance optimizations such as adding another SCSI controller or replacing an older root disk with a larger, faster model can be accomplished at a rela-tively small incremental cost.

Performance tools such as HPs GlancePlus can be used to identify performance bottlenecks. More information on GlancePlus may be found through the internet at Software Depot (http://software.hp.com) and HP OpenView (http://openview.hp.com/products/).

• Kernel Tuning

(16)

(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 sev-eral methods that can be used, with most playing some part within the IT Resource Center (ITRC). The ITRC is a web-based environment available at http://ITResourceCenter.hp.com.

For those with the highest levels of system support, Hewlett-Packard provides proactive patch analysis. These support levels limit the need for dedicated patch resources with H-P selecting and monitoring the correct patches for your sys-tems. These options are not within the scope of this document, consult with your local H-P sales representative for more information.

The Patch Database

The Patch Database is the primary mechanism for searching for and acquiring patches for Hewlett-Packard custom-ers. Listed within the IT Resource Center as the "Individual Patches" selection of the "Maintenance and Support" area, it provides support for all operating systems and hardware. Figure 1 on page 10 shows the initial view seen when entering the Patch Database. This document will discuss two of the listed options, "HP-UX Patches" and "Retrieve a Specific Patch".

As this document is being prepared (January 2000), significant enhancements to the Patch Database are underway. These will be described in a future version of this document.

Searching for HP-UX Patches

The "HP-UX Patches" link of the main Patch Database screen leads to the "Searching and Browsing" screen. The first step identifies the system architecture and version of UX. In Figure 2, the checkbox for a series 700 running HP-UX 10.20 is selected. The next step requires the search string and mode.

(18)

The Patch Database

In a boolean search, the keywords are directly entered with optional logical operators. While not in conversational language, a well-built boolean search should provide the quickest method returning the fewest target patches. Figure 2 shows the preparation for a boolean search that will return only patches that match both "LVM" and "Mir-rored". Boolean search results are limited to displaying 200 documents of the total which qualify.

The precedence of boolean operators in a search are:

• 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 eval-uated 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".

(19)

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 descrip-FIGURE 2. Patch Database HP-UX Search Screen

(20)

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 3. Patch Search Results

(21)

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.

(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 10.20 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_16750. 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 dedi-cated to different geographic locations, us-ffs.external.hp.com for the Americas and Asia/Pacific and europe-ffs.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 email address.

(23)

The session should be set to transfer files in binary mode (bi) and toggled to allow the transfer of multiple files (prom).

(24)

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 con-nection 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:

FIGURE 7. Establishing an anonymous FTP session

patchsvr(103)-> ftp us-ffs.external.hp.com Connected to hpcc933.external.hp.com.

220-220-Welcome to the HP Electronic Support Center ftp server ---

220-220-You are user 0, and there is a limit of 200 simultaneous accesses.

220-220-Log in as user "anonymous" (using your e-mail address as your password) 220-to retrieve available patches for HP-UX, MPE/iX, and other platforms.

220-220-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.

220-220-If you have questions, send email to:

220-220- [email protected]

220-220 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 e-mail 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>

(25)

• /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 10.20 are found in the/hp-ux_patches/s700/10.X subdirectory. Note that patches common to both architectures are found unders700_800.

• /firmware_patches/hp (Firmware patches for HP Hardware)

Patches supplying firmware updates to HP hardware are found under this directory. Subdirectories exist for firm-ware specifically for CPUs, Fibre Channel, graphics cards, and I/O cards.

• /export/patches

(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 pop-up 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 sys-tem. 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. Cer-tain 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 depen-dencies 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 reg-ular 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..

(27)

FIGURE 9. Custom Patch Manager Main Screen

FIGURE 10. Executing the cpm_collect.sh script

$ sh cpm_collect.sh

cpm_collect.sh version: A.03.03

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.

(28)

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" sec-tion off of the main CPM page. It is recommended that the script be downloaded on a regular basis. It is a quick pro-cedure 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 privi-leges, 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 subdi-rectory on the ftp server. Please note that this disubdi-rectory 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 incom-ing directory is displayed. After the appropriate configuration file is selected, the candidate patch list can be dis-played. 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 hyper-linked 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 con-flict 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 fol-lowing 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 download-ing. 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.

(29)

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

(30)

FIGURE 12. Individual Patch Details (PHKL_20508)

(31)

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 e-mail notifi-cation 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 fil-ters) 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.

(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 e-mail 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 Notifica-tion 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 configura-tion 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 pro-file. 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 but-ton 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 notifi-cations. When used with each other, these category options act as a logical OR. For example, if you pick the Com-mand and Kernel options, you are asking to be notified of all patches which are related to the ComCom-mand 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.

(33)

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 10.20 and 11.00 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 11.00.

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

/cdrom/DIAGNOSTICS/B.10.20

Quarterly

Install specific diagnostic tools EMS-Config, EMS-Core, Pre-dictive, Sup-Tool-Mgr-700,

Sup-Tool-Mgr-800, or other products from the depot

Quarterly

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

Semi-annually

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 cus-tom 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

(34)

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 withioscan. 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 subdirec-tories. 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.

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

Hardware/Critical (HWCR) bundle from:

/cdrom/XSWHWCR1100

Quarterly

Bring all Core OS software to current patch level (without custom patch selection), including current Core OS Y2K changes

General Release (GR) bundle from:

/cdrom/XSWGR1100

Quarterly

Install all of the latest diagnostic tools OnlineDiag bundle from

Quarterly

Install specific diagnostic tools EMS-Config, EMS-Core, Predictive, Sup-Tool-Mgr-800,or other products from

(35)

• 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 avail-able from the Adobe web site (http://www.adobe.com/prodindex/acrobat/readstep.html).

• 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 subdirec-tory.

• 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 docu-mentation 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/XSWGR1100

2. 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 cre-ated 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.

(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 (http://www.software.hp.com) 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 pur-chase 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 http://www.software.hp.com/SUPPORT_PLUS.

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 http://www.software.hp.com/ACE 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 bun-dles and the original HP-UX Core. Software Depot provides the HWE patch bunbun-dles alone for download, and they may be accessed from the http://www.software.hp.com/products/HWE 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 2.2.160, DNS-BIND 8.1.2, Sendmail 8.8.6, and JFS 3.3.

(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.

(38)

(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 man-agement to system administrators limits the number of systems that each can control. By defining a depot, a cen-tralized 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.

(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 SDswcopycommand. The best example of this is the .depot file deliv-ered 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 Distribu-tor tools. The price of these new abilities was to introduce several new attributes to the SD objects. The

layout_versionattribute 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 oflayout_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 sys-tems. 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 environ-ment. 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.