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.
I tried the method to make the consumer effectively a master allowing
updates but it didnt work. There is no entry in dse.ldif for
"cn=somedomain.co.uk,ou=dns,o=acmesystems.com" so I assume I should be
editing the parent of that object ie:
dn: cn="o=acmesystems.com",cn=mapping tree, cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
nsslapd-state: referral on update
cn: "o=acmesystems.com"
nsslapd-backend: acmeldap
numSubordinates: 1
nsslapd-referral:
I shutdown ldap, changed "referral on update" to "Backend" (also tried
removing nsslapd-referral) and then restarted LDAP but the dse.ldif
config seems to revert back to the original each time. The exact file I
am editing is:
/etc/dirsrv/slapd-consumer01/dse.ldif
Is there another file I should be editing?
Thanks.
Jim.