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.. Ta. Jim. -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
