R80.40 to R81.10 Migration

[Simon_Macpherso]

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

[the_rock]

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?

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Simon_Macpherso]

Thanks @the_rock

Yes I followed the procedure outlined in the link provided. 

Can anyone else chime in here regarding these points? 

[PhoneBoy]

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.

[Simon_Macpherso]

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

[RamGuy239]

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.

[Martijn]

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

[Simon_Macpherso]

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