On 05/23/2011 06:30 AM, Jim Tyrrell wrote: > 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? No. That is the right entry and the right file. Are you sure the server is not running when you edit the file? If you edit the file while the server is running your edits will be lost. If you're sure the server is stopped, then it must be something done automatically by the replication code. Try this: 1) stop the server 2) find the entry the Multimaster Replication plugin 3) set nsslapd-pluginEnabled: off 4) edit the mapping tree entry above to make it nsslapd-state: backend > Thanks. > > Jim. > > > > > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
