## Patching with SD-UX; the Cleanup Command

### Scott W. Sarisky

Hewlett Packard
Phone: (770) 794-7662
E-mail: scott_sarisky@hp.com

The purpose of this paper is to inform you about what the cleanup command is and how it works on HP-UX 10.x. The cleanup command will "clean up" patch related areas.

Such as, removal of superseded patches in /var/adm/sw/patch, trimming of SD-UX logfiles, removal of superseded patches in a depot and clean the IPD (Installed Products Database). The cleanup command was originally released in patch PHCO_5400. However, new features were added to the command which in turn, caused PHCO_5400 to be superseded by PHCO_12140. So, the latest version of cleanup is version 2 and it is delivered in PHCO_12140.

PATCHING MECHANICS, BEHIND THE SCENE.

Prior to delving into the specifics of the cleanup command, an overview of what happens behind the scenes may be helpful. In the following example, watch how things change as newer versions of /sbin/mount are installed. The newer versions of /sbin/mount, in this example, are delivered in patches PHCO_1234 and PHCO_5678. These two patches are fictitious and are used for example purposes only.

1. HP-UX 10.20 prior to any patches for /sbin/mount.

    # what /sbin/mount

    /sbin/mount:
             $Revision: 78.9 $

     [Figure 1]

2. After PHCO_1234 is installed, which is a patch for /sbin/mount.

    # what /sbin/mount

    /sbin/mount:
             $Revision: 78.9.1.1 $

    # pwd

    /var/adm/sw/patch

    # ll

    drwxr-xr-x   2 root       sys          1024 Apr 11 17:47 .SUPERSEDED
    -rw-r--r--   1 root       sys          4377 May  5 11:30 PATCH.log
    drwxr-xr-x   4 root       sys          1024 Feb 26 13:48 PHCO_1234

                                                                               [Figure 2]

Notice, in figure 2, how /sbin/mount has a new revision number and see what was created under /var/adm/sw/patch directory. There are more directories under /var/adm/sw/patch/PHCO_1234. If you drill down this directory you will ultimately find the original mount command, revision 78.9. Everything under /var/adm/sw/patch/PHCO_1234 is there just in case you need to remove PHCO_1234 from the system. This is where swremove will find the previous revision of mount.

3. After PHCO_5678 is installed, which is also a patch for /sbin/mount and supersedes PHCO_1234.

    # what /sbin/mount

    /sbin/mount:
             $Revision: 78.9.1.2

    # pwd

    /var/adm/sw/patch

    # ll

    drwxr-xr-x   2 root       sys           1024 May  5 13:59 %PHKL_1234
    drwxr-xr-x   2 root       sys           1024 Apr 11 17:47 .SUPERSEDED
    -rw-r--r--   1 root       sys           4377 May  5 11:30 PATCH.log
    drwxr-xr-x   4 root       sys           1024 Feb 26 13:48 PHCO_5678

    #
                                                                     [Figure 3]

Again, notice how /sbin/mount has a new revision number and see what other directories were created under the /var/adm/sw/patch directory. The significance of the example is the percent sign in front of PHCO_1234. This percent sign denotes that this patch has been superseded. At this point, in this example, there are three versions of mount (see figure 4). The chances of ever needing to get back to the original revision of mount is very small. Therefore, any patch directory under /var/adm/sw/patch that starts with a percent sign is a directory that contains binaries and/or files that have been superseded at least twice.

       /sbin/mount                                    Revision 78.9.1.2
       /var/adm/sw/patch/PHCO_5678/usr/sbin/mount     Revision 78.9.1.1
       /var/adm/sw/patch/%PHCO_1234/usr/sbin/mount    Revision 78.9

                                                                           [Figure 4]

So, the more patches you apply to your system, the more "stuff" you are keeping under /var/adm/sw/patch. Please note that the files under individual patch names, i.e. PHCO_5678 are not the binaries and files for that particular patch. The files here are for the potential removal of that particular patch. Therefore, underneath PHCO_5678, you would find the files for removal of PHCO_5678. These include the scripts necessary to actually remove that patch and the binaries that were on the system before the patch was installed.

SD-UX LOGFILES.

