On 10/06/2015 01:13 PM, Andrew E. Bruno wrote:
On Tue, Oct 06, 2015 at 12:53:04PM -0400, Mark Reynolds wrote:

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

Here's the results of the above query:


dn: cn=replica,cn=dc\3Dcbls\2Cdc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tr
  ee,cn=config
nsds50ruv: {replicageneration} 55a95591000000040000
nsds50ruv: {replica 4 ldap://srv-m14-32.cbls.ccr.buffalo.edu:389} 55a955fa0000
  00040000 561400b3000700040000
nsds50ruv: {replica 3 ldap://srv-m14-31-02.cbls.ccr.buffalo.edu:389} 55a955960
  00000030000 5613f7b5000200030000
nsds50ruv: {replica 5} 5600051d001000050000 5600051d001000050000


Still see that replica 5? Is that normal?
It's still present, and if you were having replication issues its possible the changelog recreated that old replica ID (replica 5) after it was cleaned. This changelog resurrection bug has been fixed upstream- fyi.

So, you need to rerun cleanallruv. If the IPA CLI is not detecting the replica id you are trying to delete, then you can run the 389-ds-base cleanallruv.pl script and run it on the server with the old rid:

cleanallruv.pl -D "cn=directory manager" -w password -b "dc=cbls,dc=ccr,dc=buffalo,dc=edu" -r 5

Wait a minute, and rerun that ldapsearch to see if the replica ID was removed/cleaned.

Mark

Thanks!

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