Automating checkpoint Upgrade process for remote sites using Ansible

[Abhishek_Singh1]

Hi Guys ,

I am creating an Automation script in Ansible to perform the Checkpoint R80.10 to R80.40 upgrade remotely for our 100 + remote sites .

The script is almost ready utilizing the Ansible shell (pre , actual upgrade ) & uri (policy install - post upgrade ) modules expect for this step -

HOSTNAME#clish -c 'installer upgrade Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz'
Existing OS settings and Check Point database are preserved.
The machine will automatically reboot after upgrade.
Do you want to continue? ([y]es / [n]o) 

Since , the checkpoint doesn't support Pexpect or any other similar module for interactive automation , Is there a way to pass the response (yes)to this command  ??

I have tried to send the traditional Linux way --y , but with no luck .

@PhoneBoy  -- Do you have any insight , tricks to get this done 🙂 ? Any clish / expert command to pass 'yes' , or any installer setting to force the default action as "yes" ??

Regards,

Abhishek

[Chris_Atkinson]

I applaud your efforts to automate these tasks. 

Out of interest have you considered using CDT and were there limitations specific to your scenario that  encouraged you to go a different way?

[Abhishek_Singh1]

Hi Chris ,

I missed the details , these 100+ sites are remote locations running Stand-alone ( Mgmt + Gateway) , not managed Centrally .Hence , cann't use CDT 😞 .

Also , we have very poor almost no connectivity to these mobile sites (VSAT connectivity ) , so the plan is to send the upgarde files .tgz and upload these to our Orchestrator (Ansible) . From where the Ansible upgrade script will initiate the entire Pre , Port upgrade on these Standalone firewalls.

[PhoneBoy]

I don't know if this will actually work or not but you can try something like:

echo yes | clish -c 'installer upgrade Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz'

[Abhishek_Singh1]

Already tried it, yet no luck :(.

So far tried and failed attempts -
echo y | clish -c 'installer upgrade 1'
clish -c 'installer upgrade 1' | echo y

yes | clish -c 'installer upgrade 1' --> works in terminal session, but fails with the ansible session cause of python subprocess killing the write pipe sig_ing handler.

Is there a way to make default action as 'he's instead of cancel for this command? Or something from expert I can run for upgrade passing --y.

[PhoneBoy]

Perhaps you need to push a script that calls those commands in that order and execute that script via Ansible instead of trying to execute directly like you're doing?
In any case, I'm not aware of a way to force the installer to proceed without any input.
The "installer" commands aren't yet in the Gaia APIs either, which would be an RFE.

[Abhishek_Singh1]

Thanks for the insight. Creating a shell script and getting it executed via Ansible did the trick...

Now I am at the last stage where the upgrade is done and Initial Policy is pushed on the GW. Since my Ansible server is South the GW it's access to trigger policy install to the firewall is getting blocked cause of this initial policy...

I am thinking of creating an cron job ( on R80.10 before upgrade) that performs policy install every 25 mins ---> thinking post the upgarde it ll trigger and overcome the lockdown imposed by the Initial policy. Am I correct in this approach??
Do the cron jobs sustain Upgrades??
Or is there anyway around this?

[PhoneBoy]

Believe that will work.
Assuming you've configured cron jobs via Gaia WebUI/clish, they should persist across upgrades.

[Abhishek_Singh1]

@PhoneBoy , 

Finally I was able to write the entire role for the firewall upgrade in ansible . 

But I just realized the potential isuue with the CPUSE runs out-of-date so quickly. 

As I have mentioned we have 100+ standalone firewalls , we have shipped the DA-18665, upgrade .tzp files to be installed with the ansible role locally. 

Now it fails complaining of - new deployment agent is available -18889 , pls update to proceed kinda msg. 

But unfortunately as these standalone firewalls don't have internet access most of the time, in place online da update is not possible. 

Is there any workaround to execute the upgarde process with old Deployment Agent (CPUSE) ... Cause again if we decide to ship the new DA file we have a chance that in a week or so it ll again be outdated 😞 . 

Tx, 

Abhishek

[PhoneBoy]

If these gateways don't have Internet access, how do they know Deployment Agent isn't up to date?
Seems like you should be checking for a new Deployment Agent before you run your playbook and use that.

[Abhishek_Singh1]

I mean they have internet access, but with limited bandwidth (few kbps) and availability. Like we cannt trust as and when the internet uplink (VSAT) is functional or not.

Checking for new DA on these standalones is neither an feasible not an garaunteed shot ( cause the way these VSAT links work )

I was looking for any command or flag to force - don't check for latest DA or run upgarde with existing DA or force the upgrade to be in offline mode. Is there any??

[PhoneBoy · Accepted solution]

What I meant by "checking for a new Deployment Agent" is to do the check out-of-band and deploy it either as part of or prior to your playbook.
The only way I can think of to potentially get around these checks would be to set updates.checkpoint.com via the hosts file to 127.0.0.1.
This will cause the update check to fail and may allow the CPUSE upgrade to take place without updating Deployment Agent.

This change could have other side effects, so I recommend thorough testing.

[Dorit_Dor]

The reason we force check for DA version is that we had seen failures in combination of DA and CPUSE pkg and we are trying to shape the process to 100% success ... 

i am therefore not sure its good to void the check for DA. The cases that it will fail may be “side cases” or they can be relevant in your case. If you decide to void the check, i recommend to talk to our deployment team (thru phone boy or thru support). 
i suspect it may be easier to send updated version of DA and deploy it. 

[Abhishek_Singh1]

Thanks for the quick response . Finally the Upgarde script is completed and we have managed to upgrade 80+ Standalone FWs.

Over few FW (5-8%), I have noticed the CP services dont start for almost more than 30-35mins after the upgrade and hence stalling the post upgrade policy install .

We are running , 2 CPU - 6GB RAM --- Deployment type(Standalone) on HyperV VM.

Upgrading from R80.10 to R80.40 - build 038.

To me this looks like standard CPU load issue , so far I am not able to confirm the recommended Specifications for HyperV Standalone FW deployement from official R80.40 release notes.
Can you please point me towards the required specifications wrt to CPU , RAM , Storage to support this .

Tx,
Abhishek.

[Chris_Atkinson]

For mind those would be aligned to minimum specifications, more accurate sizing depends on your underlying hardware / dedicated resources / traffic demand / enabled blades and in turn this will help determine any licensing implications.

[PhoneBoy]

6GB of RAM is bare minimum for management alone.
Standalone bare minimum is 8GB of RAM.
More RAM is highly recommended.

The minimum specifications are listed in the Release Notes: https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_RN/Content/Topics/Hardware-R... Server Hardware Requirements|_____0#Open_Server_Hardware_Requirements
It mentions "Open Server" but they apply to installation in any environment.

[Vadim9]

Hi Abhishek,

You can use the "not interactive" option for this purpose, it's available for most installer commands

Example:
clish -c "installer upgrade Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz not-interactive"

[Abhishek_Singh1]

Thanks Vadim . But with not-interactive option, I don't get to see the live status of the installation progress... I know that can be fetched with the 'show installer package <no.> -- but this needs to be executed multiple times... So dropped the idea of using it.

BTW do you have any tweak/insight on how to avoid initial policy lockdown? Does the crob job survive upgrade ( R80.10 to R80.40) ?

[kylesmith58]

Would you be able to post an example of your update script?

[Douglas_Rich]

instead of cpuse use da_cli