On 05/20/2011 08:43 AM, Rich Megginson wrote: > On 05/20/2011 05:18 AM, Jim Tyrrell wrote: >> Hi, >> >> We have a setup with multiple masters which are replicating down to 389 >> Directory Server consumers via 2 hubs, but have a consistency issue. >> >> It appears a few objects were deleted and re-added to the masters but >> the object was not deleted from the 389 consumers. We now have 1 >> object on the masters and 2 objects on the consumers which causes >> problems for the mail servers. If we delete the object from the master >> we are still left with one object on the slaves. The slaves currently >> have a few duplicate objects like this: >> >> dn: cn=mx::10, cn=somedomain.co.uk, ou=dns, o=acmesystems.com >> cn: mx::10 >> mailtransport: nexthop:[mailserver.ourdomain.com] >> dnspreference: 10 >> dnstype: MX >> >> dn: >> nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk, >> ou=dns,o=acmesystems.com >> cn: mx::10 >> mailtransport: nexthop:[mailserver.ourdomain.com] >> dnspreference: 10 >> dnstype: MX >> >> The object showing nsuniqueid is the valid one that exists on the >> master. Is there a way to remove the 2nd object from the consumer >> without re-initialising? > not sure, but you could try this > > 1) make sure no supplier will attempt to send updates - you can do this > by "suspending" replication - how it works is that you first do a search > on the suppliers for the replication agreement for this server > a) ldapsearch -x -D "cn=directory manager" -W -b cn=config > "objectclass=nsds5replicationagreement" > find the one for your consumer, then note the dn: > b) use ldapmodify to change the replication schedule to be "not now": > ldapmodify -x -D "cn=directory manager" -W<<EOF > dn: the dn of the replication agreement > changetype: modify > replace: nsds5replicaupdateschedule > nsds5replicaupdateschedule: 2358-2359 0 > EOF > > 2) shutdown the server you are attempting to fix > 3) edit dse.ldif - find the mapping tree entry for the suffix > cn=somedomain.co.uk, > ou=dns,o=acmesystems.com - change nsslapd-state: backend > 4) start the server > 5) ldapdelete -x -D "cn=directory manager" -W > "nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk, > > ou=dns,o=acmesystems.com" > > or any other modify operation you might need to do Whoops - almost forgot these steps, before resuming replication 6) stop the server 7) edit the mapping tree entry again - change nsslapd-state: referral on update 8) start the server then resume replication as below > 6) on the suppliers, "resume" replication > ldapmodify -x -D "cn=directory manager" -W<<EOF > dn: the dn of the replication agreement > changetype: modify > replace: nsds5replicaupdateschedule > nsds5replicaupdateschedule: 0000-2359 0123456 > EOF > > see also > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Managing_Replication-Solving_Common_Replication_Conflicts > >> I have seen this before on a single consumer so we re-initialised it, >> but its a much bigger problem to re-initialise all of the consumers. It >> would be ideal if there is a way to manually delete an object direct on >> a consumer? >> >> Thanks. >> >> Jim. >> >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