Also, as a by product of using SD-UX commands, information is written to command specific logfiles. All of the logfiles (SD-UX), are located in the /var/adm/sw directory. For instance, information from the swinstall command will be logged to /var/adm/sw/swinstall.log. These logfiles can become quite large over time.

    # pwd
    /var/adm/sw

    # ll *.log

    -rw-r--r--   1 root       sys     368417 May  5 11:32 swagent.log
    -rw-r--r--   1 root       sys      73559 May  5 11:32 swagentd.log
    -rw-r--r--   1 root       root     41419 Mar  4 15:06 swconfig.log
    -rw-r--r--   1 root       sys      83087 Mar 30 17:21 swcopy.log
    -rw-r--r--   1 root       sys      52356 May  5 11:30 swinstall.log
    -rw-r--r--   1 root       root    113042 May  5 11:30 swmodify.log
    -rw-r--r--   1 root       sys       2506 Mar 23 14:11 swreg.log
    -rw-r--r--   1 root       sys      12501 Apr 23 09:19 swremove.log
    -rw-r--r--   1 root       sys        518 Mar  9 09:52 swverify.log

                                                                                 [Figure 5]

OPTIONS OF THE CLEANUP COMMAND

.

-t This option is for trimming the logfiles. It will reduce all of the SD logfiles to the last five iterations.

-F This will force removal of all patch directories under /var/adm/sw/patch. You will have more disk space after running this options. However, you will not be able removes any patches that are currently running on your system.

Blank This option is probably the most common, it is simply running the cleanup command with no options. First this will trim your logfiles. This is the same as the -t option. The command will prompt you before trimming just in case you do not want to trim. Secondly, it will remove the binaries and possibly the directories that start with a percent sign under /var/adm/sw/patch.

-i This option is for syncing the IPD (Installed Products Database).

-d This option is for removing superseded patches from a depot.

TRIMMING THE LOGFILES

When you run the cleanup command with no options or the –F option, you will be prompted to see if you want the logfiles trimmed to the last five entries. And if you reply yes, they will be trimmed. Also, if you just want to trim the logfiles, you can use the –t option. Of course it is always a good idea to store these logfiles to tape before trimming them.

    # cleanup -t

    This is the HP-PATCH disc space recovery tool.  It will automatically
    recover disc space for you that is being used for backup of original
    files that have been patched. As an added feature, if you like, your
    SD log files can also be trimmed.

    Trimming SD log files

        Trimming swagent.log
        Trimming swagentd.log
        Trimming swconfig.log
        Trimming swcopy.log
        Trimming swinstall.log
        Trimming swmodify.log
        Trimming swreg.log
        Trimming swremove.log
        Trimming swverify.log

    #
                                      [Figure 6]

REMOVING OLDER, SUPERSEDED PATCH FILES.

To remove older, superseded patches, i.e. the superseded patch directories that start with a percent (%) sign, see figure 3, run the cleanup command with no options. As always, it is a good idea to back things up prior to removing them from the system. See the note regarding backuplist in figure 7. Also, this option will trim the SDUX logfiles at your discretion.

    # cleanup

    This is the HP-PATCH disc space recovery tool.  It will automatically
    recover disc space for you that is being used for backup of original
    files that have been patched. As an added feature, if you like, your
    SD log files can also be trimmed.

    The log files for SD can get very large.  Would
    you like the logs trimmed to the last 5 entries? > n

    The following patch backups are marked for removal :

    %PHCO_10589  %PHCO_10964     %PHCO_11462     %PHCO_11585     %PHCO_11982
                                    |
                                    |
          Only the patches in /var/adm/sw/patch with a percent sign (%)
          will appear here.

    It is highly recommended that you backup the directory '/var/adm/sw/patch'
    before removing a large portion of its contents. If you have not done
    so, you may wish to reconsider completing this operation.

    NOTE: If you backup the '/var/adm/sw/patch' directory, use the list of files
          in '/var/adm/sw/patch/backuplist' as the list of files to backup.

    Continue with removal? > y

    >>>> Removed backup directory: %PHCO_10589              05/05/98  15:40:59
    >>>> Removed backup directory: %PHCO_10964              05/05/98  15:40:59
    >>>> Removed backup directory: %PHCO_11462              05/05/98  15:40:59
                         |
                         |
          Only the patches in /var/adm/sw/patch with a percent sign (%)
          will appear here.

    Backup removal complete.

    The results of this action have been logged to:
         '/var/adm/sw/patch/PATCH.log'.

                                                                                                                                          [Figure 7]

REMOVING ALL SUPERSEDED PATCH INFORMATION

