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. 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: ldap://Master2.eclipse.net.uk:389/o%3Dacmesystems.com nsslapd-referral: ldap://Master1.eclipse.net.uk:389/o%3Dacmesystems.com 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. -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
