Bug 1044173

Summary:	[RFE] make referential integrity configuration more flexible
Product:	Red Hat Enterprise Linux 7	Reporter:	Nathan Kinder <nkinder>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.0	CC:	lkrispen, nhosoi, vashirov
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 09:32:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1044171

Description Nathan Kinder 2013-12-17 21:41:06 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47621

In ticket 47527 scope for applying referential integrity was introduced, but it is not flexible enough. There should be the possibility to define multiple scopes and to exclude subtrees from scope

Comment 3 Sankar Ramalingam 2014-10-27 15:26:28 UTC

Is the doc link correct?
http://port389.org/wiki/Configuring_scope_for_referential_integrity_plugin

Comment 4 Ludwig 2014-11-17 13:53:26 UTC


The doc lives here now: http://www.port389.org/docs/389ds/design/configuring-scope-for-referential-integrity-plugin.html

Comment 5 Viktor Ashirov 2014-11-24 23:50:32 UTC

Plugin fails to exclude updates on entries when ExcludeEntryScope is a subtree of EntryScope (see below test case [2])

$ rpm -qa | grep 389
389-ds-base-1.3.3.1-9.el7.x86_64
389-ds-base-debuginfo-1.3.3.1-9.el7.x86_64
389-ds-base-libs-1.3.3.1-9.el7.x86_64

On a fresh install of DS I imported test data:
$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:389 -a << EOF
dn: ou=Deleted,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Deleted

dn: cn=user1,ou=People,dc=example,dc=com
objectClass: inetUser
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: user1
sn: user1

dn: cn=user2,ou=People,dc=example,dc=com
objectClass: inetUser
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: user2
sn: user2

dn: cn=group1,ou=People,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: group1
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

dn: cn=group2,ou=People,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: group2
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com
EOF

adding new entry "ou=Deleted,dc=example,dc=com"

adding new entry "cn=user1,ou=People,dc=example,dc=com"

adding new entry "cn=user2,ou=People,dc=example,dc=com"

adding new entry "cn=group1,ou=People,dc=example,dc=com"

adding new entry "cn=group2,ou=People,dc=example,dc=com"






Test cases: 

[1] EntryScope and ExcludeEntryScope are disjoint subtrees:
nsslapd-pluginContainerScope: ou=People,dc=example,dc=com
nsslapd-pluginEntryScope: ou=People,dc=example,dc=com
nsslapd-pluginExcludeEntryScope: ou=Deleted,dc=example,dc=com

1. Move group2 out of EntryScope
dn: cn=group2,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: cn=group2
deleteoldrdn: 0
newsuperior: ou=Deleted,dc=example,dc=com

2. MODRDN user1 to user1_modified
dn: cn=user1,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: cn=user1_modified
deleteoldrdn: 1
newsuperior: ou=People,dc=example,dc=com

2.1 Check members of group1 and group2:
$ ldapsearch -o ldif-wrap=no -LLL -x -H ldap://localhost:389 -D "cn=Directory Manager" -w Secret123 -b dc=example,dc=com "(cn=group*)"  uniqueMember
dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com

dn: cn=group2,ou=Deleted,dc=example,dc=com
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

group1 was updated since it's in the EntryScope subtree -> PASS
group2 wasn't updated since it's in the ExcludeEntryScope subtree -> PASS


3. Move user2 out of EntryScope
dn: cn=user2,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: cn=user2
deleteoldrdn: 0
newsuperior: ou=Deleted,dc=example,dc=com

3.1 Check members of group1 and group2:
$ ldapsearch -o ldif-wrap=no -LLL -x -H ldap://localhost:389 -D "cn=Directory Manager" -w Secret123 -b dc=example,dc=com "(cn=group*)"  uniqueMember
dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com

dn: cn=group2,ou=Deleted,dc=example,dc=com
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

group1 was updated since it's in the EntryScope subtree -> PASS
group2 wasn't updated since it's in the ExcludeEntryScope subtree -> PASS




[2] ExcludeEntryScope is a subtree of EntryScope
nsslapd-pluginContainerScope: dc=example,dc=com
nsslapd-pluginEntryScope: dc=example,dc=com
nsslapd-pluginExcludeEntryScope: ou=Deleted,dc=example,dc=com

1. Move group2 out of EntryScope
2. MODRDN user1 to user1_modified
2.1 Check members of group1 and group2:

dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com

dn: cn=group2,ou=Deleted,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com

group1 was updated since it's in the EntryScope subtree -> PASS
group2 is in ExcludeEntryScope, but it was updated -> FAIL


3. Move user2 out of EntryScope
3.1 Check members of group1 and group2:

dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com

dn: cn=group2,ou=Deleted,dc=example,dc=com
uniqueMember: cn=user1_modified,ou=people,dc=example,dc=com

group1 was updated since it's in the EntryScope subtree -> PASS
group2 is in ExcludeEntryScope, but it was updated -> FAIL



[3] EntryScope is a subtree of ExcludeEntryScope
Note: this is highly improbable use case, more like misconfiguration. But in my opinion server behaves correctly. EcludeEntryScope here takes precedence unlike in test case [2].
nsslapd-pluginContainerScope: ou=People,dc=example,dc=com
nsslapd-pluginEntryScope: ou=People,dc=example,dc=com
nsslapd-pluginExcludeEntryScope: dc=example,dc=com

1. Move group2 out of EntryScope
2. MODRDN user1 to user1_modified
2.1 Check members of group1 and group2:

dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

dn: cn=group2,ou=Deleted,dc=example,dc=com
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

group1 and group2 weren't updated since they are in the ExcludeEntryScope subtree -> PASS


3. Move user2 out of EntryScope
3.1 Check members of group1 and group2:

dn: cn=group1,ou=People,dc=example,dc=com
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

dn: cn=group2,ou=Deleted,dc=example,dc=com
uniqueMember: cn=user1,ou=People,dc=example,dc=com
uniqueMember: cn=user2,ou=People,dc=example,dc=com

group1 and group2 weren't updated since they are in the ExcludeEntryScope subtree -> PASS

Comment 6 Sankar Ramalingam 2014-11-25 10:41:20 UTC

Hi Viktor, 
    The test coverage looks great :). This is really a good stuff to test this feature. However, the scenario #2 looks like no supported as per my understanding. The basic feature seems to be working fine as per other scenarios. So, we can mark this bug as verified and open new bugs if the scenario #2 is confirmed as valid.

Comment 7 Sankar Ramalingam 2014-11-25 14:56:25 UTC

Hi Ludwig, Requesting you to see the comment #5 and comment #6.

Comment 8 Ludwig 2014-11-25 15:01:26 UTC

I think the expectation in teh testcase is incorrect.

The excludeEntryScope applies only the the member entries, the scope for gropus is defined by the containerScope, so far no exclude mechanism exist for that

Comment 9 Viktor Ashirov 2014-11-25 15:17:32 UTC

Marking as VERIFIED.

Comment 11 errata-xmlrpc 2015-03-05 09:32:22 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html