This option of cleanup will remove all of the files required to remove a patch from you system. In other words, you will NOT be able to swremove any of the patches on your system after running the cleanup command with the –F option. The benefit of this option is that you will have more space in /var. The trade off is that you cannot remove any of the patches that are currently on your system. This option works like running the cleanup command with no option. The only difference is that it will remove all patch directories under /var/adm/sw/patch, not just those with the percent sign. Also, the –F option will give you a warning about not being able to back out any patches after running the command.

CLEANING UP A DEPOT.

To help understand the purpose of this option, you must first understand the concept of depots and the potential problem that can occur after adding new patches to a depot.

A depot, actually in this case a directory depot, is just a collection of patches. It is where multiple patches exist together for the purpose of being available to be swinstalled on multiple boxes. You would have a depot for each different version of HP-UX that you support. The following steps show a normal progression of a depot.

1. A depot is created, either manually or via the swcopy command.
2. Patches are added to the depot for the first time.
3. The depot is used to swinstall patches on multiple boxes.
4. Time goes by and newer patches are available, some are new others are supersedes.
5. Patches are added to the depot for the second time.

When patches are added to a depot for the second time, or anytime thereafter, there is a chance that some of the new patches just added replace older patches that are already in the depot. Following are two examples of situations that could occur in a depot where both a new and old version of a patch exists.

Example 1: Depot with PHCO_5555 and PHCO_8888 (these patch numbers are made up for this example). Both of these patches patch the same binary. When swinstall is executed using this depot, the checkinstall script is executed for each of the patches in the depot. In this example, both 5555 and 8888 will be approved for installation. This happens because at the time checkinstall is executed, neither 5555 nor 8888 is installed. Therefore swinstall will install both patches. A depot is really just a directory and directories are sorted lexically. Therefore, 5555 will go in first and 8888 will go in second. After swinstall completes, if swlist is executed to show what patches are on the system, both 5555 and 8888 will appear as installed. This is actually false information, as 5555 is not truly installed. This information is misleading but not typically detrimental because 8888 is the newer version of the patch.

Example 2: Depot with PHCO_7777 and PHCO_11111 (these patch numbers are made up for this example). Both of these patches patch the same binary. When swinstall is executed using this depot, the checkinstall script is executed for each of the patches in the depot. In this example, both 7777 and 11111 will be approved for installation. This happens because at the time checkinstall is executed, neither 7777 or 11111 is installed. Therefore swinstall will install both patches. A depot is really just a directory and directories are sorted lexically. Since these patches are in lexical order, PHCO_1 comes before PHCO_7. Therefore, 11111 will go in first and 7777 will go in

second. After swinstall completes, if swlist is executed to show what patches are on the system, both 7777 and 11111 will appear as installed. This is actually false information as 11111 is not truly installed. This situation is worse in comparison to the first example. The swlist will show you that 11111, the latest version of the patch is installed and it is not installed because 7777 was installed after it. Again, the "acid test" to determine what version is installed is to do a what on the binary and compare it the what string in the patch text file.

Therefore, you should always "clean up" your depot after adding more patches to it. To do this, you would run the cleanup command with the –d option. On the next page, in figure 8, there is an example of cleaning a patch depot. Also, when you use the –d option, it does not touch any other patch information outside of the depot that you are running it on. It does not touch the binaries that are currently installed, it does not touch the IPD (installed products database) and it does not do anything with the files under /var/adm/sw/patch.

    # cleanup -d /patch/prod.depot

    This utility will locate all patches in the  depot '/patch/prod.depot'
    that have been superseded by patches also available from this depot.
    After identifying the superseded patches, it will request confirmation
    before removing the patches from the depot.

    Obtaining the list of superseded patches in the depot...
      The following patches in the depot have been superseded by patches
      also in the same depot.

            Superseded Patch        Replacement Patch(es)
            ----------------        ---------------------
            PHCO_11004              PHCO_11315
            PHCO_8677               PHCO_11586
            PHKL_9711               PHKL_11471
            PHNE_10511              PHNE_11051

    Hit [Return] to continue...

    Would you like to continue with the process to remove these
    superseded patches from the depot? y

    In addition to the superseded patches listed, there may also be
    patches in the depot that have corequisite attributes
    (hard-coded dependencies) on one or more of the superseded patches.
    Patches with corequisites are typically from the HP-UX Extension
    Software.  If these patches exist in the depot, they will also need
    to be removed to maintain the integrity of the depot.

    Now checking for patches with corequisite attributes set for one or
    more superseded patches. Please be patient, this may take several
    minutes.

    No other patches were found in the depot that have corequisite
    attributes set for superseded patches targetted for removal.

    Do you wish to continue with the removal of the superseded patches
    from the depot? y

    Please be patient, this may take several minutes.

    Removing patches from the depot...done!

    The superseded patches have been removed from '/patch/prod.depot'.

    #
                                                                               [figure 8]

