Apply Patches to CPS

Apply a Patch

This section describes the general process to apply a patch to CPS.

Patches must be applied during a maintenance window. This section includes instructions for stopping all CPS components before applying the patch and restarting the components after the patch has been applied.


Note
Only one patch can be applied to CPS at a time. If you have already applied a patch, you must Undo and then Remove the existing patch before applying the new patch. Refer to Undo a Patch and Remove a Patch for more information. To determine if a patch is currently applied to the system refer to List Applied Patches.

Procedure

Step 1

Run patch -u and patch -r to remove any applied patches from the Cluster Manager before proceeding. For more information, refer to Undo a Patch and Remove a Patch.

Step 2

Download the latest patch file from a location provided by your Cisco representative to the Cluster Manager VM.

Step 3

Log in to the Cluster Manager as a root user.

Step 4

Download the patch file to the Cluster Manager VM. For example:

wget http://siteaddress/xxx.tar.gz

where,

siteaddress is the link to the website from where you can download the patch file.

xxx.tar.gz is the name of the patch file.

Step 5

Run the patch -a command to apply the patch:

/var/qps/install/current/scripts/patch/patch -a filename.tar.gz

where filename is the path and filename of the downloaded patch file.

For example:

/var/qps/install/current/scripts/patch/patch -a /tmp/CPS701_1234.tar.gz

Step 6

Run the following command to restore the Policy Builder configurations.

/var/qps/install/current/scripts/setup/restorePolicyRepositories.sh

Step 7

Run build_all.sh script to create updated CPS packages. This builds updated VM images on the Cluster Manager with the new patch applied.

/var/qps/install/current/scripts/build_all.sh

Step 8

Update the VMs with the new software using reinit.sh script. This triggers each CPS VM to download and install the updated VM images from the Cluster Manager:

/var/qps/install/current/scripts/upgrade/reinit.sh

Step 9

Refer to section Rolling Restart of CPS VMs QNS Process (Odd Sides) and Rolling Restart of CPS VMs QNS Process (Even Sides) for further steps.

Step 10

Run about.sh to verify that the component is updated:

about.sh

What to do next

After applying a patch in HA deployment, run the following command from Cluster Manager:

puppet apply --logdest=/var/log/cluman/puppet-custom-run.log --modulepath=/opt/cluman/puppet/modules --config=/opt/cluman/puppet/puppet.conf /opt/cluman/puppet/nodes/node_repo.pp

Note

Manually enter puppet apply command in your system.

After applying the puppet apply command, run the following command from Cluster Manager to update the /etc/httpd/conf/httpd.conf file on all VMs:

/var/qps/install/current/scripts/modules/update_httpd_conf.py

Rolling Restart of CPS VMs QNS Process (Odd Sides)


Important
The commands mentioned in the steps must be entered manually.

Procedure

Step 1

Stop Policy Server (qns) process:

for vmName in `hosts.sh | sort | sed -n 'p;n'`; do echo $vmName; ssh $vmName "service monit stop"; ssh $vmName "service qns stop"; echo; done

Step 2

Verify whether the Policy Server (qns) process has stopped:

for vmName in `hosts.sh | sort | sed -n 'p;n'`; do echo $vmName; ssh $vmName "service qns status"; echo; done

Step 3

Start Policy Server (qns) process:

for vmName in `hosts.sh | sort | sed -n 'p;n'`; do echo $vmName; ssh $vmName "service qns start"; ssh $vmName "service monit start"; echo; done

Step 4

Verify that the Policy Server (qns) process has started:

for vmName in `hosts.sh | sort | sed -n 'p;n'`; do echo $vmName; ssh $vmName "service qns status"; echo; done

Step 5

Verify the CPS health status using the diagnostics.sh script.

Rolling Restart of CPS VMs QNS Process (Even Sides)


Important
The commands mentioned in the steps must be entered manually.

Procedure

Step 1

Stop Policy Server (qns) process:

for vmName in `hosts.sh | sort | sed -n 'n;p'`; do echo $vmName; ssh $vmName "service monit stop"; ssh $vmName "service qns stop"; echo; done

Step 2

