On 09/16/2015 06:54 PM, Craig White wrote: > Virtually completed the steps listed here... > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html > > Managed to get IPA2 deleted and removed from 'ipa-replica-manage list' so now > it is down to IPA1. No amount of effort will seem to kill that sucker off. > > ipa-replica-manage del ipa1.stt.local --force > Connection to 'ipa1.stt.local' failed: > Forcing removal of ipa1.stt.local > Skipping calculation to determine if one or more masters would be orphaned. > No RUV records found. > > $ ipa-replica-manage del ipa1.stt.local --force -c > Connection to 'ipa1.stt.local' failed: > Forcing removal of ipa1.stt.local > Skipping calculation to determine if one or more masters would be orphaned. > No RUV records found. > > $ ipa-replica-manage list > ipa1.stt.local: master > ipa3.stt.local: master > ipa4.stt.local: master > > Obviously connection to ipa1 failed because in previous step, I had to shut > it down on ipa1 (ipactl stop) > > What's the trick to get rid of an old, discontinued 'master' ? > > Craig White
Quickly looking at ipa-replica-manage code, the del command will end if there is no RUV. So it seems that in some of your previous RUV was deleted, but server record was not. What does # ipa-replica-manage list-ruv show? Petr or Honza, is the only option here to 1) Use ldapdelete to delete the master record in cn=masters as a hotfix for this issue 2) File a ticket to avoid get_ruv function exit the whole "del" command when --force is in play to fix this long-term > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
