The winsync plugin does not ignore changes to entries that are outside of the configured subtree. Ex: [25/Feb/2011:15:45:44 -0500] NSMMReplicationPlugin - agmt="cn=meTojgalipea-win-2008r2.ipa.qe" (jgalipea-win-2008r2:389): windows_replay_update: failed to fetch local entry for modify operation dn="dnahostname=vm-049.idm.lab.bos.redhat.com+dnaportnum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" In this case the plugin is configured to deal only with entries in the: cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com But it still throws up errors about entries it should completely ignore.
Created attachment 482147 [details] Patch
Pushed to master. Thanks to Rich and Noriko for their reviews! Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1.38 KiB, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 2af43a8..4f30419 master -> master Pushed to 389-ds-base-1.2.8 branch as well: Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1.39 KiB, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git bbccde3..b6c75e3 128-local -> 389-ds-base-1.2.8
Need steps to reproduce and verify please.
(In reply to comment #3) > Need steps to reproduce and verify please. I believe that this was initially found from one of your tests based off of the log snippet in the original description. IIRC, you just need to set up AD sync and then do a modify operation to an entry outside of the scope of the sync agreement on the DS side. You should not see an error message like initially reported in the errors log.
I think this is when Simo was using my ADS machine.
I could still see some error messages for the subtree which is not in WinSync agreement. [03/Aug/2011:14:11:35 -0400] NSMMReplicationPlugin - agmt="cn=One Way Sync from AD to DS" (win2k8rhvd64:636): windows_replay_add: Cannot replay add operation. [03/Aug/2011:14:11:35 -0400] NSMMReplicationPlugin - agmt="cn=One Way Sync from AD to DS" (win2k8rhvd64:636): Simple bind resumed [03/Aug/2011:14:13:56 -0400] NSMMReplicationPlugin - process_replay_rename: newparent is empty [03/Aug/2011:14:14:32 -0400] NSMMReplicationPlugin - process_replay_rename: newparent is empty I created a winsync agreement with nsDS5ReplicaRoot as "dc=pass_sync,dc=com". And I was trying to create few users and run modrdn operations for few users under "ou=people,dc=pass_sync,dc=com".
(In reply to comment #6) > I could still see some error messages for the subtree which is not in WinSync > agreement. > > > [03/Aug/2011:14:11:35 -0400] NSMMReplicationPlugin - agmt="cn=One Way Sync from > AD to DS" (win2k8rhvd64:636): windows_replay_add: Cannot replay add operation. > [03/Aug/2011:14:11:35 -0400] NSMMReplicationPlugin - agmt="cn=One Way Sync from > AD to DS" (win2k8rhvd64:636): Simple bind resumed > [03/Aug/2011:14:13:56 -0400] NSMMReplicationPlugin - process_replay_rename: > newparent is empty > [03/Aug/2011:14:14:32 -0400] NSMMReplicationPlugin - process_replay_rename: > newparent is empty > > > I created a winsync agreement with nsDS5ReplicaRoot as "dc=pass_sync,dc=com". > And I was trying to create few users and run modrdn operations for few users > under "ou=people,dc=pass_sync,dc=com". I'm not sure that I understand what you're testing. You should be using a bi-directional sync agreement to verify this, not a one-way agreement. You have your agreement configured for the "dc=pass_sync,dc=com" suffix, so "ou=people,dc=pass_sync,dc=com" falls within the scope of the agreement. What you should be testing is to configure a bi-directional sync agreement at the "dc=pass_sync,dc=com" suffix level on the DS side, then modify a user in another suffix on the DS side, such as "dc=example,dc=com". You should not see a message like the following in the errors log when doing this modify to a user outside of the sync agreement scope: [25/Feb/2011:15:45:44 -0500] NSMMReplicationPlugin - agmt="cn=meTojgalipea-win-2008r2.ipa.qe" (jgalipea-win-2008r2:389): windows_replay_update: failed to fetch local entry for modify operation dn="dnahostname=vm-049.idm.lab.bos.redhat.com+dnaportnum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com"
(In reply to comment #7) > (In reply to comment #6) > > I could still see some error messages for the subtree which is not in WinSync > > agreement. > > > > > > [03/Aug/2011:14:11:35 -0400] NSMMReplicationPlugin - agmt="cn=One Way Sync from > > AD to DS" (win2k8rhvd64:636): windows_replay_add: Cannot replay add operation. > > [03/Aug/2011:14:11:35 -0400] NSMMReplicationPlugin - agmt="cn=One Way Sync from > > AD to DS" (win2k8rhvd64:636): Simple bind resumed > > [03/Aug/2011:14:13:56 -0400] NSMMReplicationPlugin - process_replay_rename: > > newparent is empty > > [03/Aug/2011:14:14:32 -0400] NSMMReplicationPlugin - process_replay_rename: > > newparent is empty > > > > > > I created a winsync agreement with nsDS5ReplicaRoot as "dc=pass_sync,dc=com". > > And I was trying to create few users and run modrdn operations for few users > > under "ou=people,dc=pass_sync,dc=com". > > I'm not sure that I understand what you're testing. You should be using a > bi-directional sync agreement to verify this, not a one-way agreement. You > have your agreement configured for the "dc=pass_sync,dc=com" suffix, so > "ou=people,dc=pass_sync,dc=com" falls within the scope of the agreement. The sync agreement says so, but later I deleted the oneWaySync attribute from the agreement. I agree that all subtrees under the suffix are under sync agreement. When I created a subtree in windows as similar to DS, it started working fine. > > What you should be testing is to configure a bi-directional sync agreement at > the "dc=pass_sync,dc=com" suffix level on the DS side, then modify a user in > another suffix on the DS side, such as "dc=example,dc=com". You should not see > a message like the following in the errors log when doing this modify to a user > outside of the sync agreement scope: > > [25/Feb/2011:15:45:44 -0500] NSMMReplicationPlugin - > agmt="cn=meTojgalipea-win-2008r2.ipa.qe" (jgalipea-win-2008r2:389): > windows_replay_update: failed to fetch local entry for modify operation > dn="dnahostname=vm-049.idm.lab.bos.redhat.com+dnaportnum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" I verified the fix by add/modify/delete entries at non-sync agreement suffix. The issue is not reproducible. Hence marking the bug as verified.
So when does this get released?
(In reply to comment #9) > So when does this get released? It was already released in RHEL 6.2/RHDS 9.0