Bug 680558 - Winsync plugin fails to restrain itself to the configured subtree
Summary: Winsync plugin fails to restrain itself to the configured subtree
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - Plugins
Version: 1.2.8
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 639035 389_1.2.8
TreeView+ depends on / blocked
 
Reported: 2011-02-25 21:52 UTC by Simo Sorce
Modified: 2018-11-28 21:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 680579 (view as bug list)
Environment:
Last Closed: 2015-12-07 17:14:39 UTC
Embargoed:


Attachments (Terms of Use)
Patch (4.25 KB, patch)
2011-03-03 20:12 UTC, Nathan Kinder
nkinder: review?
rmeggins: review+
nhosoi: review+
Details | Diff

Description Simo Sorce 2011-02-25 21:52:48 UTC
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.

Comment 1 Nathan Kinder 2011-03-03 20:12:25 UTC
Created attachment 482147 [details]
Patch

Comment 2 Nathan Kinder 2011-03-03 21:11:28 UTC
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

Comment 3 Jenny Severance 2011-06-06 17:42:29 UTC
Need steps to reproduce and verify please.

Comment 4 Nathan Kinder 2011-06-06 18:06:14 UTC
(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.

Comment 5 Jenny Severance 2011-06-06 18:31:24 UTC
I think this is when Simo was using my ADS machine.

Comment 6 Sankar Ramalingam 2011-08-03 12:02:21 UTC
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".

Comment 7 Nathan Kinder 2011-08-03 16:05:26 UTC
(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"

Comment 8 Sankar Ramalingam 2011-08-04 14:44:26 UTC
(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.

Comment 9 James G. Brown III 2012-04-25 20:28:18 UTC
So when does this get released?

Comment 10 Rich Megginson 2012-04-30 16:48:09 UTC
(In reply to comment #9)
> So when does this get released?

It was already released in RHEL 6.2/RHDS 9.0


Note You need to log in before you can comment on or make changes to this bug.