R81 - SmartUpdate Package Repository

[Anthony_Kahwati]

Afternoon all

I'm trying to update an R81 Manager via Smart Update....

SmartUpdate > Packages > Add > From File

I kept on rejecting the attempt with the below error:

As that was failing I thought I'd use GAIA CPUSE, which worked fine. This lead me to think that I add it this way to the manager then it will become available in the Repository in SmartUpdate, but still no sign of it.

Has anyone used this method to upgrade / update before? My aim is to remotely update the managed gateways direct from the manager.

Many thanks

Anthony

[Timothy_Hall]

The "gateway upgrade" portion of SmartUpdate (including the Package Repository) is not integrated at all with CPUSE and is very old.  I haven't utilized that feature of SmartUpdate in many years, but overall CPUSE works well if you have the latest Deployment Agent and that is what you should use.  It also appears that the license management function of SmartUpdate (which is still quite relevant today) is slowly being integrated into the main SmartConsole in the latest releases and Jumbo HFAs, so it would appear SmartUpdate's days are numbered anyway.

[G_W_Albrecht]

That is very true, Timothy ! Here, i would just stay with the Dashboard instead of using several CPUSE WebGUIs 😎:

[G_W_Albrecht]

But this manual process will download the Jumbo on every GW - if you have many GWs, you can use sk111158: Central Deployment Tool (CDT)

[Boaz_Orshav]

Notice that you can upload packages to a package repository placed on the management machine.

Then the package will be distributed to the GWs from the management repository instead of download it for each GW separately:

[G_W_Albrecht]

Yes, that is true, we have a selectable package location source - i can then do Action > Install HF using the Jumbo from SMS !

[Anthony_Kahwati]

I see this now.... I've never used the central deployment from the Smart Update console so assumed when I had the right version of R80 or 81 then that was it!..... hadn't done my research!

It seems you can only get the JHF's from Checkpoint download centre via this method so the machine has to have Internet access. Unfortunately this particular install is air-gapped and can't reach the Internet. 

[G_W_Albrecht · Accepted solution]

No ! See Security Management R81 Administration Guide p.138: Central Deployment of Hotfixes and Version Upgrades

Adding a package to the Package Repository

1. From the left navigation panel, click Manage & Settings.

2. From the left tree, click Package Repository.

3. Click New and select one of these options:

- Download from cloud - To download the package to the Package Repository from the Check Point Cloud, enter the package name and click Download.

- Upload from local - To upload the package to the Package Repository from your device, browse to the applicable package and click Open.

After the download or upload is complete, the package appears in the Package Repository window in SmartConsole > Manage & Settings view.

[Anthony_Kahwati]

Ah! Thank you.

[Bob_Zimmerman]

Wow. I've seen people put hardware information in hostnames, but that's a whole other level. This box is in a lab, surely?

[G_W_Albrecht]

Of course 😎

[PhoneBoy]

We changed to CPUSE packages back in the R77 timeframe.
SmartUpdate does NOT use this mechanism.
The only thing you can update using this mechanism is legacy SMB appliances running R77.20.x code.

In R81 you should be able to manage licenses and CPUSE packages from SmartConsole itself (not using SmartUpdate).
Contracts or management of licenses offline might be the only reason to use SmartUpdate at this point.

[Timothy_Hall]

Ah I was wondering if the SmartUpdate upgrading capability was even still supported any more, thanks for the clarification.

[JozkoMrkvicka]

Maybe the original name of "SmartUpdate" is little bit confusing now. It WAS used in the past for updates, but nowadays mostly as licensing tool, so maybe correct name should be "SmartLicense". Not sure if this should be considered in the future, as starting from R81 there shouldnt be use case for SmartUpdate...

[PhoneBoy]

Ultimately, the goal is to completely deprecate SmartUpdate.
Right now, the only reasons to still use SmartUpdate in R8x are specific to licensing in specific scenarios per sk149872:

• Open Server activation (not entirely sure this is required)
• License manual updates for totally offline domains (activation, renewal, relicense…)
• Central licensing for Dynamic gateway IPs (if the gateway doesn't have a built-in license)

[M_Ruszkowski]

The packages never show up in our Domains/CMA's.   I have uploaded the packages in the global domain and the pushed this out to our 5 MDS servers with 60+domains.  When I open the SmartConsole for the domain level, the packages are empty.  If you try and upload via local it gives an error stating this must be done via the global repository.   For me this has become a useless tool in R81.10.   Also the command line version of CDT has had a 50% failure rate.  I even upgraded to 9.5 and i can run a generate and no candidates will show up.  Yes the mdsenv is correct and the model is on the hardware list.  I can open a browser to the GW and do it manually fine via CPUSE.   I am a little frustrated because as soon as we upgraded the MDS servers to R81.10 all it broke CDT. 

[mahmods]

Hi Michael, 

i think we can investigate the issues in your environment and solve it so you can use both CDT and Central Deployment from Smart Console. 

can you please collect the following logs and send me via email?

1. collect CDT logs for the generate execution with the empty candidates list.
2. run collect_logs.bash on your MDS machine to collect Central Deployment from Smart Console logs. 

send the collected logs to mahmods@checkpoint.com

i will investigate it and update you ASAP.

Thanks. 

[mahmods]

Hi @M_Ruszkowski , 

Kind reminder.

still waiting for you response. 

Thanks. 

[M_Ruszkowski]

I have opened a case with our Diamond Support Engineer.   

I was mainly posting this in Checkmates to see if anyone else had the same issue.   

[M_Ruszkowski]

CheckPoint has replicated the issue in the their lab.  It appears to be a sync issue with regarding MDS servers in an HA environment.   The packages are not replicated to the other MDS servers.   So at this time we are waiting for R&D to resolve the issue.    

So how in the world does something like CDT GUI not get tested with multiple MDS servers?  Check Point has to assume that the majority of their customers have more than one MDS server.  Especially the larger customers that manage 100's of firewalls where we need something like CDT to help with faster upgrades and patch deployments.   

[M_Ruszkowski]

I had a good talk with Check Point R&D and I would like to say thank you for explaining the situation.  It was documented in the R81.10 Release notes that this feature was not ready for a Multi-MDS environment.  It is on the roadmap.

As for the issue with the candidates file....thank you for the help.  It turns out the CDT uses the CPRID  process to communicate to the gateways.   Recently after we upgraded the MDS servers to R81.10, there were a few domains with "Accept control Connections" enabled.  We turned this off but did not add the CPRID service the GW Management rule.  So a few clusters were dropping the CPRID connection.   This made CDT appear to have intermittent issues.  Some clusters it worked and others it did not.   So this was not a CDT issue.   Thank you Check Point support for the help.

Now everything has been working great.  I have started upgrading all the clusters to R81.10.  we have more that 170+ firewalls and I have been able to upgrade 64 firewalls in 3 weeks with no downtime.  By next week 50% will be done.   If I stay on track I should have them all done in a total of 2 months!   This is mainly due to change windows, and that I have been doing them all myself.  So i am very happy with CDT!

[M_Ruszkowski]

I am wondering if this will allow us to use the CDT that is built into R81.10 in our environment where we have multiple MDS.

To get the GUI to work in a multiple MDS....

1. On primary MDS / Global active - import the packages
2. SSH into the primary MDS - this is where the packages are stored

             MDS01#     /var/log/PackageRepository

      3. replicate this folder - rsync this folder to the other MDS servers

      4. Re-assign globals

This seems to work in the lab.  I know it is not supported....but i am wondering if this is a safe workaround our will we cause issues doing this?