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 -
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.
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
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.
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.**
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". }}}
git patch file (master) 0001-Ticket-521-modrdn-NSMMReplicationPlugin-Consumer-fai.patch
{{{ / 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 1396 / 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 0001-Ticket-521-modrdn-NSMMReplicationPlugin-Consumer-fai.2.patch
Reviewed by Mark and Rich (Thank you!!)
Pushed to master: commit aa55789 bbe198d..aa55789 master -> master
Steps: 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 }}}
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1044143
Metadata Update from @nkinder: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.2 - 07/13 (July)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.