CDT RMA function

[funkylicious]

Hello everyone,

Has anyone tried to do an RMA with CDT ?

I am currently doing some tests and managed to install both JHF and upgrade from R77.30 to R80.10 in basic mode and advanced mode is still to be tested, but I can't figure out how RMA mode works.

I can succesfully generate the candidates list and backup all my gateways from the CMA, I have the backups in /home/admin/backups/<CMA>/ , but when I want to restore a particular GW, although the message displayed on the output is the one below and the new gateway is still unchanged, from the hostname, interfaces, first time wizard is still required...

*A* [Main]: Rma restore Finished.
N* [Main]: Total execution time: 0 hours 4 minutes 15 seconds

Before doing the RMA, i shutdown the interface of the working GW which I wanted to replace and set the same IP on the new GW and enabled the interface.

In the CentralDeploymentPlan.xml file, located in /opt/CPcdt , I've only added this line to the original one

<CPUSE RPMPath="/sysimg/CPwrapper/linux/CPda/CPda-00-00.i386.rpm" /> .

Since the GW that I want to RMA is with R80.10 no particulat JHF installed on it, the new one is with R77.30 . I've tried with one that has the same version R80.10, but no result.

In the /home/admin/ repository the file Check_Point_R80.10_T479_Fresh_Install_and_Upgrade_from_R7X.tgz is found.

The output of the : ./CentralDeploymentTool -rma -info -gateway=R77-2A -server=172.16.100.10

---------------- Backup information (v1.1) ----------------

************* IP Address *************
172.16.100.21
************* Product Type *************
gateway
************* Cluster Type *************

************* Gaia Base Version *************
R80.10
************* Take Number *************
479
************* Branch Name *************
hugo1
************* FCD File Name *************
Check_Point_R80.10_T479_Fresh_Install_and_Upgrade_from_R7X.tgz
************* Image Key *************
{
"gaia_base_version" : "R80.10",
"gaia_take_number" : "479",
"image_products" : null
}

************* DA Version *************
1865
************* Rma Backup Version *************
1.1
************* Hotfixes *************
************* Configurations *************
FTW_settings.conf
Machine_settings.conf
SIC_settings.conf
exported_sic_cert.p12
various.tar
Additional_settings.sh
************* Custom Files *************

Thanks,

Paul

[_Val_]

From CDT manual:

Warning - Do not edit the RMA configuration file RmaTool.xml installed by the CDT package.

[funkylicious]

Hi,

RmaTool.xml was not modified.

Since I am using in my lab virtual appliances, I have also added the <Debug RemoteDefaultPassword="" /> param in the CentralDeploymentTool.xml , how it was used in the Demo Point tutorial, because when you install the VM the admin password cannot be shorter than 6 characters.

Also, tried to reset it to the default using the /sbin/grub-md5-crypt and copy the hash for the admin password, but no luck.

[_Val_]

Since the installation file was transferred, I suspect the CPUSE install fails. It might be that your R77.30 is on lower DA version that requires.

I would look into the actual commands and output files, as described on CDT manual. Looc into RMA / Verification here: https://sc1.checkpoint.com/documents/CDT/v1.7.1/Content/Topics/RMA-Mode.htm?TocPath=Operation%20Mode... 

[_Val_]

Also, just a note, CDR RMA Mode is for actual physical appliances, and not the virtual ones.

[funkylicious]

Oh, really ? Didn't read about this restriction in the document/presentation.

Also, in the mentioned tutorial that I've watched where these functions were described/presented, virtual appliances were used, if I'm not mistaken.

https://www.youtube.com/watch?v=SxP2HbevTsY

[_Val_]

By definition of the terms, RMA is replacing a physical box. Never mind, let's concentrate on your troubleshooting. Any luck with the mentioned files?

[_Val_]

Most importantly, this one: /var/log/CPcdt/logs_<YYYY-MM-DD-HH-mm-ss>/RmaLogs/<Name of Security Gateway or Cluster Member Object>_FinalClishLog.elg

[funkylicious]

In the /var/log/CPcdt/logs_YYYY-MM-DD-HH-mm-ss/ directory, I only have the following 3 files : Main_log.elg , RMA_log.elg and RMA_rma_restore_plan.xml which I also attached, but not the directory mentioned.

L.E. The SG for which I am trying to do a RMA is different from the one in the first post, this being a standalone, whereas the first was part of a cluster .

[_Val_]

In your logs:

Main.elg

Candidate execution results:
RMA, IP 172.16.100.40: Failed

For additional details see the status and log files.
Status file name: /opt/CPcdt/rma/CDT_status_CMA_A-Site.txt
Log files are found in this directory: /var/log/CPcdt/logs_2020-03-09-12-01-21/

RMA.elg:

