Bug 488548 - Reactivation key from one org is migrated to the another org with system migration.
Reactivation key from one org is migrated to the another org with system migr...
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other (Show other bugs)
All Linux
urgent Severity high
: ---
: ---
Assigned To: Brad Buckingham
Preethi Thomas
Depends On:
Blocks: 456998
  Show dependency treegraph
Reported: 2009-03-04 14:13 EST by Preethi Thomas
Modified: 2009-09-10 15:48 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-10 15:48:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Preethi Thomas 2009-03-04 14:13:12 EST
Description of problem:
Reactivation key from one org is migrated to the another org with system migration.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. create 2 orgs org1 & org2 with trust.
2. register a system to org1.
3. login to org1
4. give the system management and provisioning entitlement
5. navigate to the SDC of the system and Details->Reactivation
6. generate a new key
7. from the command line of the satellite server migrate the system to org2
8. migrate-system-profile --username=USERNAME --password=PASSWORD --systemId=SYSTEMID  --to-org-id=TO_ORG_ID
9. login to org2
10. give the migrated system from step 8 management and provisioning entitlement.
11. navigate to the SDC of the system and Details->Reactivation

Actual results:
 Notice that the reactivation key you generated from org1 is available.
If you try to register that system with the reactivation key now, the system will be registered to org1

Expected results:

Additional info:
Comment 2 Brad Buckingham 2009-03-05 10:21:39 EST
Since this one should be in the API logic, I'll investigate.
Comment 3 Brad Buckingham 2009-03-06 12:08:36 EST
git commit: 1d670116eb2e60dae08bd02d70916260ec4e0534

While working on the solution for this one, I actually found a couple of 
similar issues that needed to be addressed.  As a result, this solution addressed
the following issues:

1. The issue as reported... During a system migration, remove the reactivation key
associated with the system.

2. During a system migration, remove any custom values that have been defined
for the system.  (e.g. Values found under Systems->System->Details->Custom Info)

3. During a system migration, migrate any configuration files associated with the
system to the new org.  This includes config files found in 
System->Configuration->View/Modify->Locally-Managed and Local Sandbox.
Comment 4 Brad Buckingham 2009-03-17 17:17:45 EDT
mass move to ON_QA
Comment 5 Preethi Thomas 2009-04-09 08:02:30 EDT
tested all the 3 scenarios from comment#3
Comment 6 John Sefler 2009-08-06 18:47:58 EDT
re-verified staged sat530 w/ build 7/24
all 3 scenarios from comment#3 worked as indicated.

Comment 7 Brandon Perkins 2009-09-10 15:48:37 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.