On 09/22/2015 01:03 AM, Craig White wrote:
-----Original Message-----
From: Petr Vobornik [mailto:pvobo...@redhat.com]
Sent: Friday, September 18, 2015 1:44 AM
To: Craig White; Martin Kosek; freeipa-users@redhat.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; freeipa-users@redhat.com; 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 
of them.


It's an 'aci' attribute of the container - visible for Directory Manager.
Petr Vobornik

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to