- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Database import
- 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
Database import
Hello, after I have tried to import database ...
[Expert@CP-MGMT-EPRS_BL:0]# ./migrate import /var/log/SMS.tgz
The import operation will eventually stop all Check Point services (cpstop).
Do you want to continue? (y/n) [n]? y
Extracting the database...
Migrate is only supported between machines with the same take
Execution finished with errors. See log file '/opt/CPshrd-R81.20/log/migrate-2024.04.10_16.33.26.log' for further details
What is cause of error?
Which takes are different? Atached log.
Best regards,
Milan Babic
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, Jumbo Hotfix on both systems were different. It is cause of error: "Migrate is only supported between machines with the same take"
But, now I have installed Jumbo Hotfix Take 53 as source server before migrate import operation. Again, I get some error and I don't know cause.
(attached documents). After I finish migrate import and run "api status" command some of processes are stopped
CP-MGMT-EPRS_BL> api status
API Settings:
---------------------
Accessibility: Require local
Automatic Start: Unknown
Processes:
Name State PID More Information
-------------------------------------------------
API Stopped 0
CPM Stopped 0
FWM Stopped 0
APACHE Started 14071
Port Details:
-------------------
JETTY Internal Port: 0
JETTY Documentation Internal Port: 0
APACHE Gaia Port: 443
Profile:
-------------------
Machine profile: 24800-35800 with SME
CPM heap size: 3072m
Apache port retrieved from: dbget http:ssl_port
--------------------------------------------
Overall API Status: The API Server Is Not Running!
--------------------------------------------
API readiness test FAILED. The server is down and unable to receive connections!
Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'
CP-MGMT-EPRS_BL>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The take refers to the level of Jumbo Hotfix installed on both systems.
Why are you using the legacy migration tool?
You should be using migrate_server from R80.20 onward: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityManagement_AdminGuid...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, Jumbo Hotfix on both systems were different. It is cause of error: "Migrate is only supported between machines with the same take"
But, now I have installed Jumbo Hotfix Take 53 as source server before migrate import operation. Again, I get some error and I don't know cause.
(attached documents). After I finish migrate import and run "api status" command some of processes are stopped
CP-MGMT-EPRS_BL> api status
API Settings:
---------------------
Accessibility: Require local
Automatic Start: Unknown
Processes:
Name State PID More Information
-------------------------------------------------
API Stopped 0
CPM Stopped 0
FWM Stopped 0
APACHE Started 14071
Port Details:
-------------------
JETTY Internal Port: 0
JETTY Documentation Internal Port: 0
APACHE Gaia Port: 443
Profile:
-------------------
Machine profile: 24800-35800 with SME
CPM heap size: 3072m
Apache port retrieved from: dbget http:ssl_port
--------------------------------------------
Overall API Status: The API Server Is Not Running!
--------------------------------------------
API readiness test FAILED. The server is down and unable to receive connections!
Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'
CP-MGMT-EPRS_BL>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, so if jumbo takes are the same, just to confirm, did you follow below process?
Best,
Andy
Pozdrav 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I have tried a both methods, legacy and new migration tool but without success.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you attach output of cpinfo -y fw1 on both current and new system?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, after reboot of SMS, I get a following situation
CP-MGMT-EPRS_BL> api status
API Settings:
---------------------
Accessibility: Require local
Automatic Start: Enabled
Processes:
Name State PID More Information
-------------------------------------------------
API Started 13469
CPM Started 13469 Check Point Security Management Server is running and ready
FWM Stopped 0
APACHE Started 12056
Port Details:
-------------------
JETTY Internal Port: 62675
JETTY Documentation Internal Port: 51583
APACHE Gaia Port: 443
Profile:
-------------------
Machine profile: Large env resources profile with SME or Dedicated Log Server
CPM heap size: 1280m
Apache port retrieved from: dbget http:ssl_port
--------------------------------------------
Overall API Status: Started
--------------------------------------------
API readiness test FAILED. The server is down and unable to receive connections!
Notes:
------------
To collect troubleshooting data, please run 'api status -s <comment>'
CP-MGMT-EPRS_BL> cpinfo -y fw1
This is Check Point CPinfo Build 914000239 for GAIA
[FW1]
HOTFIX_NGM_DOCTOR_AUTOUPDATE
HOTFIX_R81_20_JUMBO_HF_MAIN Take: 53
HOTFIX_GOT_MGMT_AUTOUPDATE
HOTFIX_WEBCONSOLE_AUTOUPDATE
HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE
HOTFIX_VCE_R81_20_AUTOUPDATE
HOTFIX_GOT_TPCONF_MGMT_AUTOUPDATE
FW1 build number:
This is Check Point Security Management Server R81.20 - Build 010
This is Check Point's software version R81.20 - Build 024
CP-MGMT-EPRS_BL>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After reboot FWM process is stopped, I think that it is a reasom why I can't to log in via Smart Console application and get error (attached picture)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
100% thats the reason. Please run cpm doctor script from $FWDIR/scripts
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please, can you tell me exact command sinax
[Expert@CP-MGMT-EPRS_BL:0]# cd $FWDIR/scripts
[Expert@CP-MGMT-EPRS_BL:0]#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
./run_cpmdoc.sh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, sorry for later answer.
I have converted *.html to *.pdf document.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
cpmdoctor is showing log indexing crashing:
10399093 Apr 12 14:24 /var/log/dump/usermode/cpsemd.56480.core.gz
10467136 Apr 12 14:26 /var/log/dump/usermode/cpsemd.60501.core.gz
2427927 Apr 15 10:11 /var/log/dump/usermode/log_indexer.26598.core.gz
2427444 Apr 15 10:12 /var/log/dump/usermode/log_indexer.31435.core.gz
Best to engage with the TAC here: https://help.checkpoint.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see what Phoneboy is saying. I also checked the doc and those are the only errors coming up, nothing else.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Babic,
Can you to resolve this case, I've with same problem...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just run ./runcpm_doc.sh script from $FWDIR/scripts and examine the output.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello everyone,
I also face the same issue with r81.20 with a customer. I found out that the customer upgraded to R81.20 last year which means they used the ISO Check_Point_R81.20_T631. Please notice that Check Point changed this one this year (2024) due to the vulnerability with C2S VPN, and now the ISO is Check_Point_R81.20_T634.
I made a mini lab to confirm this and using the ISO with T631 run the import correctly. Maybe this is the issue you are facing.
Best Regards,
Reagles
IMPORTANT NOTE: I replicated my lab environment twice (in different vmware environments) and for some reason I do not know, the second time I had to run the import almost 3 times (one after the other), in the third one the import run correctly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@fpaez wrote:Hello everyone,
I also face the same issue with r81.20 with a customer. I found out that the customer upgraded to R81.20 last year which means they used the ISO Check_Point_R81.20_T631. Please notice that Check Point changed this one this year (2024) due to the vulnerability with C2S VPN, and now the ISO is Check_Point_R81.20_T634.
I made a mini lab to confirm this and using the ISO with T631 run the import correctly. Maybe this is the issue you are facing.
Best Regards,
Reagles
IMPORTANT NOTE: I replicated my lab environment twice (in different vmware environments) and for some reason I do not know, the second time I had to run the import almost 3 times (one after the other), in the third one the import run correctly.
Hello fpaez,
I am sure that I have used ISO Check_Point_R81.20_T631 because I have been doing it two months before a new ISO Check_Point_R81.20_T634 was launched. I don't know the real reason why the problem happened.
Luckily, I have found some older backup, restore configuration and resolve the problem on another way.
Best Regards,
Milan Babic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In case this still helps anybody, 'Take' is the word that is internally used to refer to the Gaia 'Build' version too. So if Jumbo version is confirmed to be OK, the issue is most probably referring to a mismatch on the 'Build' version of the operating systems, just like FPaez mentioned with the ISO images.
Easy way to check if there is a difference, from clish run 'show version all' (or 'show version os build') and confirm that the Build number is also the same between servers. This is how it looks like for me:
> show version all
Product version Check Point Gaia R81.20
OS build 627
OS kernel version 3.10.0-1160.15.2cpx86_64
OS edition 64-bit
Make sure the target server matches this version too, not just the Jumbo!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Or maybe update CPUSE deployment agent to check if OS build numbers match during package verification ? If secondary management is about to be upgraded, it must communicate with primary management. There is some check already in place.
Jozko Mrkvicka