Verify whether the Policy Server (qns) process has stopped:

for vmName in `hosts.sh | sort | sed -n 'n;p'`; do echo $vmName; ssh $vmName "service qns status"; echo; done

Step 3

Start Policy Server (qns) process:

for vmName in `hosts.sh | sort | sed -n 'n;p'`; do echo $vmName; ssh $vmName "service qns start"; ssh $vmName "service monit start"; echo; done

Step 4

Verify that the Policy Server (qns) process has started:

for vmName in `hosts.sh | sort | sed -n 'n;p'`; do echo $vmName; ssh $vmName "service qns status"; echo; done

Step 5

Verify the CPS health status using the diagnostics.sh script.

Undo a Patch

The following steps disables the currently applied CPS patch, and reverts the system to the base software version. For example, if a patch 7.5.0.xx is installed on the system, this command reverts the software to the base version 7.5.0.


Note
If you have custom plug-ins installed in your system, refer to CPS Installations using Custom Plug-in before executing the patch -u command.

To undo the applied patch, execute the following command on the Cluster Manager:

/var/qps/install/current/scripts/patch/patch -u

After undoing the applied patch execute the following commands in Cluster Manager to re-build the CPS system and push the changes to VMs:

/var/qps/install/current/scripts/build_all.sh

/var/qps/install/current/scripts/upgrade/reinit.sh

After undoing a patch, qns processes need to be restarted. Refer to Rolling Restart of CPS VMs QNS Process (Odd Sides) and Rolling Restart of CPS VMs QNS Process (Even Sides) for further steps.

Remove a Patch

Execute the following command on the Cluster Manager to completely remove a patch and all related items from the Cluster Manager. This deletes the patch file from the /var/qps/.tmp/patches directory of the Cluster Manager:

/var/qps/install/current/scripts/patch/patch -r patch_name

where, patch_name is the name of patch you want to remove.

Example,

/var/qps/install/current/scripts/patch/patch -r Patch_1_11.9.9


Note
Currently, CPS supports only one patch at a time. You must remove any existing patches before applying a new patch.

After removing a patch, qns processes need to be restarted. Refer to Rolling Restart of CPS VMs QNS Process (Odd Sides) and Rolling Restart of CPS VMs QNS Process (Even Sides) for further steps.

List Applied Patches

Execute the following command on Cluster Manager to list the applied patches installed in the system:

/var/qps/install/current/scripts/patch/patch -l

The about.sh command also displays if any patch is applied on the current CPS system or not.

CPS Installations using Custom Plug-in

CPS provides several methods to patch baseline release functionality. One method utilizes the “repositories” configuration file to specify the location of additional software on the CPS Cluster Manger. As such, the current patch utilities aide in removing all repositories. However, CPS Custom plug-in software also uses the “repositories” configuration file to specify the location of custom software. Therefore an additional manual step is required to reconfigure CPS custom plug-in code after patches are removed.

Procedure

Step 1

From the CPS Cluster Manager, undo the patches:

Note 

While the patch utility logs that it is removing the repositories configuration file, it actually renames it, at the same path location, as “repositories.back”.

/var/qps/install/current/scripts/patch/patch -u

The following messages show the progress of the patch -u command: 

undo the patches
copy puppets from /var/qps/patches backup to /var/qps/install/current/puppet
copy scripts from /var/qps/patches backup to /var/qps/install/current/scripts
remove /etc/broadhop/repositories
patch undone successfully, please run build_all.sh and reinit.sh to push the changes to VMs
Step 2

For CPS installations utilizing custom plug-ins, the following step is required before software upgrade.

  1. From the CPS Cluster Manager, restore the “repositories” configuration file, without patch references.

    Copy the repositories backup to the original location:

    cp /etc/broadhop/repositories.back /etc/broadhop/repositories

  2. Remove references to software patch locations, and leave references to custom plugin code:

    In the example below, leave the first line (file:///var/qps/.tmp/plugin1) as it is, and remove the second line (file:///var/qps/.tmp/patch1) before continuing with the software upgrade process.

    file:///var/qps/.tmp/plugin1

    file:///var/qps/.tmp/patch1