GMU Tool : Basic migrateOut and migrateIn Examples
Article ID: 43972
Updated On:
Products
Issue/Introduction
Symptoms:
GMU Tool - Basic example to demonstrate how the utility works.
Below is a simple example on how to migrate out a folder with a policy from a TEST SERVER to a PRODUCTION Server.
We have two possible cases. First case explains just a simple migrate out - migrate in, in case where policy doesn't exist on Production Server. Second scenario is when we try to update existing policy on production server.
Environment:
Platform: VM appliance CA API Gateway
Version: API Gateway v9.0 With GMU tool 1.2
OS: Red Hat 6 64 bit
Our examples use input argument files for simplification of the command line format. Our examples use 'out.arg' and 'in.arg'
******
GatewayMigrationUtility-1.2.00]# cat out.arg
host=xxxxx.com
username=admin
plaintextPassword=<admin_password>
port=8443
trustHostname
trustCertificate
******
GatewayMigrationUtility-1.2.00]# cat in.args
host=xxxxx.com
username=admin
plaintextPassword=<admin_password>
port=8443
trustHostname
trustCertificate
*****
Resolution/Workaround:
MIGRATE OUT - From source Gateway. This saves the migration package to policy.xml :
./GatewayMigrationUtility.sh migrateOut --argFile out.args --plaintextEncryptionPassphrase <PlainTextPasswordGMU> --folderName gmucase_test --d policy.xml
MIGRATE IN - The destination Gateway should be the same version as the source.
./GatewayMigrationUtility.sh migrateIn --argFile in.arg --plaintextEncryptionPassphrase <PlainTextPasswordGMU> --bundle policy.xml --results result.xml
If the service policy is already in production system, and was updated in Test, a simple migrate out and migrate in will not work because of the 'Mapping Action' in the policy.xml bundle file. You have to change the Mapping Action from 'NewOrExisting' to 'NewOrUpdate'. This can be done manually via editing the file yourself or you can use the 'manageMappings' option.
Example :
./GatewayMigrationUtility.sh manageMappings --argFile out.arg --bundle policy.xml --action NewOrUpdate --type SERVICE
The resulting change...
<l7:Mapping action="NewOrExisting" srcId="0000000000000000ffffffffffffec
76" srcUri="https://xxxxx.com:8443/restman/1.0/folders/000000000000000
0ffffffffffffec76" type="FOLDER">
<l7:Properties>
<l7:Property key="FailOnNew">
<l7:BooleanValue>true</l7:BooleanValue>
</l7:Property>
</l7:Properties>
</l7:Mapping>
<l7:Mapping action="NewOrExisting" srcId="0f0abe295570b6bb6b780c614add57
4a" srcUri="https://xxxxx.com:8443/restman/1.0/folders/0f0abe295570b6b
b6b780c614add574a" type="FOLDER"/>
<l7:Mapping action="NewOrUpdate" srcId="0f0abe295570b6bb6b780c614add578d
" srcUri="https://xxxxx.com:8443/restman/1.0/services/0f0abe295570b6bb
6b780c614add578d" type="SERVICE"/>
</l7:Mappings>
</l7:Bundle>
With the change above, migrateIn should update the EXISTING POLICY
./GatewayMigrationUtility.sh migrateIn --argFile in.arg --plaintextEncryptionPassphrase <PlainTextPasswordGMU> --bundle policy.xml --results result.xml
Environment
Component: APIGTW
Resolution
Our examples use input argument files for simplification of the command line format. Our examples use 'out.arg' and 'in.arg'
******
GatewayMigrationUtility-1.2.00]# cat out.arg
host=xxxxx.com
username=admin
plaintextPassword=<admin_password>
port=8443
trustHostname
trustCertificate
******
GatewayMigrationUtility-1.2.00]# cat in.args
host=xxxxx.com
username=admin
plaintextPassword=<admin_password>
port=8443
trustHostname
trustCertificate
*****
Resolution/Workaround:
MIGRATE OUT - From source Gateway. This saves the migration package to policy.xml :
./GatewayMigrationUtility.sh migrateOut --argFile out.args --plaintextEncryptionPassphrase <PlainTextPasswordGMU> --folderName gmucase_test --d policy.xml
MIGRATE IN - The destination Gateway should be the same version as the source.
./GatewayMigrationUtility.sh migrateIn --argFile in.arg --plaintextEncryptionPassphrase <PlainTextPasswordGMU> --bundle policy.xml --results result.xml
If the service policy is already in production system, and was updated in Test, a simple migrate out and migrate in will not work because of the 'Mapping Action' in the policy.xml bundle file. You have to change the Mapping Action from 'NewOrExisting' to 'NewOrUpdate'. This can be done manually via editing the file yourself or you can use the 'manageMappings' option.
Example :
./GatewayMigrationUtility.sh manageMappings --argFile out.arg --bundle policy.xml --action NewOrUpdate --type SERVICE
The resulting change...
<l7:Mapping action="NewOrExisting" srcId="0000000000000000ffffffffffffec
76" srcUri="https://xxxxx.com:8443/restman/1.0/folders/000000000000000
0ffffffffffffec76" type="FOLDER">
<l7:Properties>
<l7:Property key="FailOnNew">
<l7:BooleanValue>true</l7:BooleanValue>
</l7:Property>
</l7:Properties>
</l7:Mapping>
<l7:Mapping action="NewOrExisting" srcId="0f0abe295570b6bb6b780c614add57
4a" srcUri="https://xxxxx.com:8443/restman/1.0/folders/0f0abe295570b6b
b6b780c614add574a" type="FOLDER"/>
<l7:Mapping action="NewOrUpdate" srcId="0f0abe295570b6bb6b780c614add578d
" srcUri="https://xxxxx.com:8443/restman/1.0/services/0f0abe295570b6bb
6b780c614add578d" type="SERVICE"/>
</l7:Mappings>
</l7:Bundle>
With the change above, migrateIn should update the EXISTING POLICY
./GatewayMigrationUtility.sh migrateIn --argFile in.arg --plaintextEncryptionPassphrase <PlainTextPasswordGMU> --bundle policy.xml --results result.xml
Feedback
