On 05/20/2011 09:20 AM, Jim Tyrrell wrote: > On 20/05/2011 15:47, Rich Megginson wrote: >> 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 > Thanks for the info - I will give that a go. > > I had been thinking about this and wondered if another solution would > be to resurrect the tombstone entry on the master server and then > perform a delete via the master? Is that possible - would removing > the ObjectClass of nsTombstone undelete it and re-add it to the > index? I have searched and found some mentions of doing that in > Active Directory.. not sure - I suppose you could try it > > Ta. > > Jim. -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
