R80.20 to R80.40 upgrade with CDT 1.8

[3315cd11-6366-4]

Has anyone managed to do an upgrade using CDT Advanced mode to upgrade a HA cluster from R80.20 to R80.40?       I'd like to do this followed by patching both gateways.

I've started configuring the deployment plan but I'm a little concerned about the lack of an 'upgrade' option for the upgrade - when doing it manually, after verifying the package I'd choose 'upgrade' in the webui or 'installer upgrade xxxx' in clish  as the 'install package' option would then do a fresh install - not helpful!      I'm a bit worried about CDT doing the same thing... so I'd expect to see a 'upgrade_package' option.

Secondly is the 'connectivity_upgrade=true' needed for this ?    As the upgrade manually needs the cluster version updated and the policy reinstalled after each gateway is upgraded, is this function handled by 'connectivity_upgrade=true' ?    The Deployment Plan section of the manual mentions that the install_package 'runs the Prepare New Policy stage before the package installation to make sure there is an updated policy for the Security Gateway to fetch.'      but there is no more information on this.

Lastly the CDT instructions don't seem to be clear about the 'update_cpuse=true' switch.       How does this update cpuse when there is no path defined to a new CPUSE version?   Does it just read the version installed on the MDS somehow?       Our environment cannot access Checkpoint online servers for updates.

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

<!--
This is an example of a Check Point Central Deployment Tool Deployment Plan file.
Refer to the CDT SK for additional information about configuring and using CDT:
https://supportcenter.us.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&so...
-->

<CDT_Deployment_Plan>
<!--
The plan_settings element contains the name and the description of the deployment plan
and additional configuration.
-->
<plan_settings>
<name value="Upgrade clusters to R80.40" />
<description value="Upgrade firewall clusters to R80.40 and patch with CDT" />
<update_cpuse value="true" />
<connectivityupgrade value="false" />
</plan_settings>

<!-- Execute script -->
<execute_script path="/home/admin/cdt/preScript.sh" iscritical="false" />

<!-- Remove custom jumbo -->
<uninstall_cpuse_package filename="R75.46_JUMBO_HF.tgz" />

<!-- Major R80.40 upgrade -->
<import_package path="/home/admin/Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz" />
<verify_package path="/home/admin/Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz" />
<install_package path="/home/admin/Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz" />

<!-- Notifications during execution -->
<log level="NORMAL" value="Finished installing major upgrade." />
<send_email to="cdt.admin@checkpoint.com" subject="Major upgrade completed" body="Finished installation of R80.40 major upgrade, preparing to install R80.40 JHF T77" />

<!-- Install JHF for R80.40 -->
<import_package path="/home/admin/Check_Point_R80_40_JUMBO_HF_Bundle_T77_sk165456_FULL.tgz" />
<install_package path="/home/admin/Check_Point_R80_40_JUMBO_HF_Bundle_T77_sk165456_FULL.tgz" />

<!-- Get a file from the gateway to /home/admin/ -->
<pull_file remote_path="/home/admin/file_to_pull.txt" local_dir="/home/admin/" />

</CDT_Deployment_Plan>

Any insights from anyone who has used this more?

thanks

Chris

[Boaz_Orshav]

Hi Chris

  1. Indeed there is a mis-consistency regarding the action name. We shall think how to make it clear that "install" in CDT terms means "Upgrade"

  Now you can be sure this is the situation due to the fact that CDT supports only upgrade )and not clean install) so don't worry about it.
2. What is written in the admin is correct - the CDT prepares the policy on the management before the installation starts and when the GW finishes the upgrade it fetches the policy.

I would recommend that after everything is done you run the install policy from the management.

3. Regarding the CPUSE - it takes the one form the image you are installing. However, you can specify a path where to take it from. We will update the documentation.

Thanks very much for the comments! It helps us improve the documentation and make the tool easier to use.

Boaz

[3315cd11-6366-4]

Thanks Boaz thats useful to know.      Something else I discovered - it seems to require sole access to the CMA even though its multi-user.     My first attempt just sat there until I disconnected a couple of sessions before it carried on, this would be inconvenient during normal working,    but presumably its to ensure no other admin has the cluster locked for editing?

My first attempt failed - not sure why as can't see anything useful in the logs.         It upgraded CPUSE without issue on the standby fw, upgraded to R80.40 and rebooted, upgraded the cluster version and even sorted the policy out but then fell over.          All I had to do manually was to run cpstart on the gateway and then fail over.      I tried retrying/resuming  the install which failed so had to finish the cluster manually.

I'll have another go on a different cluster.

Chris

[funkylicious]

Hi, connectivityupgrade argument will execute/or not the cphacu start command before doing the failover, where the standby/backup member will sync the connections that the active/master member before the failover was handleling.

As for the upgrade, you don't need to worry. CDT doesnt perform clean/fresh installs, except the RMA mode, so it will do an upgrade. Also, you don't really need to verify_package argument.

update_cpuse will update the CPUSE agent version on the gateway with a newer version, that needs to be extracted on the MDS, adding the following line into CentralDeploymentTool.xml

<CPUSE RPMPath="/home/admin/CPda-00-00.i386.rpm"/>

Remember that before you execute CDT in advanced mode to run mdsenv <CMA_IP>

Full commands to run it :

./CentralDeploymentTool -generate -candidates=file.csv -deploymentplan=DepPlan.xml -server=CMA_IP
./CentralDeploymentTool -execute -candidates=file.csv -deploymentplan=DepPlan.xml -server=CMA_IP

If multiple gateways/clusters are present on the CMA and you don't want to perform upgrade on all, then you need to create a text file and add the name of the cluster that you want to do the upgrade in it, then the argument -filter=file.txt , before the -server argument in each of the lines.

If you want, I can provide example of the configuration files that I have been using for 6 months, both for VRRP/ClusterXL and VSX  clusters, from R77.30 to R80.X + JHF installation.

[3315cd11-6366-4]

Thanks for this, I did try it sometime last year for patching but have completely forgotten how to work it!    I'd also forgotten what the connectivity upgrade was about so have that disabled now  presumably don't need it for R80.20 to R80.40

As I replied to Boaz above, first attempt failed -  CDT bombed out after upgrading, didn't seem to want to start the services and fail over but can't see anything useful in the logs to indicate why so I finished it manually this time, but will try again.

chris