#521 modrdn + NSMMReplicationPlugin - Consumer failed to replay change
Closed: wontfix None Opened 8 years ago by safoo.

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
replace: modifiersname
modifiersname: cn=directory manager
replace: modifytimestamp
modifytimestamp: 20121112194019Z

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.

rpm -q 389-ds-base


Rich Megginson
10:16 AM (3 hours ago)

to me
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.


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

This is the first bug report ticket I have ever filled out, please let me know if anything else is needed

Bug description: modrdn on AD is synchronized to DS, but the
other way does not get synchronized.

Fix description:
1) process_replay_rename (windows_protocol_util.c): If newparent
was NULL, the rename operation was skipped. This patch sets
the original parent dn to the newparent.
2) process_replay_rename (windows_protocol_util.c): AD does not
accept deleteoldrdn == 0 (Old RDN must be deleted). If
deleteoldrdn is 0, it is replaced with 1 before sending the
request to AD.
3) is_subject_of_agreement_remote (windows_protocol_util.c):
When checking if the entry was in the subtree defined in the
agreement or not, it returned true only if the entry is a
direct child of the agreement subtree top. This patch returns
true if the entry is the further descendent of the subtree.
4) This patch adds more NULL reference checks.
5) When the given dn is already normalized, sets it to Slapi_DN
as a normlized dn. It saves an unnecessary dn normalization.
6) Logs in windows sync specific code are prefixed with
"NSMMReplicationPlugin - windows sync".

1393 * ldap_rename: Server is unwilling to perform (53)
1394 * additional info: 00000057: LdapErr: DSID-0C090AAB,
1395 * comment: Old RDN must be deleted, data 0, v1db1
1397 slapi_log_error(SLAPI_LOG_FATAL, windows_repl_plugin_name,
Do we really need this to be logged at FATAL level? What about REPL?

git patch file (master) -- lowered the log level to REPL for the modify deleteoldrdn message

Reviewed by Mark and Rich (Thank you!!)

Pushed to master: commit aa55789
bbe198d..aa55789 master -> master

Create ou=OU and ou=SUBOU,ou=OU on both AD and DS (since I could not create ou=SUBOU under cn=Users on AD).
Set up an agreement between the ou=OU on AD and on DS.
1. create an entry on DS: uid=tuser,ou=OU,<suffix>
check the entry is synchronized to AD
2. move uid=tuser,ou=OU,<suffix> to ou=SUBOU,ou=OU,<suffix> with deleteoldrdn: 0 on DS
check the entry is moved on AD, as well
3. move uid=tuser,ou=SUBOU,ou=OU,<suffix> to ou=OU,<suffix> with deleteoldrdn: 1 on DS
check the entry is moved on AD, as well
4. create an entry on AD: uid=auser,ou=OU,<suffix>
check the entry is synchronized to DS
5. move uid=tuser,ou=OU,<suffix> to ou=SUBOU,ou=OU,<suffix> on AD
check the entry is moved on DS, as well

Metadata Update from @nkinder:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.2 - 07/13 (July)

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/521

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

5 months ago

Login to comment on this ticket.