Bug 974719
Summary: | rhds90 crash on tombstone modrdn | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Marc Sauton <msauton> |
Component: | 389-ds-base | Assignee: | Ludwig <lkrispen> |
Status: | CLOSED ERRATA | QA Contact: | Sankar Ramalingam <sramling> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 6.4 | CC: | jgalipea, jrusnack, lkrispen, lnovich, nhosoi, nkinder |
Target Milestone: | rc | ||
Target Release: | 6.5 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.2.11.15-22.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-11-21 21:09:17 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marc Sauton
2013-06-15 01:36:05 UTC
Reproduced with current master. The behaviour of modrdn for a tombstone entry is very inconsistent. Modrdn has two options: deleteoldrdn and newsuperior and the result is different for different combinations: deleteoldrdn: 1 NO newsuperior: ==> err=53 (unwilling to perform) deleteoldrdn: 1 newsuperior: <dn> ==> err=53 (unwilling to perform) deleteoldrdn: 0 NO newsuperior ==> err=1 (operations error) deleteoldrdn: 0 newsuperior: <dn> ==> CRASH The crash has the side effect, that the entry is no longer accessable after restart, an attempt to repeat the operation gives err=32 (no such object) What's next: 1] Define the expected behaviour, consistent to all combinations. In my opinion tombstone entries are internal and direct modifications should be prevented, so err=53 seems appropriate. 2] Implement 1] 3] Investigate if there is a proper way to resurrect tombstones by a client There is also a problem with modify operations with tombstone entries. It is possible to change an ordinary attribute eg uid. The change will get a csn, is written to the audit log and the index is updated although tombstone entries should have been removed from the ordinary attribute indexes. When the tombstone is purged an invalid index reference remains Upstream ticket: https://fedorahosted.org/389/ticket/47396 Automated in mmrepl/accept Verified all 4 scenarios as per https://bugzilla.redhat.com/show_bug.cgi?id=974719#c5 on 389-ds-base-1.2.11.15-22.el6.x86_64. 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. http://rhn.redhat.com/errata/RHBA-2013-1653.html |