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 ./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. 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
