Check Point Deployment Tool (CDT)

We have been working with one of our clients doing Check Point upgrades – applying jumbo hotfix accumulators (JHA) and also upgrading from R7x to R80.

Check Point Deployment Tool (CDT) is a fantastic tool for making this process quick, easy and painless.

What is it?

Central Deployment Tool (CDT) is a utility that runs on Security Management Servers and Multi-Domain Security Management Servers running Gaia OS.

This utility lets you manage deployment of software packages from your Management Server to multiple managed Security Gateways and cluster members at the same time:

• Installation of software packages
• Perform various actions – take snapshots, run shell scripts, push/pull files, and so on
• Automate the RMA backup and restore process

CDT handles cluster upgrades automatically, including Connectivity Upgrade (CU).

It is fully documented in sk111158, which is also where you can download it from.

Modes of operation

Basic Mode

This is a simple mode, suitable only for a single package installation.

Advanced Mode

This uses a deployment XML file, to define steps – you can uninstall a package then do an upgrade, then install another package all in one plan.

RMA Mode

This automates an RMA backup, then an RMA restore (we haven’t use this yet).

How we used it

We didn’t use the basic mode. Even for a single package install, advanced mode is still not very difficult to use, so you may as well use it!

The Deployment File

The first thing to do is to write a deployment file. These look something like this (this is an example from Check Point):

<?xml version="1.0" encoding="UTF-8"?>
<CDT_Deployment_Plan>

<plan_settings>
<name value="Example deployment plan" />
<description value="Example deployment plan - Run a script, uninstall a hotfix, perform upgrade, install a hotfix, log and send email, pull a file" />
<update_cpuse value="true" />
<connectivityupgrade value="false" />
</plan_settings>

<!-- Path to the script -->
<execute_script path="/home/admin/cdt/preScript.sh" iscritical="false" />
<!-- Use the CDT uninstall actions -->
<uninstall_cpuse_package filename="R75.46_JUMBO_HF.tgz" />
<!-- Use the CDT import and install actions to upgrade -->
<import_package path="/home/admin/R77.30_Install_and_Upgrade.tgz" />
<install_package path="/home/admin/R77.30_Install_and_Upgrade.tgz" />
<!-- Create a log -->
<log level="NORMAL" value="Finished installing major upgrade." />
<!-- Send an email -->
<send_email to="cdt.admin@checkpoint.com" subject="Major upgrade completed" body="Finished installation of R77.30 major upgrade, preparing to install R77.30 HF2." />
<!-- Use the CDT import and install actions -->
<import_package path="/home/admin/R77.30_HF2.tgz" />
<install_package path="/home/admin/R77.30_HF2.tgz" />
<!-- Path to file that needs to be pulled -->
<pull_file remote_path="/home/admin/file_to_pull.txt" local_dir="/home/admin/" />
</CDT_Deployment_Plan>

Wow – that’s a lot. But actually, if you break it down, it’s really not.

It does this:

1. In the plan settings, it defines that it will update CPUSE first.
2. Also in the plan settings, it states it will do a Connectivity Upgrade (CU). This means it will do all your cluster failovers for you!
3. The first step is to run an arbitrary script. Maybe you want to collect some data before you start (routing tables, or whatever). You could put these collection commands into this script.
4. Next, it uninstalls a package. Maybe you have a custom hotfix you received as part of a support case. This would need removing before you attempted to apply further patches.
5. Following that, it imports an upgrade file. What does this mean? It means it will copy the file up there (think: SCP). Then it will import that file (think installer import)
6. After that is installs the package (think installer install)
7. Then it does a log entry, followed by sending an email notification.
8. Now it does an import and an install for a JHA package.
9. Finally, it copies an arbitrary file to the box.

All this in one XML file. A full version upgrade followed by a JHA install, plus some other bits thrown in for good measure.

The Candidate List

Now we have what we want to do defined. But who do we want to do it to?

For this, we use a single CLI command to generate a candidate list. This pulls all gateways out of the manager (or the MDS domain), and puts them in a list. It also checks their eligibility for having the deployment plan ran against them, by checking the first package in the plan. Any gateways that are not eligible get marked with “N/A”. Everything else gets assigned a batch number (typically 1). If you wanted to upgrade in a defined order you could change these batch numbers as needed. If you are doing a CU, you don’t need to separate the cluster members into batches, it is smart enough to manage this. Any gateway which you do not wish to upgrade, you simply need to replace the batch number with a hyphen (-). Do not delete gateways from the candidate list!

The rule is: You can only change the upgrade order column

Run it

That’s it. Once you have the deployment plan and the candidate list, you just type another command and run it. CDT will then run the deployment plan against the candidate list, in the order of the batches you specified. Go get a cup of tea, it might take a while.

Just remember to keep pressing return or something, so that your SSH session doesn’t time out.

Bonus Tips

SSH timing out

To save pressing return every few minutes, you can run the script with nohup to stop the script terminating if the SSH session dies.

Pre-staging the files

If we are in a tight maintenance window upgrading a site half way round the world, it might be a good idea to transfer the packages in advance of our window.

We can stage the files using a deployment plan, just using the “send_package” action in our XML. Here, you should make sure that in this plan, the update_cpuse action is set to no, as updating CPUSE is a change that should probably be done in the maintenance window.

Alternatively, you can manually SCP the files into /var/log/upload on the gateway. When you run CDT to copy and import the files, it first checks if the file already exists in this location on the remote gateway, and if it does you’ll see a message saying is is skipping the sending of files.

Summary

CDT is a fantastic tool for deploying upgrades to gateways. Using it, you can easily deploy multi-stage upgrades and updates to multiple gateways across your estate. It still takes some time, but it is an automated process so it means it just gets on with it.

Do you need your firewalls upgrading but struggling to find the manpower? Why not let Always Networks do it for you. Get in touch!