Thank you Rich! On Nov 15, 2012 9:27 AM, "Rich Megginson" <[email protected]> wrote:
> On 11/14/2012 09:18 PM, Derek Belcher wrote: > > Rich, thank you so much for your help, where do I send the beer? > > So here are the new steps that I am testing out and seem to work in my > test environment: > > cd /usr/lib64/dirsrv/slapd-my-ldap/ > ./db2ldif -n userRoot -a /var/tmp/mydb.ldif > chmod 755 /var/tmp/mydb.ldif > > This shouldn't be necessary as long as the file is owned by the server > user. > > ./ldif2db.pl -v -D "cn=directory manager" -w ****** -i > /var/tmp/mydb.ldif -s dc=company,dc=net > reinitialize consumers > reinitialize winsync > > > Does this look right? Better to be paranoid then to do something crazy > in production. > > Yes > > > > On Wed, Nov 14, 2012 at 9:15 PM, Rich Megginson <[email protected]>wrote: > >> On 11/14/2012 05:04 PM, Derek Belcher wrote: >> >> 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 >> >> Yes >> >> service dirsrv stop >> >> Not required >> >> Delete the database out of the GUI in the Configuration / data / >> dc=company,dc=net >> re-create the database dc=company,dc=net (userRoot) >> >> No >> >> ./ldif2db -n userRoot -i /var/tmp/mydb.ldif >> >> You can use ldif2db.pl while the server is running >> >> service dirsrv start >> >> See above >> >> Then right click and reinitialize each sync agreement for the >> multimasters and consumers >> >> Yes >> >> Also reinitialize the winsync agreement >> >> Yes >> >> >> >> 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? >> >> Yes. >> >> >> Thanks -Derek >> >> >> >> On Wed, Nov 14, 2012 at 1:59 PM, Derek Belcher >> <[email protected]>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 <[email protected]>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 <[email protected]>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 >>>>> <[email protected]>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 < >>>>>> [email protected]> 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 >>>>>> [email protected]https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > >
-- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
