[389-users] Delete object on Consumer

Jim Tyrrell jim at scusting.com
Fri May 20 15:20:37 UTC 2011


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 at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> 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.



More information about the 389-users mailing list