On 10/06/2015 10:30 AM, Andrew E. Bruno wrote:
On Tue, Oct 06, 2015 at 10:22:44AM -0400, Rob Crittenden wrote:
Andrew E. Bruno wrote:
On Tue, Oct 06, 2015 at 09:35:08AM -0400, Rob Crittenden wrote:
Andrew E. Bruno wrote:
The replica is not showing up when running ipa-replica-manage list.

   # ipa-replica-manage list
   srv-m14-32.cbls.ccr.buffalo.edu: master
   srv-m14-31-02.cbls.ccr.buffalo.edu: master


However, still seeing the ruvs in ldapsearch:

ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" 
objectClass=nsDS5ReplicationAgreement -LL


nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000
  00050000 55b2aa68000200050000


..

nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000
  0005b0000 55b13e740000005b0000


Should I clean these manually? or can I run: ipa-replica-manage clean-ruv 5

Thanks again for the all the help.

--Andrew


Note that the list of masters comes from entries in IPA, not from
replication agreements.

ipa-replica-manage list-ruv will show the RUV data in a simpler way.

Yeah, I'd use clean-ruv to clean them up.

rob


I get an error trying to clean-ruv:

   # ipa-replica-manage clean-ruv 5
   Replica ID 5 not found

Can these safely be ignored? or will we hit problems when adding the
replica back in?
ipa-replica-manage list-ruv will show you the current RUV list. If it
isn't there then yeah, you're done.

Having unused RUV in a master causes it to do unnecessary replication
calculations.

rob
Yes, list-ruv seems to show the correct RUV list.

# ipa-replica-manage list-ruv
srv-m14-32.cbls.ccr.buffalo.edu:389: 4
srv-m14-31-02.cbls.ccr.buffalo.edu:389: 3

It's just the ldapsearch that's showing repid 5 :

ldapsearch -Y GSSAPI -b "cn=mapping tree,cn=config" 
objectClass=nsDS5ReplicationAgreement -LL
I think this can be ignored sicne its on the repl agreement, and not the backend.

What does this ldapsearch return:

replace -b with your suffix

ldapsearch -Y GSSAPI -b|"dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' nsds50ruv|


Mark

dn: cn=meTosrv-m14-31-02.cbls.ccr.buffalo.edu,cn=replica,cn=dc\3Dcbls\2Cdc\3Dc
  cr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config
cn: meTosrv-m14-31-02.cbls.ccr.buffalo.edu
objectClass: nsds5replicationagreement
objectClass: top
..
nsds50ruv: {replica 5 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afec6b0000
  00050000 55b2aa68000200050000



dn: cn=masterAgreement1-srv-m14-31-02.cbls.ccr.buffalo.edu-pki-tomcat,cn=repli
  ca,cn=o\3Dipaca,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replicationagreement
...
nsds50ruv: {replica 91 ldap://srv-m14-30.cbls.ccr.buffalo.edu:389} 55afecb0000
  0005b0000 55b13e740000005b0000



Last time we had a replicate fail we manually ran a cleanall ruv via ldapmodify
for the ipaca rid which wasn't properly deleted. However, this time we're
seeing the rid in both ipca dn and the replica dn?

Just want to be sure.. are you saying these can be safely ignored? and we can
trust that the list-ruv is correct (and not causing unnecessary replication
calculations). We plan on adding the failed replica back with the same name.

--Andrew


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

Reply via email to