Bug 1044173 - [RFE] make referential integrity configuration more flexible
Summary: [RFE] make referential integrity configuration more flexible
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 1044171
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:41 UTC by Nathan Kinder
Modified: 2015-03-05 09:32 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 09:32:22 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

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


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