[Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers

Martin Kosek mkosek at redhat.com
Thu Sep 17 11:15:39 UTC 2015


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

>




More information about the Freeipa-users mailing list