From: Petr Vobornik [mailto:pvobo...@redhat.com]
Sent: Friday, September 18, 2015 1:44 AM
To: Craig White; Martin Kosek; email@example.com; Jan Cholasta
Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA 3.0.0)
On 09/17/2015 06:19 PM, Craig White wrote:
> -----Original Message-----
> From: Petr Vobornik [mailto:pvobo...@redhat.com]
> Sent: Thursday, September 17, 2015 4:59 AM
> To: Martin Kosek; Craig White; firstname.lastname@example.org; Jan Cholasta
> Subject: Re: [Freeipa-users] last step in retiring old RHEL 6 (IPA
> 3.0.0) servers
>>> 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
>> 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
where <SERVICENAME> is usually DNS, HTTP and ldap
The webui also shows a dogtag/ipa1.stt.local@STT.LOCAL but no other dogtag
URL's (like the new master). Is it no longer needed or should it be changed to
the new CA-master?
> removes s4u2proxy configuration
> removes some ACIs
> More info:
>> 2) File a ticket to avoid get_ruv function exit the whole "del"
>> command when --force is in play to fix this long-term
> 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
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
> 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
> 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
DNA ranges could be also configured using ipa-replica-manage.
Yes, the other servers are there and seem to handle the right stuff
> 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
There should be two which contain the deleted replica hostname. One has name
"Read IPA Masters" the other "Modify IPA Masters".
Not sure I understand.
There are entries for the 3 servers in question
Ipa1, ipa3, ipa4 but in cn=masters,cn=ipa,cn=etc,$SUFFIX there isn't anything
(i.e. attributes) that are called IPA Masters or Modify IPA Masters under any
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project