[389-users] 389ds + modrdn + NSMMReplicationPlugin - Consumer failed to replay change

Thu Nov 15 04:18:13 UTC 2012

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 <rmeggins at redhat.com> 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 <jderekbelcher at 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 <rmeggins at 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 <rmeggins at 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 <rmeggins at 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 <
>>>>> jderekbelcher at 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 at 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 at lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20121114/935fbdcf/attachment.html>