| At the time of this writing, there were 365 patches listed on the ITRC for HP-UX 11i. By the time you read this, I am sure there will be one or possibly two more. Not all of those patches will be applicable to an individual site. However, it is common where we have a number of similar machines on our network that we will want to set up a depot that contains all the patches that apply to those machines. From that depot, we can install individual patches or whole collections of patches. The machine that hosts the patch depot is commonly known as a patch server . There is an interesting choice when setting up a patch depot: -
-
A depot of software and associated patches Before we discuss each of these options, consider the following bullet-points: -
Will you maintain patches for multiple operating systems? When supporting multiple operating systems, you might want to set up a directory structure for your patches that reflects the different operating system revisions. Table 12-3. Example Patch Depot Structure to Support Multiple Operating System Revisions | Directory name | Description | | /software/11i-PA/ | Software and patches for HP-UX 11i version 1 | | /software/11i-IPF/ | Software and patches for HP-UX 11i version 1.5, 1.6 and 2 | | /software/11.0/ | Software and patches for HP-UX 11.0 | | /software/10.20/ | Software and patches for HP-UX 10.20 | If you are going to set up a software-and-patches depot including the software on the HP-UX Applications media, I suggest further subdividing the directory structure into ../ core and ../apps . This will allow you to distinguish between the Core operating system and non-Core applications. -
Do you have adequate disk space on the machine acting as the patch server? It would be prudent to set up a separate filesystem to house the patches. For maximum flexibility, you should create the filesystem in a resizable volume, i.e., use either Logical Volume Manager or Veritas Volume Manager. For maximum flexibility, the Veritas filesystem (VxFS) should also be used. With these options, it is possible to resize the filesystem and volume online, i.e., while users are using the filesystem. Note : The necessary software licenses will need to be purchased to accomplish this: either an Enterprise Operating Environment license (HP-UX 11i) or a license for OnLine JFS (Advanced VxFS) for other versions of HP-UX. -
Have you resolved all the dependencies required by a given patch? It is sometimes the case that installing one patch requires that other patches be already installed or part of the same depot in order for them to be selected and installed at the same time. There are Patch Dependencies, Hardware Dependencies, and Other Dependencies that are documented in the patch .text file. In order to meet all dependencies, it may be necessary to investigate all patch dependencies because subsequent patches may have dependencies themselves . If you use the ITRC to select individual patches, the ITRC can resolve these inter-dependencies, allowing you to download all relevant patches in one visit. -
Has the patch server been adequately patched itself? The patch server will be serving a large community of machines and should be online for as long as possible. Proactive patching may be worth thinking about in order to avoid known problems with the patch server itself. 12.9.1 A patch-only depot A patch-only depot is a depot that holds patches exclusively. No base software is held in the depot at all. This type of depot is suited to sites where administrators prefer to install the base software separately; test the base software in isolation, and then choose certain patch installations only when necessary. Here are some of the benefits of a patch-only depot: -
The most up-to-date patches are easy to install. With Software Distributor making use of the supersedes attribute, the most up-to-date patch will be selected when a patch install is performed. There is also the possibility of overriding this if a particular patch level is required. -
Use -x patch_match_target=true for easier selection. This option to swinstall allows the administrator to avoid individual patch selection. With this option, Software Distributor will select all relevant patches, and their dependencies, based on the base software already installed on the system. -
You have only one location to maintain. Having one depot for all patches eases the burden of disk space management and performing backups . Utilizing LVM/VxVM and VxFS features can allow online resizing of this filesystem when necessary. -
You can hold multiple versions of patches in one location. Software Distributor has the ability to select the patches highest in the supersession chain due to the supersedes attribute. However, in the event of having a patch recall, the administrator can remove an individual patch from the depot, allowing a previous revision of the patch to be subsequently installed. -
Having no base software held in depot is less confusing. For some administrators, having a mix of software and patches in the same depot can be confusing. Having only patches in the depot makes it much clearer what the depot is intended for. It can also allow the administrator to set up a software-only depot that contains only the base software. For some administrators, this is easier to understand, easier to manage, and cleaner in its purpose. 12.9.2 A depot of software and associated patches The software-and-patches depot is where the depot holds base software and patches together. This type of depot is suited to sites where administrators would like to install software and have that software patched automatically during the software installation. Here are some of the benefits of a software-and-patch depot: -
The most up-to-date patches are easy to install. With Software Distributor making use of the supersedes attribute, the most up-to-date patch will be selected when a patch install is performed. There is also the possibility of overriding this if a particular patch level is required. -
Use -x patch_match_target=true for easier selection. This option to swinstall allows the administrator to avoid selecting individual patches. With this option, Software Distributor will select all relevant patches, and their dependencies, based on the base software already installed on the system. -
Use -x autoselect_patches=true for easier installation. This attribute is the default behavior for Software Distributor. During the installation of a base product, if patches are located in the same depot, they will automatically be selected along with the base software. In this way, only one reboot (if necessary) will be performed for both the software install and the patch install. -
You have only one location to maintain for both software and patches. Having one depot for all patches ease the burden of disk-space management and performing backups. Utilizing LVM/VxVM and VxFS features can allow online resizing of this filesystem when necessary. -
You can hold multiple versions of patches and software in one location. Software Distributor has the ability to select the patches highest in the supersession chain due to the supersedes attribute. However, in the event of having a patch recall, the administrator can remove an individual patch from the depot allowing a previous revision of the patch to be subsequently installed. -
It mimics the Installation CD/DVD depot. HP creates the HP-UX installation CDs/DVDs such that any current patches are loaded onto the CD along with the base software. During the installation of HP-UX, all necessary patches loaded on the CD/DVD will automatically be selected as well. This cuts down on the time for installing the software and patches because only one reboot takes place. 12.9.3 The process of setting up the patch depot Enough talking. Let's get down to the process of setting up the patch depot, regardless of whether it is a patch-only or a software-and-patches depot. The process can be summarized as follows : -
One-time setup tasks -
Create a separate filesystem large enough to accommodate all current patches. -
Set up a depot directory structure for multiple operating system support. -
Ongoing tasks -
Copy software/patches into the patch depot. -
Remove redundant software/patches from the patch depot (we look at that a little later). Because you readers are supposed to be advanced administrators, I will assume you are okay with creating a separate filesystem using LVM/VxVM and using a VxFS filesystem. I have taken +30GB for my patch depot:
root@hpeos004[] bdf /software Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol11 34021376 3312 33752304 0% /software root@hpeos004[] ll /software/ total 0 drwxrwxr-x 2 root sys 96 Sep 26 12:36 10.20 drwxrwxr-x 2 root sys 96 Sep 26 12:35 11.0 drwxrwxr-x 2 root sys 96 Sep 26 12:35 11i-IPF drwxrwxr-x 2 root sys 96 Sep 26 12:35 11i-PA drwxr-xr-x 2 root root 96 Sep 26 12:34 lost+found root@hpeos004[]
If you are going to use a logical volume within vg00 , you might want to consider how this will affect your make_[tapenet]_recovery procedure. Do you want to include or exclude this directory from your recovery archive? If you decide to include these directories, the process to create a recovery archive will be considerably longer and require a tape that can accommodate all that data. On the other hand, with this directory included, we can recover the patch server much quicker. I leave it to you to decide. Let's look at copying some patches into our patch depot . Before we throw ourselves into an swcopy command, we need to mention a word about dependencies. With swinstall and swcopy , the default behavior is to enforce_dependencies=true . If we override this default during a swinstall , we could render a system unstable and prone to many future problems. With swcopy , the situation is slightly different. When we have individual patch depots ( .depot files), those individual files will not contain any dependencies for that patch. Here's an example: Patch PHCO_24839 (for HP-UX 11i) has a dependency of PHNE_23502 (or a superseding patch). I downloaded the individual patch shar file PHCO_24839 . When I tried to copy this into my depot, I experienced the following problem:
root@hpeos004[] swcopy -s /tmp/PHCO_24839.depot \* @ /software/11i-PA ======= 09/26/03 12:58:04 BST BEGIN swcopy SESSION (non-interactive) (jobid=hpeos004-0055) * Session started for user "root@hpeos004". * Beginning Selection * "hpeos004:/software/11i-PA": This target does not exist and will be created. NOTE: The software "PHCO_24839" was successfully marked, but it depends on the following software items which could not be found in the source. However, these items may already be in the target. This will be checked during the Analysis Phase: PHNE_23502.NISPLUS-CORE,fa=HP-UX_B.11.11_32/64 * Source: /tmp/PHCO_24839.depot * Targets: hpeos004:/software/11i-PA * Software selections: PHCO_24839.CORE-SHLIBS,r=1.0,a=HP-UX_B.11.11_32/64,v=HP,fr=1.0,fa=HP-UX_B.11  .11_32/64 * Selection succeeded. * Beginning Analysis and Execution * Session selections have been saved in the file "/.sw/sessions/swcopy.last". ERROR: "hpeos004:/software/11i-PA": The software dependencies for 1 products or filesets cannot be resolved. * The analysis phase failed for "hpeos004:/software/11i-PA". * Analysis and Execution had errors. NOTE: More information may be found in the agent logfile using the command "swjob -a log hpeos004-0055 @ hpeos004:/software/11i-PA". ======= 09/26/03 12:58:05 BST END swcopy SESSION (non-interactive) (jobid=hpeos004-0055) root@hpeos004[]
The error above relates to the fact that I don't have the dependency either in the source .depot file or in the target depot itself. In this case, I might want to override the enforce_dependencies=true option in order to copy the patch into the depot. At some point in the not-too- distant future, I should copy all dependent patches into the depot. Without them, installing the patch will fail because the dependencies will not be available.
root@hpeos004[] swcopy -x enforce_dependencies=false -s /tmp/PHCO_24839.depot \* @ /software/11i-PA ======= 09/26/03 13:04:53 BST BEGIN swcopy SESSION (non-interactive) (jobid=hpeos004-0061) * Session started for user "root@hpeos004". * Beginning Selection * "hpeos004:/software/11i-PA": This target does not exist and will be created. NOTE: The software "PHCO_24839" was successfully marked, but it depends on the following software items which could not be found in the source. However, these items may already be in the target. This will be checked during the Analysis Phase: PHNE_23502.NISPLUS-CORE,fa=HP-UX_B.11.11_32/64 * Source: /tmp/PHCO_24839.depot * Targets: hpeos004:/software/11i-PA * Software selections: PHCO_24839.CORE-SHLIBS,r=1.0,a=HP-UX_B.11.11_32/64,v=HP,fr=1.0,fa=HP-UX_B.11 .11_32/64 * Selection succeeded. * Beginning Analysis and Execution * Session selections have been saved in the file "/.sw/sessions/swcopy.last". WARNING: "hpeos004:/software/11i-PA": The software dependencies for 1 products or filesets cannot be resolved. * The execution phase succeeded for "hpeos004:/software/11i-PA". * Analysis and Execution succeeded. NOTE: More information may be found in the agent logfile using the command "swjob -a log hpeos004-0061 @ hpeos004:/software/11i-PA". ======= 09/26/03 13:04:54 BST END swcopy SESSION (non-interactive) (jobid=hpeos004-0061) root@hpeos004[]
If this is the first time I have copied patches/software into my depot, swcopy will register the target depot as a Software Distributor depot entity:
root@hpeos004[] swlist -l depot # Initializing... # Target "hpeos004" has the following depot(s): /depots/patches /software/11i-PA root@hpeos004[]
For the rest of this demonstration, I am going to use a fictitious product call FooProd and its associated patches PHCO_1000 , PHCO_2000 , PHCO_3000 and PHCO_4000 . The product and associated patches will allow us to explore managing patches and patch depots. I have used the swcopy command to copy the product and the patches into my patch depot. (I have removed the PHCO_24839 from the depot to make it easier to follow.)
root@hpeos004[] swlist -d @ /software/11i-PA # Initializing... # Contacting target "hpeos004"... # # Target: hpeos004:/software/11i-PA/ # # # No Bundle(s) on hpeos004:/software/11i-PA/ # Product(s): # FooProd 1.0 This is an example 11.X product. PHCO_1000 1.0 Foo Cumulative Patch PHCO_2000 1.0 Foo Cumulative Patch PHCO_3000 1.0 Foo Cumulative Patch PHCO_4000 1.0 Foo Cumulative Patch root@hpeos004[]
This all looks quite simple; we have a base product called FooProd and a supersession chain involving all four patches. Well, it's nearly that simple. I have included another Software Distributor attribute in order for us to understand the relationship between base products and associated patches. We are talking about prerequisites and co-requisites . We talked about dependencies when we looked at swcopy previously. The difference between prerequisite and co-requisite is a little esoteric, but it's worth knowing about in case you come across it in a real-world situation. The swinstall , swcopy , swverify , and swremove commands recognize software dependencies. The default behavior for swinstall , for example, prevents an install unless all dependencies are met. Dependencies may be defined as follows: -
A fileset may depend on another product (or a subset of that product). -
A fileset may depend on a particular fileset within a product. -
A fileset may depend on an entire product. Software Distributor supports these types of dependencies: Co-requisite : Software that must be present for a fileset to operate correctly. For example, specifying a co-requisite for an install fileset means that the co-requisite must be installed before or when the fileset itself is installed. (Note that a co-requisite dependency does not imply any run-time dependency, i.e., load order.) Ex-requisite : Software that may not be present when the fileset is operated on by Software Distributor. For example, specifying an ex-requisite for a fileset prevents the fileset from being installed if any of the specified ex-requisite software objects are installed or are being installed. Prerequisite : Software that must be installed and/or configured correctly before a fileset can be operated on by Software Distributor. Prerequisites control the order of an installation with swinstall (install-time dependency). Let's look at an example of this with our product FooProd and its associated patches. -
FooProd consists of three programs bar , foo , and foo2 . -
PHCO_1000 fixes a problem in program bar . PHCO_1000 supersedes FooProd . -
PHCO_2000 includes the fixed program bar , but also fixes a problem in the program foo . PHCO_2000 supersedes PHCO_1000 . -
PHCO_3000 includes the fixed programs bar and foo , and fixes a problem with program foo2 . PHCO_3000 supersedes PHCO_2000 . -
PHCO_4000 adds functionality to the product by including a new program foobar . As such, it doesn't necessarily supersede any other patches. If it contained (as it does here) all the fixed programs, bar , foo , and foo2 , it could be said to supersede PHCO_3000 . Normally, adding functionality will mean that a patch uses a name similar to the product itself as opposed to using a patch handle . Remember, this is only an example. This means that to load patch PHCO_4000 we have a co-requisite of product FooProd . That makes some sort of weird sense. You don't want to add functionality to a product that doesn't exist in the first place.
root@hpeos004[] swlist -d -a corequisite PHCO_4000 @ /software/11i-PA # Initializing... # Contacting target "hpeos004"... # # Target: hpeos004:/software/11i-PA # # PHCO_4000 PHCO_4000.FOO-MIN FooProd.FOO-MIN,fr=1.0,fa=HP-UX_B.11.00_32/64,v=HP root@hpeos004[]
Similarly, for PHCO_4000 to work properly, it is assuming that we have the most up-to-date version of the product by having a prerequisite of the product via patch PHCO_3000 .
root@hpeos004[] swlist -d -a prerequisite PHCO_4000 @ /software/11i-PA # Initializing... # Contacting target "hpeos004"... # # Target: hpeos004:/software/11i-PA # # PHCO_4000 PHCO_4000.FOO-MIN PHCO_3000.FOO-MIN,fr=1.0,fa=HP-UX_B.11.00_32/64,v=HP root@hpeos004[]
You may be wondering why the big fuss over prerequisites and co-requisites. It's important that we have a handle on this when we come to managing a patch depot. When we come to remove software from a depot, the value of the two options enforce_dependencies and autoselect_dependents have a huge bearing on what, if anything, will be removed from the patch depot. Setting up a real patch depot can take many hours. If we are setting up a software-and-patches depot, we will need to load all of the Core OS disks as well as all the Applications media. From there, we can move onto the Support Plus media as well as any individual patch bundles that you download from the ITRC or receive directly from your local Response Center. I think we are now ready to install some patches. |