Mon Mar 9 12:03:41 2020 *D*: Stages list for the current action:
DA cloud packages prevention
Mon Mar 9 12:03:41 2020 *N*: Executing stage - DA cloud packages prevention
Mon Mar 9 12:03:41 2020 *D*: Preventing CPUSE from searching for new packages in the cloud.
Mon Mar 9 12:03:41 2020 *D*: Executing CPUSE stop request.
Mon Mar 9 12:03:41 2020 *D*: Executing command: cprid_util -server 172.16.100.40 -verbose rexec -rcmd stat "/opt/CPda/bin/DAClient"
Mon Mar 9 12:03:41 2020 *D*: retry count = 0, out = (NULL BUF), rc = 5
Mon Mar 9 12:04:11 2020 *D*: retry count = 1, out = (NULL BUF), rc = 5
Mon Mar 9 12:04:42 2020 *D*: retry count = 2, out = (NULL BUF), rc = 5
Mon Mar 9 12:05:12 2020 *D*: retry count = 3, out = (NULL BUF), rc = 5
Mon Mar 9 12:05:42 2020 *D*: retry count = 4, out = (NULL BUF), rc = 5

As I said, the installation package requires a new DA package. Check you have it ready in /opt/CPda/bin/

[funkylicious]

This is the output from the new SG ( 172.16.100.40 ) , when trying to extract/install DeploymentAgent.tgz / CPda rpm file, the latest from the site.

package CPda-00-00 is already installed .

I've done a remove with rpm -e CPda-00-00 and then reinstalled with the new rpm file that I copied from the MDS , and restarted the DAClient and also re-issued the rma restore command, same output.

Mon Mar  9 15:04:30 2020 *N*: Executing stage - DA cloud packages prevention
Mon Mar  9 15:04:30 2020 *D*: Preventing CPUSE from searching for new packages in the cloud.
Mon Mar  9 15:04:30 2020 *D*: Executing CPUSE stop request.                                                                                                                                                   Mon Mar  9 15:04:30 2020 *D*: Executing command: cprid_util -server 172.16.100.40 -verbose rexec -rcmd stat "/opt/CPda/bin/DAClient"                                                                          Mon Mar  9 15:04:31 2020 *D*: retry count = 0, out = (NULL BUF), rc = 5                                                                                                                                       Mon Mar  9 15:05:01 2020 *D*: retry count = 1, out = (NULL BUF), rc = 5                                                                                                                                       Mon Mar  9 15:05:32 2020 *D*: retry count = 2, out = (NULL BUF), rc = 5                                                                                                                                       Mon Mar  9 15:06:02 2020 *D*: retry count = 3, out = (NULL BUF), rc = 5                                                                                                                                       Mon Mar  9 15:06:32 2020 *D*: retry count = 4, out = (NULL BUF), rc = 5                                                                                                                                

On the RMA SG:

[Expert@gw-76c0ee:0]# /opt/CPda/bin/DAClient enable
Enabling DAService...
cpwd_admin:
Process DASERVICE is alive, process won't be started again

gw-76c0ee> installer agent update
Info: Initiating CPUSE self update...
Deployment Agent: agent is up to date

Any ideas on what else to check ?

L.E. Since this command is depedent on the SIC being established between the DMS and the SG, I guess it's normal not to work, since I did not run the FTW in order to set the SIC Key .

[_Val_]

from management, run 

cprid_util -server 172.16.100.40 -verbose rexec -rcmd stat "/opt/CPda/bin/DAClient"

and see why it is failing. If no clue there, please open TAC case so they could investigate further

[_Val_]

also, run  on the GW directly

stat "/opt/CPda/bin/DAClient"

Should return something like 

  File: `/opt/CPda/bin/DAClient'
  Size: 14401372  Blocks: 28168      IO Block: 4096   regular file
Device: fd01h/64769d Inode: 2068321     Links: 1
Access: (0750/-rwxr-x---)  Uid: (    0/   admin)   Gid: (    1/     bin)
Access: 2020-02-06 11:52:29.000000000 +0100
Modify: 2020-02-06 11:52:29.000000000 +0100
Change: 2020-03-04 12:38:28.000000000 +0100

[funkylicious]

[Expert@gw-76c0ee:0]# stat "/opt/CPda/bin/DAClient"
  File: `/opt/CPda/bin/DAClient'
  Size: 14401372        Blocks: 28168      IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 2854460     Links: 1
Access: (0750/-rwxr-x---)  Uid: (    0/   admin)   Gid: (    1/     bin)
Access: 2020-03-09 09:12:26.000000000 -0400
Modify: 2020-02-06 05:52:29.000000000 -0500
Change: 2020-03-09 08:59:50.000000000 -0400

[funkylicious]

Thanks for your input on the matter, I will do just that.

[funkylicious]

The issue is well-known and most likely be resolved in the next version of CDT.

[funkylicious · Accepted solution]

CDT v1.8.0 has resolved this problem !