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

[Petr Vobornik]

On 09/17/2015 06:19 PM, Craig White wrote:
> -----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

This part could be done in web ui - check for 
<SERVICENAME>/ipa1.stt.local at STT.LOCAL

where <SERVICENAME> is usually DNS, HTTP and ldap

>       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

yes


If by ipa1_ETC you mean (assuming that your realm is STT.LOCAL):
> Dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=stt,dc=local - attribute memberPrincipal ipa1_ETC

HTTP/ipa1.stt.local at STT.LOCAL

> Dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=stt,dc=local - attribute memberPrincipal ipa1_ETC

ldap/ipa1.stt.local at STT.LOCAL



>
> 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  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.

Check if the DNA range configuration for the deleted master does contain 
dna RemainingValues other than 0. In that case you might want to check 
DNA configuration of other masters to be sure that other master can 
issue posix numbers.

DNA ranges could be also configured using ipa-replica-manage.

>
> If there are actual ACI's to edit, I am afraid I don't have a tool to do that very easily.

Could  be seen e.g., when browsing LDAP structure in Apache Directory 
studio as Directory Manager. It's 'aci' attribute of entry 
cn=masters,cn=ipa,cn=etc,$SUFFIX

There should be two which contain the deleted replica hostname. One has 
name "Read IPA Masters" the other "Modify IPA Masters".


>
> Thanks
>
> Craig
>


-- 
Petr Vobornik