Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
When renaming a subtree that contains group and user entries such as the users are members of the groups, referential integrity plugin operation fails.
From Noriko's email:
I'm afraid this particular test case may not work with referential integrity with the betxn timing.
This case renames ou=A,dc=suffix to ou=X,ou=Y,ou=Z,dc=suffix. And we have users and groups in ou=A,dc=suffix with having the users as a member in the groups. Please note that users are located prior to the groups.
If we rename ou=A,dc=suffix to ou=X,ou=Y,ou=Z,dc=suffix, its children are renamed and it triggers the referential integrity plug-in (Let's say uid=testuser). In the reverential integrity plug-in, it searches entries which have the DN (uid=testuser,ou=A,dc=suffix) and it tries to replace it with a new DN (uid=testuser,ou=X,ou=Y,ou=Z,dc=suffix). But the found group entry's DN is still an old one (cn=testgroup,ou=A,dc=suffix). And modifying the entry is failing in the test case due to no such entry (LDAP_NO_SUCH_OBJECT).
Version-Release number of selected component (if applicable):
389-ds-base-1.3.1.6-24
How reproducible:
always
Steps to Reproduce:
1. Create a (large) number of entries as groups and members of these groups.
2. Rename the subtree as in description.
Actual results:
Every moved entry results in an error of referential integrity plugin.
Expected results:
The plugin operation does not fail.
Additional info:
These problems may be recurrent in other plugins in more complicated setups. Such as attribute uniqueness in chained environment.
To Mark,
This bug is a regression and found in the subtree rename stress test.
The problem does not occur with the small data set, but it requires 1000s of members which DN is renamed.
Milan Kubik wrote:
> I've got several runs of subtreeRenames stress test, I ran only stress startup and stress_03_02 (the previous test cases do not have an effect on this to they could've been skipped to spare some time). They can be described as these two cases:
I tested the following combinations and all passed the stress_03_02.
. master x TET trunk
. 389-ds-base-1.3.1 x TET trunk
. 389-ds-base-1.3.1 x TET RHEL7
. rhel-7.0 x TET RHEL7
I ran the tests against the local builds on F18, but it should not matter...
Milan, could you rerun the test (rhel-7.0 build with RHEL7 TET) once again?
Thanks!
Milan,
Were you able to restart this test again? Both Noriko and I have not been able to reproduce any issues with this test suite on any current version of the server.
Thanks,
Mark
Hi,
I ran the stress test in beaker and hasn't been able to reproduce this problem.
Another thing I noticed is that the DelSuffix procedure at the end of the test case doesn't fail. When I reported this problem this was not the case, the suffix couldn't be deleted because it was populated with indexes and the procedure didn't expect that (DelSuffixWithIndexes helped back then).
I don't know what changed, but back then I was able to get the behaviour described by this bugzilla quite consistently...