I have recently discovered rather unfortunate situation with Multi-Domain Security Management servers. If you have ever renamed any of the global objects in the global policies, you cannot migrate CMAs anymore.
This sounds strange, but it is the fact. With R77.x cma_migrate script will fail on the target machine if at least one of the global objects was ever renamed.
Check Point has a rather vague SK article about it, and the only proposed solution is to request a hotfix. Mind this article is only referring to R77.10 version, although the issue is present on R77.20 and potentially on R77.30.
It seems cma_migrate is running re-upgrade verifications and fails if gdb_rename table is not empty.
I can only guess if it was done intentionally or not, but there is a history of other issues with renaming global objects on MDSM.
For example, with R75.40 it was impossible to rename a global object, unless a particular system variable was changed (SK82380). One more know issue was about upgrading R76 MDS to R77.10
(SK98793).
Considering all above, the only recommendation is: do not rename global objects to avoid any of the described issues.
This sounds strange, but it is the fact. With R77.x cma_migrate script will fail on the target machine if at least one of the global objects was ever renamed.
Check Point has a rather vague SK article about it, and the only proposed solution is to request a hotfix. Mind this article is only referring to R77.10 version, although the issue is present on R77.20 and potentially on R77.30.
It seems cma_migrate is running re-upgrade verifications and fails if gdb_rename table is not empty.
I can only guess if it was done intentionally or not, but there is a history of other issues with renaming global objects on MDSM.
For example, with R75.40 it was impossible to rename a global object, unless a particular system variable was changed (SK82380). One more know issue was about upgrading R76 MDS to R77.10
(SK98793).
Considering all above, the only recommendation is: do not rename global objects to avoid any of the described issues.
The R77.30 has the same problem, but the issue itself is not a showstopper. Information about the renamed global object has to be assigned to ALL customers and in this case gdb_rename table ($MDSDIR/conf/mdsdb/gdb_renamed.C) will be empty.
ReplyDeleteCan you elaborate?
DeleteSome amount of CMA-s had been successfully migrated and upgraded during a P1 upgrade from an older version to version R77.30 when CMA migrations suddenly failed. Investigation revealed that the failure had been caused by a renamed global object on the destination (R77.30) server. The rename action had been introduced during the long upgrade period by a mistake and the global policy had been reassigned only to relevant CMA-s, where the renamed global object was actually used. Under such situation the gdb_renamed table listed rest of the CMA-s, where the global policy was not yet reassigned and where rename actions was in pending state. As soon as the rename operation was fully completed by reassigning the global policy to all CMA-s, the gdb_renamed table was empty again and it was possible to continue migration + upgrade process. Maybe our situation was too specific, but hopefully someone will find this hint helpful someday.
ReplyDelete