[Freeipa-users] re-initialize replica

[Andrew E. Bruno]

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

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