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

[Craig White]

-----Original Message-----
From: Petr Vobornik [mailto:pvoborni at redhat.com] 
Sent: Thursday, September 17, 2015 4:59 AM
To: Martin Kosek; Craig White; freeipa-users at redhat.com; 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