[Freeipa-users] ipa replica failure

[Andrew E. Bruno]

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.

Thanks,

--Andrew