[Freeipa-users] ipa replica failure

Wed Jul 1 21:34:24 UTC 2015

On Thu, Jun 25, 2015 at 05:40:23PM -0400, Andrew E. Bruno wrote:
> On Mon, Jun 22, 2015 at 12:49:01PM -0400, Rob Crittenden wrote:
> > >>
> > >>You aren't seeing a replication agreement. You're seeing the Replication
> > >>Update Vector (RUV).
> > >>
> > >>See http://directory.fedoraproject.org/docs/389ds/howto/howto-cleanruv.html
> > >>
> > >>You need to do something like:
> > >>
> > >># ldapmodify -D "cn=directory manager" -W -a
> > >>dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
> > >>objectclass: extensibleObject
> > >>replica-base-dn: o=ipaca
> > >>replica-id: 97
> > >>cn: clean 97
> > >>
> > >
> > >Great, thanks for the clarification.
> > >
> > >Curious what's the difference between running the ldapmodify above and
> > >ipa-replica-manage clean-ruv?
> > >
> > 
> > Nothing, for the IPA data. This is a remanant from a CA replication
> > agreement and it was an oversight not to add similar RUV management options
> > to the ipa-careplica-manage tool.
> > 
> 
> I'm still seeing some inconsistencies. Forgive me if I'm mis-interpreting any
> of this output (still learning the ropes with FreeIPA here)..
> 
> Just trying to wrap my head around the RUVs. Trying to follow the docs here:
> http://directory.fedoraproject.org/docs/389ds/howto/howto-cleanruv.html
> 
> And after running the ldapsearch command to check for "obsolete masters"
> I'm not seeing the replica ID for the old replica we deleted (rep2):
> 
> 
> $  ldapsearch -xLLL -D "cn=directory manager" -W -s sub -b cn=config objectclass=nsds5replica
> Enter LDAP Password: 
> dn: cn=replica,cn=dc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> objectClass: nsds5replica
> objectClass: top
> objectClass: extensibleobject
> nsDS5ReplicaType: 3
> nsDS5ReplicaRoot: dc=ccr,dc=buffalo,dc=edu
> nsds5ReplicaLegacyConsumer: off
> nsDS5ReplicaId: 4
> nsDS5ReplicaBindDN: cn=replication manager,cn=config
> nsDS5ReplicaBindDN: krbprincipalname=ldap/rep2 at CCR.BUFFA
>  LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
> nsDS5ReplicaBindDN: krbprincipalname=ldap/rep3 at CCR.BUFFA
>  LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
> nsState:: BAAAAAAAAABIa4xVAAAAAAAAAAAAAAAAJAAAAAAAAAABAAAAAAAAAA==
> nsDS5ReplicaName: a0957886-df9c11e4-a351aa45-2e06257b
> nsds5ReplicaChangeCount: 1687559
> nsds5replicareapactive: 0
> 
> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
> objectClass: top
> objectClass: nsDS5Replica
> objectClass: extensibleobject
> nsDS5ReplicaRoot: o=ipaca
> nsDS5ReplicaType: 3
> nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-rep2
>  falo.edu-pki-tomcat,ou=csusers,cn=config
> nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-rep3
>  falo.edu-pki-tomcat,ou=csusers,cn=config
> cn: replica
> nsDS5ReplicaId: 96
> nsDS5Flags: 1
> nsState:: YAAAAAAAAAAPa4xVAAAAAAkAAAAAAAAACgAAAAAAAAABAAAAAAAAAA==
> nsDS5ReplicaName: c458be8e-df9c11e4-a351aa45-2e06257b
> nsds5ReplicaChangeCount: 9480
> nsds5replicareapactive: 0
> 
> 
> I see: 
> 
> dn: cn=replica,cn=dc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config)
> nsds5replicaid: 4
> 
> and 
> 
> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
> nsDS5ReplicaId: 96
> 
> 
> In the above output I only see the old replica showing up under:
> 
> nsDS5ReplicaBindDN: krbprincipalname=ldap/rep2 at CCR.BUFFA...
> 
> According to the docs I need the nsds5replicaid for use in the CLEANALLRUV
> task? 
> 
> I also checked the RUV tombstone entry as per the docs:
> 
> # ldapsearch -xLLL -D "cn=directory manager" -W -b dc=ccr,dc=buffalo,dc=edu '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))'
> Enter LDAP Password: 
> dn: cn=replica,cn=dc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config
> cn: replica
> nsDS5Flags: 1
> objectClass: nsds5replica
> objectClass: top
> objectClass: extensibleobject
> nsDS5ReplicaType: 3
> nsDS5ReplicaRoot: dc=ccr,dc=buffalo,dc=edu
> nsds5ReplicaLegacyConsumer: off
> nsDS5ReplicaId: 4
> nsDS5ReplicaBindDN: cn=replication manager,cn=config
> nsDS5ReplicaBindDN: krbprincipalname=ldap/rep2 at CCR.BUFFA
>  LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
> nsDS5ReplicaBindDN: krbprincipalname=ldap/rep3 at CCR.BUFFA
>  LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
> nsState:: BAAAAAAAAADycYxVAAAAAAAAAAAAAAAAJAAAAAAAAAABAAAAAAAAAA==
> nsDS5ReplicaName: a0957886-df9c11e4-a351aa45-2e06257b
> nsds50ruv: {replicageneration} 5527f711000000040000
> nsds50ruv: {replica 4 ldap://rep1:389} 5527f771000000040
>  000 558c7228000200040000
> nsds50ruv: {replica 5 ldap://rep3:389} 5537c773000000050
>  000 5582c7f6000600050000
> nsds5agmtmaxcsn: dc=ccr,dc=buffalo,dc=edu;meTorep3;rep3;389;5;558c572b000a00040000
> nsruvReplicaLastModified: {replica 4 ldap://rep1:389} 55
>  8c7204
> nsruvReplicaLastModified: {replica 5 ldap://rep3:389} 00
>  000000
> nsds5ReplicaChangeCount: 1689129
> nsds5replicareapactive: 0
> 
> And only see nsds50ruv attributes for rep1, and rep3. However, still seeing
> rep2 in the nsDS5ReplicaBindDN.
> 
> If I'm parsing this output correct, it appears RUVs for rep2 is already
> cleaned? If so, how come the nsDS5ReplicaBindDN still exist? 
> 
> Also, why is there a nsds50ruv attribute for rep2 listed when I run this query
> (but not the others above):
> 
> 
> $ ldapsearch -xLLL -D "cn=directory manager" -W -b "cn=mapping tree,cn=config" objectClass=nsDS5ReplicationAgreement
> 
> dn: cn=masterAgreement1-rep3-pki-tomcat,cn=replica,cn=o\
>  3Dipaca,cn=mapping tree,cn=config
> 
> nsds50ruv: {replica 97 ldap://rep2:389} 5527f76000000061
>  0000 556f462b000400610000
> 
> 
> 
> I'm likely missing something here..any help is greatly appreciated.
> 

Just wanted to follow up .. 

I was able to successfully remove the RUV for rep2. I had the wrong base
dn in my ldapsearch.

I verified the nsds50ruv ID by running this command:

$ ldapsearch -xLLL -D "cn=directory manager" -W -b o=ipaca
'(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))'

Then ran the cleanallruv command (thanks Rob):

# ldapmodify -D "cn=directory manager" -W -a
dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: o=ipaca
replica-id: 97
cn: clean 97

That worked and cleaned the RUV. All seems well now. 

Thanks again for all the help.

--Andrew