Description of problem: Often we need to re-register a system in order to deploy new packages (added to a package list in an activation key) or subscribe the system to a new channel. This issue is that when re-registering a system a duplicate instance of that system is added to Satellite rather than updating the existing instance. While I understand there may be a script that looks for orphaned systems (ie not checked in for 60 days) and removes them from Satellite, this is not ideal because I don't: - want old systems hanging around until the script removes them - want to manually have to figure out which system (as there are 2 with the same name after re-registering) is the current one by manually cross referencing system id's and deleting the old one There is also an issue with entitlements as well - re-registering a system consumes another entitlement until the old system is removed. This can prevent other systems (depending on how many system entitlements the Satellite has) from registering when being deployed or re-registering. It would be extremely desirable for rhn_register to be able to properly re-register existing systems
Please can you open a support case and work through the formal RFE processes to get this correctly triaged and reviewed. I will point out that within the 5.4 release we made efforts to help reduce duplicates: - systems reinstalled using Satellite provisioning were re-tied to their old profile (not create a new profile) - provided the duplicate systems pages/tabs within Satellite WebUI - API call available in 5.5 Satellite, when released later this year. Manual registration from client though today will continue to create a duplicate profile. Restricting/educating users to not run registration commands may help (unless you are using a non-satellite provisioning system, and thus not benefiting from our built-in code to reduce duplicate instances from happening). Cliff