22.3 Installing Customer Specific Patches

Sometimes your system will need a patch that does not exist as part of a current aggregate patch kit. It could be that you reported a problem to HP Support, and they provided a Customer Specific Patch (CSP) for you to install to correct whatever problem you were having. Alternatively, there may already be an Early Release Patch that was on the ftp (1) server but not in the currently shipping patch kit. Usually with these patches you can either install them "manually" or by using the rolling upgrade method. Let's look at installing this patch manually. For more on rolling upgrades see Chapter 25.

Let's take this fictitious patch as an example. You may have gotten this patch by way of HP Services or maybe you found it on the Tru64 UNIX ftp patch site:

http://ftp.support.compaq.com/public/unix/v5.1a/

The first step after copying the file down with ftp is to verify the checksum of the patch tar file. There are sum (1) and cksum (1) checksums listed in the README file in addition to more complex "checksums" MD5 and SHA1 results. Here is how to check this checksum (sum):

 # sum TCV51AB1-C0000000-11111-M-20020521.tar 60146 2810 TCV51AB1-C0000000-11111-M-20020521.tar

The reason we want to verify the file (checksum or one of the other verification methods) is that we want to be reasonably sure that we don't have a truncated tar file. Nothing can waste a system administrator's time like chasing a problem that only exists because of a file transfer problem. Once we've verified that the file is good, we'll create an install directory and untar the kit and run the installation script.

 # mkdir -p /tmp/CSPkit1 # cd /tmp/CSPkit1 # tar -xvpf TCV51AB1-C0000000-11111-M-20020521.tar # cd patch_kit/TruCluster_V5.1A/ManualKit # ./TCRPATC0000000520.install.sh

After running the script, the patched files (which usually contain ".mod" files that are used to deliver kernel changes) are moved into place, and if a kernel rebuild is required you are prompted to perform the kernel build. Don't forget to do this on each member in the cluster and then to cp (1), notmv (1), the new kernel into place. To save space, you can then remove the kernel in /sys/HOSTNAME. For more on kernel building and cleanup see section 12.2.1.

Now all that is required is a cluster-wide reboot^[1] for the patches to take effect.

^[1]Currently you cannot automatically reboot the entire cluster. You will need to shutdown the entire cluster (i.e., "shutdown -c now") and boot each member.