[389-users] Delete object on Consumer

[Rich Megginson]

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