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

Thu Nov 15 15:34:39 UTC 2012

Thank you Rich!
On Nov 15, 2012 9:27 AM, "Rich Megginson" <rmeggins at redhat.com> 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 <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/20121115/a2b20f4a/attachment.html>