12.11 Removing Patches and Committing Patches

     

The ability to remove a patch and return the product to its previous state is known as patch rollback . It is implemented by Software Distributor via the option “x patch_save_files=true to the swinstall command. The default behavior of Software Distributor is to save the current incarnation of the patched software to facilitate patch rollback at some time in the future. Overriding this default can cause serious problems if you subsequently need to implement patch rollback . It is strongly advised that you always maintain the previous incarnation of software just in case. This will save the original versions of the affected files under a directory named /var/adm/sw/save/<patch name >/ . Here, we can see the saved files on my system relating to the FooProd patches:

 

 root@hpeos004[]  swlist -l patch -x show_superseded_patches=true -a patch_state FooProd  # Initializing... # Contacting target "hpeos004"... # # Target:  hpeos004:/ # # FooProd # FooProd.FOO-HELP # FooProd.FOO-MIN   PHCO_1000.FOO-MIN     superseded   PHCO_2000.FOO-MIN     superseded   PHCO_3000.FOO-MIN     applied root@hpeos004[] root@hpeos004[]  ll -d /var/adm/sw/save/PHCO_[1234]000  drwxr-xr-x   3 root       sys             96 Sep 26 15:45 /var/adm/sw/save/PHCO_1000 drwxr-xr-x   3 root       sys             96 Sep 26 16:10 /var/adm/sw/save/PHCO_2000 drwxr-xr-x   3 root       sys             96 Sep 26 16:10 /var/adm/sw/save/PHCO_3000 root@hpeos004[] 

When we remove a patch, e.g., PHCO_3000 , Software Distributor will restore the product to patch level PHCO_2000 because the files under the directory /var/adm/sw/save/PHCO_3000 hold that incarnation of the software. This gives us a warm feeling inside because we know that if a patch is recalled, we can always go back to the previous patch level without much trouble.

If we are to attempt to remove PHCO_2000 , Software Distributor is clever enough to realize that PHCO_2000 is part of a supersession chain. Software Distributor will not remove PHCO_2000 because that would mean we would leave the saved files for PHCO_3000 on the system, which would not make any sense. We would have to remove PHCO_3000 first and then remove PHCO_2000 .

12.11.1 Committing patches

As the number of patches you install on a system increases , the disk space used for patch rollback can become quite considerable. Some administrators will want to save the disk space under this directory by removing superseded patches. It is dangerous to simply remove the relevant directories because Software Distributor expects patch save files to be available when a patch is in the applied state. I suppose that we could temporarily remove them as long as we recovered them when they were needed. The formal method of recovering this disk space it to commit patches. Personally, I don't like this idea because it removes the saved files for a given patch level. This means that we cannot perform patch rollback to return a product to its former state. To return a product to its former state, we would have to remove the committed patch, remove the fileset itself, and then reinstall the fileset from our source media/depot. Committing patches is the same as overriding the “x patch_save_files=true option to swinstall . We can also use the swmodify command to commit patches. Once committed, we will see that as being the patch_state . Here's an example where we have the FooProd product and patches PHCO_1000 , PHCO_2000 , and PHCO_3000 all installed:

 

 root@hpeos004[]  swlist -l patch -x show_superseded_patches=true -a patch_state FooProd  # Initializing... # Contacting target "hpeos004"... # # Target:  hpeos004:/ # # FooProd # FooProd.FOO-HELP # FooProd.FOO-MIN   PHCO_1000.FOO-MIN     superseded   PHCO_2000.FOO-MIN     superseded   PHCO_3000.FOO-MIN     applied root@hpeos004[] root@hpeos004[]  ll -d /var/adm/sw/save/PHCO_[1234]000  drwxr-xr-x   3 root       sys             96 Sep 26 17:03 /var/adm/sw/save/PHCO_1000 drwxr-xr-x   3 root       sys             96 Sep 26 17:04 /var/adm/sw/save/PHCO_2000 drwxr-xr-x   3 root       sys             96 Sep 26 17:04 /var/adm/sw/save/PHCO_3000 root@hpeos004[] 

As we can see, we have full patch rollback in place; we can roll back to whatever patch level is necessary simply by removing the relevant patch with swremove . If we commit patch PHCO_3000 , we will lose all rollback functionality:

 

 root@hpeos004[]  swmodify -x patch_commit=true PHCO_3000  root@hpeos004[]  swlist -l patch -x show_superseded_patches=true -a patch_state FooProd  # Initializing... # Contacting target "hpeos004"... # # Target:  hpeos004:/ # # FooProd # FooProd.FOO-HELP # FooProd.FOO-MIN   PHCO_1000.FOO-MIN     superseded   PHCO_2000.FOO-MIN     committed/superseded   PHCO_3000.FOO-MIN     committed root@hpeos004[]  ll -d /var/adm/sw/save/PHCO_[1234]000  drwxr-xr-x   3 root       sys             96 Sep 26 17:15 /var/adm/sw/save/PHCO_1000 root@hpeos004[] 

Although it looks like we can remove PHCO_1000 , we will come across a problem if we try to remove it:

 

 root@hpeos004[]  swremove PHCO_1000  =======  09/26/03 17:19:51 BST  BEGIN swremove SESSION          (non-interactive) (jobid=hpeos004-0108)        * Session started for user "root@hpeos004".        * Beginning Selection        * Target connection succeeded for "hpeos004:/". NOTE:    One or more patch filesets were automatically selected or          deselected to maintain patch integrity. Please refer to the          swremove.log logfile for details. ERROR:   Cannot continue the "swremove" task.        * Selection had errors. =======  09/26/03 17:19:52 BST  END swremove SESSION (non-interactive)          (jobid=hpeos004-0108) root@hpeos004[] 

When we look at the swremove.log file, we can see the problem.

 

 root@hpeos004[]  more /var/adm/sw/swremove.log  ... =======  09/26/03 17:19:51 BST  BEGIN swremove SESSION          (non-interactive) (jobid=hpeos004-0108)        * Session started for user "root@hpeos004".        * Beginning Selection        * Target connection succeeded for "hpeos004:/". WARNING: The fileset "PHCO_1000.FOO-MIN" has been automatically          deselected because one or more of the filesets in the patch          have been committed or superseded. NOTE:    One or more patch filesets were automatically selected or          deselected to maintain patch integrity. Please refer to the          swremove.log logfile for details. ERROR:   Cannot continue the "swremove" task.        * Selection had errors. =======  09/26/03 17:19:52 BST  END swremove SESSION (non-interactive)          (jobid=hpeos004-0108) root@hpeos004[] 

Returning FooProd to a previous revision will require us to remove FooProd itself. This will automatically remove PHCO_1000 and PHCO_3000 . From there, we can reinstall the base product and patch it accordingly .

There is a command called /usr/sbin/cleanup , which is provided as part of patch PHCO_24630 on HP-UX 11i. The cleanup command is a convenient interface to committing a whole series of patches (use the option “c <number> ) on a system without having to specify patches individually. It has a preview option -p that will perform all the necessary steps except actually committing the patches. The cleanup command has some other, more useful options including the following:

-i: Remove HP-UX 10.X patches that remain in the Installed Product Database after an upgrade to HP-UX 11.11. These patches are removed from the IPD so that they are no longer displayed in the output of the swlist command. The HP-UX 10.X patch files are also removed from /var/adm/sw/patch .

-s: Correct the patch_state attribute for HP-UX 11.X patches.

It is suggested that you perform a significant backup, possibly a make_[nettape]_recovery before committing patches. Be careful.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net