Rich, "Not that I know of. What you will have to do is dump your database to ldif and reload it, then reinitialize all of your replicas and winsync agreements."
Does this mean that I do not have to stop replication? So basically I would follow the following steps: cd /usr/lib64/dirsrv/slapd-my-ldap/ ./db2ldif -n userRoot -a /var/tmp/mydb.ldif service dirsrv stop Delete the database out of the GUI in the Configuration / data / dc=company,dc=net re-create the database dc=company,dc=net (userRoot) ./ldif2db -n userRoot -i /var/tmp/mydb.ldif service dirsrv start Then right click and reinitialize each sync agreement for the multimasters and consumers Also reinitialize the winsync agreement Does this sound right? Not sure if I need to delete the database or not, from what i am reading it looks like ldif2db will clobber the existing entries in the database. Is this correct? Thanks -Derek On Wed, Nov 14, 2012 at 1:59 PM, Derek Belcher <jderekbelc...@gmail.com>wrote: > Thank you for all of your help Rich. I have opened a ticket with > fedorahosted.org/389 > > Ticket # 521 > > --Derek > > > On Wed, Nov 14, 2012 at 10:16 AM, Rich Megginson <rmegg...@redhat.com>wrote: > >> On 11/14/2012 08:56 AM, Derek Belcher wrote: >> >> This master is bi-directionally syncing with my Active Directory server. >> On the AD server, I have created a customer filtered view for the time this >> started, 11/12/2014 between 1pm and 2pm, included all possible windows log >> sources and I am not seeing any errors. I believe this is due to 389ds, >> pulls and pushes updates, and AD is not really aware of 389ds. >> >> >> Correct. >> >> >> >> So I am thinking that the modrdn command is not able to make the >> changes on the AD side? But if 389ds is pushing changes... >> >> >> It should be, but AD is more restrictive of the types of modrdn and entry >> move operations it will allow. >> >> >> >> What is also interesting is that you can in AD "move" a users to a >> different DN and 389ds will replicate that change to all of its >> multi-masters and consumers. Just does not seem to work when you do DN >> changes on the 389ds side and it pushes to AD. >> >> >> It should work - does this happen with any modrdn entry move operation? >> >> >> >> Is there a way to remove this offending entry in the change log? >> >> >> Not that I know of. What you will have to do is dump your database to >> ldif and reload it, then reinitialize all of your replicas and winsync >> agreements. >> >> Please file a ticket at https://fedorahosted.org/389 - this is >> definitely a bug. >> >> >> >> >> On Wed, Nov 14, 2012 at 9:22 AM, Rich Megginson <rmegg...@redhat.com>wrote: >> >>> On 11/14/2012 08:18 AM, Derek Belcher wrote: >>> >>> Good morning Rich, >>> >>> # rpm -q 389-ds-base >>> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 >>> >>> >>> What does it say in the consumer access and errors log for this change >>> replay attempt? >>> >>> Look in the consumer access log for 50a150a4000000020000, see what the >>> timestamp is, then look in the errors log at around that timestamp. >>> >>> >>> >>> Thank you >>> >>> >>> On Wed, Nov 14, 2012 at 8:58 AM, Rich Megginson <rmegg...@redhat.com>wrote: >>> >>>> On 11/13/2012 07:21 PM, Derek Belcher wrote: >>>> >>>> Here is the error message that I am receiving in >>>> /var/log/dirsrv/slap-xxxx/errors : >>>> >>>> [13/Nov/2012:20:13:27 -0600] NSMMReplicationPlugin - >>>> agmt="cn=sync001" (AD1.company.net:636): Consumer failed to replay >>>> change (uniqueid 754ce981-e4d411e1-b828c127-7d7e145e, CSN >>>> 50a150a4000000020000): Server is unwilling to perform. Will retry later. >>>> >>>> Thanks again for your time. >>>> >>>> rpm -q 389-ds-base >>>> >>>> >>>> >>>> On Tue, Nov 13, 2012 at 5:38 PM, Derek Belcher <jderekbelc...@gmail.com >>>> > wrote: >>>> >>>>> Good evening, >>>>> >>>>> I am requesting some help from the community, I have an issue that I >>>>> can not seem to resolve. >>>>> >>>>> Yesterday I committed a change on a users DN and today I noticed >>>>> replication issues in my logs. The logs told me the uniqueid # and CSN # >>>>> >>>>> So I used cl-dump to dump the changelog into a file. Here are the >>>>> results of what I grep'ed out: >>>>> >>>>> >>>>> [root@ds]# grep "50a150a4000000020000" -B2 -A13 /var/tmp/change.dump >>>>> changetype: modrdn >>>>> replgen: 4ff8a4c0000000010000 >>>>> csn: 50a150a4000000020000 >>>>> nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e >>>>> dn: uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net >>>>> newrdn: uid=auser >>>>> deleteoldrdn: false >>>>> newsuperiordn: ou=threatbb,ou=ops,ou=groups,dc=company,dc=net >>>>> change:: >>>>> replace: modifiersname >>>>> modifiersname: cn=directory manager >>>>> - >>>>> replace: modifytimestamp >>>>> modifytimestamp: 20121112194019Z >>>>> - >>>>> >>>>> So now that I know what entry NSMReplicationPlugin is complaining >>>>> about, I don't know what to do in order to fix it and get replication back >>>>> on track. >>>>> >>>>> I really appreciate any help on this matter, Thank you >>>>> >>>> >>>> >>>> >>>> -- >>>> 389 users mailing >>>> list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>>> >>>> >>> >>> >> >> >
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
