- CheckMates
- :
- Products
- :
- Developers
- :
- API / CLI Discussion
- :
- Automating checkpoint Upgrade process for remote s...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Automating checkpoint Upgrade process for remote sites using Ansible
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
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
echo yes | clish -c 'installer upgrade Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Assuming you've configured cron jobs via Gaia WebUI/clish, they should persist across upgrades.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seems like you should be checking for a new Deployment Agent before you run your playbook and use that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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) ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Would you be able to post an example of your update script?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
instead of cpuse use da_cli