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@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. >
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 -- 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