-----Original Message----- From: Petr Vobornik [mailto:[email protected]] Sent: Thursday, September 17, 2015 4:59 AM To: Martin Kosek; Craig White; [email protected]; Jan Cholasta Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0) servers
On 09/17/2015 01:15 PM, Martin Kosek wrote: > 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_Linu >> x/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrat >> ing-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 It will fix the replica manage output but replica cleanup does more things than just a removal of master entry. It also: deletes services of the host removes s4u2proxy configuration removes some ACIs More info: https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/replication.py#n1185 > 2) File a ticket to avoid get_ruv function exit the whole "del" > command when --force is in play to fix this long-term https://fedorahosted.org/freeipa/ticket/5307 ---- OK - I think I see the LDAP entries and just wanting confirmation before I do great harm :-) Dn: cn=ipa1.stt.local,cn=masters,cn=ipa,cn=etc,dc=stt,dc=local Dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=stt,dc=local - attribute memberPrincipal ipa1_ETC Dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=stt,dc=local - attribute memberPrincipal ipa1_ETC The one DN and the 2 attributes are what I should delete to get rid of this dead master? Rummaging around, I do see other hanging chads (pardon the election season humor)... DN: dnaHostname ipa1.stt.local + 0,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local (that is apparently 'dnaPortNum 0 and dnaSecurePortNum 636) DN: dnaHostname ipa1.stt.local + 389,cn=posix-ids,cn=dna,cn=etc,dc=stt,dc=local (that is apparently 'dnaPortNum 389 and dnaSecurePortNum 636) And if I were to delete the first one, there wouldn't be any entries pointing to port '0' but that just looks strange to me anyway. If I delete both the above, then all that is left is just the 2 new RHEL 7 IPA/iDM servers on ports 389/636 which seems right to me. If there are actual ACI's to edit, I am afraid I don't have a tool to do that very easily. Thanks Craig -- 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
