- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Hello,
We are migrating management and log servers to new hardware with new IP addresses (the hostnames are NOT changing).
1. Is it necessary to run migrate server procedure to export/import the current database on the log server in addition to the management?
2. As we are changing IP addresses (management changing from internal IP which currently NATs outbound, log server changing from public to public), can you confirm it is necessary to create the mdss.json file (see page 199 on guide) on the target management server? The JSON file contains the name of the target server and new IP address.
[{"name":"mgmt-01","newIpAddress4":"new-ip-address"}]
3. I've provisioned a R81.10 VM to test the import of the current R80.40 database.
When exporting, after installing the R81.10 upgrade tools and verifying, from $FWDIR/scripts on the current server I ran ./migrate_server export -v R81.10 /usr/tmp/server_export.tgz
The MD5 hash is calculated successfully.
When importing, from $FWDIR/scripts on the target server, I ran command ‘nohup ./migrate_server import -v R81.10 -skip_upgrade_tools_check /usr/tmp/migrate_server/mgscp02_export_test.tgz &’ and monitored the output in nohup.out.
On this attempt the import exists after 30 minutes with the following message. The import does not complete.
'Minimal post intsall did not finish after 30 minutes. Existing'
Regards,
Simon
I believe answers are yes for 1 and 2 (though Im not 100% sure about 2, maybe someone else can confirm). As far as 3, did you follow migrate_server process as per below?
Thanks @the_rock
Yes I followed the procedure outlined in the link provided.
Can anyone else chime in here regarding these points?
You can only run migrate_server on a management server, not a dedicated log server.
I believe there you just do a normal CPUSE upgrade.
Not familiar with the mdss.json file, so I'll leave that for others to comment on.
Thanks.
Because in the R81.10 installation and upgrade guide documentation, under the Upgrading a Security Management Server or Log Server from R80.20 and higher with Advanced Upgrade section, it states the instructions apply equally to Security Management Server, CloudGuard Controller, Dedicated Log Server and Dedicated SmartEvent Server.
Indeed in step 5.3.d, On the target R81.10 Security Management Server, import the databases Required JSON configuration file, it states in the example given
The required syntax for the JSON configuration file you must use on the
Security Management Server and on the Log Server:
[{"name":"MySecMgmtServer","newIpAddress4":"172.30.40
.51"}]
Important - All servers in this environment must get this same
information.
Regarding the import timeout and mdss.json I'm still checking with Checkpoint Diamond. It seems the import timeout may be related to lack of resources on the test VM. I'm provisioning a higher spec'd VM today and will rerun the import. If successful it may also answer my question re the mdss.json.
So I wanted to get clarification.
Regards,
Simon
Where did you locate this information? I've used migrate_server on both dedicated log servers and dedicated smart event servers multiple times without issues.
There isn't much point in doing it on a dedicated log server unless you plan on doing an export including logs. On a Smart Event server, on the other hand, migrate_server will bring with it custom reports and other things you might have created in Smart Event which might be handy.
Hi Simon,
Did you ever solved the 'Minimal post intsall did not finish after 30 minutes. Existing' issue? What where the initial spec's on your VM and did you need to put more resources in the system? I have the same on my new R81.10 server (VMWare). Spec's are:
- 8 Cores
- 32 GB Memory
- 4 TB Disk
But still import is exiting after 30 minutes. System is not very busy and cores are almost idle during the import, so do not see why it should be resource related.
Regards,
Martijn
Hi @Martijn
In my case the root cause was resource constraint.
The import succeeded after increasing the VM spec's to 8vCPU, 32GB memory, 500GB HDD. I think my export db file was about 9GB compressed, and the import duration was approx. 45 - 60 minutes.
The TAC suggested the VM spec to be minimum 4vCPU and 12GB memory.
You spec's mostly match mine so the cause may be unrelated to resources.
The TAC were able to partially replicate my initial issue in their lab using my initial specs, albeit the same message you and I encountered was not displayed. In their case the import just hung, however the same entries (below) were added to the logs.
Running pg_ctl reload
server signaled
Tue Dec 7 16:29:36 IST 2021: minimal post install / post install failed
cpwd_admin: Failed to submit request to cpWatchDog
cpwd_admin: Failed to submit request to cpWatchDog
Stopping Repository Manager ...
There is no Repository Manager process running.
UEPM: Endpoint Security Management isn't activated
Stop Search Infrastructure...
Stop Log Indexer...
Stop SmartLog Server...
Stop SmartView ...
Stopping RFL ...
RFL stopped
Stopping Solr ...
Regards,
Simon
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY