RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: 2020-09-13 20:52 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:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 958 0 None None None 2020-09-13 20:52:15 UTC
Red Hat Product Errata RHSA-2015:0416 0 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 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
Note You need to log in before you can comment on or make changes to this bug.