CLEANING UP THE IPD.

The IPD, Installed Products Database, is made up of many files under the /var/adm/sw/products directory. At 10.x, SD (Software Distributor) considers patches as products. Therefore, when a patch is installed, information is recorded in the IPD. Under certain circumstances, the IPD can get out of sync with what is really on the box. Specifically, when you have a system at 10.01 or 10.10 and you have patches on the box. If you upgrade to 10.20, again, upgrade not install, the patch information will still reside in the IPD. At that point the IPD is not in sync with what you have on the box. To correct this, run cleanup (see figure 9). This scenario can also happen when you reinstall a product on your system after the original product was patched. Also, if you restore from a backup tape and that backup tape was made prior to having patches on the system, the potential is there for the IPD to be out of sync.

    # cleanup -i

    This utility will identify the patches that have been overwritten by
    the installation of software products during an upgrade or install
    process.  Once the patches are identified, it will request confirmation
    before removing the patch information from the SD-UX Installed Product
    Database.

    Obtaining the list of installed products and patches... done!

    Comparing installed product and patches information...

    All the patches in the SD-UX Installed Product Database

    appear to be installed.

    No action is required.

                                                                           [figure 9]

cleanup man page

    cleanup - HP-UX patch cleanup utility

          Synopsis:
          cleanup [-F]|[-t]|[-i]|[-d absolute_path_to_depot]

     DESCRIPTION:
          The cleanupp command provides several functions useful when dealing
          with HP-UX patches.  It is used as an aid in managing disk space
          consumed by the storage of backup files during the installation of a
          patch.  The cleanup command is also used to remove patch information
          from the SD-UX Installed Product Database (IPD) after patches have
          been overwritten by software updates.  The cleanup command provides an
          additional option to remove patches from a software depot if they have
          been superseded by newer patches also available in the same depot.
          Another feature of cleanup is its ability to trim the SD log files
          located in /var/adm/sw/sw*.log.

          No file removal will occur without user confirmation.

          There are 5 modes of operation for cleanup

                When run in this mode, cleanup will remove all backups of
                patches that have been superseded and prompt for trimming of the
                log files.  Removal of superseded patch save areas will still
                leave enough data on the system to allow patch removal back one
                level but would preclude removing a series of patches, each
                superseding the next.  In this mode, some accounting information
                (less than 1K) will be left on the system for 1 level back of
                superseded patch to allow for SD-database synchronization should
                a superseding patch be removed from the system.

               -F (force removal of all backups)

                When run in this mode, cleanup will remove all backups of
                patches, not just those which have been superseded.  This will
                recover the most disk space possible using this tool, but will
                eliminate the possibility of backing out any currently installed
                patch off of the target system.  There is a confirmation step
                before any backup removal takes place.

               -t (trim SD log files only)

                When run in this mode, cleanup will simply trim all the SD log
                files located in /var/adm/sw/sw*.log.  These log files will be
                trimmed to their most recent five entries.  There is no
                confirmation step when trimming the log files only.

               -i (remove overwritten patches from the IPD)

                When run in this mode, cleanup determines which patches that are
                included in the Installed Product Database have been overwritten
                by software product installations or updates.  These patches are
                removed from the IPD upon confirmation from the user so that
                they are no longer displayed in the output of the swlist(1M)
                command.
    -d absolute_path_to_depot (remove superseded patches from depot)

                When run in this mode, cleanup determines which patches in the
                software depot have been superseded by newer patches also
                available from the depot.  Upon confirmation from the user,
                these superseded patches will be removed from the software
                depot.

     RECOMMENDATIONS:

          The cleanup command should be executed when additional disk space is
          required on the filesystem containing the /var/adm/sw/patch directory.

          The cleanup -F command should be executed when additional disk space
          is required on the filesystem containing the /var/adm/sw/patch
          directory AND the user is confident that none of the patches will ever
          need to be removed.

          The cleanup -i command should be executed whenever software products
          (including the operating system) are installed, reloaded, or updated.

          The cleanup -d command should be executed whenever patches are added
          to a software depot.