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