[Freeipa-users] re-initialize replica

[Mark Reynolds]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20151006/bc24f935/attachment.htm>