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@CCR.BUFFA LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu nsDS5ReplicaBindDN: krbprincipalname=ldap/rep3@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@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@CCR.BUFFA LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu nsDS5ReplicaBindDN: krbprincipalname=ldap/rep3@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 -- 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