-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
attribute uniqueness plugin fails when set as a chaining component #1109
Comments
Comment from mreynolds (@mreynolds389) at 2014-04-30 00:42:54 The RI plugin is also a possible chaining component, but it is also a betxn plugin - which means it will never be called for a chaining delete operation. So it looks like we need a way for "database" plugins to call backend transaction plugins - I will file a new ticket for this. Then just like the proposed fix in this ticket, RI plugin would need to know how to look at sub-suffixes individually. |
Comment from rmeggins (@richm) at 2014-04-30 00:48:42 Maybe the way to fix this is to allow the chaining database to call BE[TXN][PRE|POST] operation plugins. We did the same thing in the dse.c code - basically, make the dse backend code follow the same semantics as the ldbm backend code when calling plugins. We could do the same in the chaining plugin. If/when we support external LDAP transactions, and we support them through chaining, then the use of these plugins will have the same transactional semantics as the ldbm plugins. |
Comment from mreynolds (@mreynolds389) at 2014-04-30 02:09:36 The attached patch does not change the plugin type in the config(that can be done manually for now), but we still need to change how the the "attribute uniqueness plugin" looks for duplicates: by checking all the backend suffixes that are sub-suffixes of the plugin's configured suffix. So we have a regular backend "dc=example,dc=com" (this is also what is set in the attribute uniqueness plugin), and then we have these two chained backends: ou=people,dc=example,dc=com (backend 2) When we add a user to "ou=people,dc=example,dc=com", we need to search all three backends(not just the configured one). So if we use the default suffix in the uniqueness plugin(dc=example,dc=com), it will not check the chained backends for uniqueness(not even the one we are adding it to). You need to explicitly search on "ou=people,dc=example,dc=com", or "ou=groups,...", in order to check that remote/chained backend. |
Comment from nhosoi (@nhosoi) at 2014-04-30 02:54:18 You have my ack. I'm wondering we should change the plugin type with your fix? Replying to [comment:6 mreynolds389]:
|
Comment from rmeggins (@richm) at 2014-04-30 02:58:29 Replying to [comment:7 nhosoi]:
If you change it from betxn, that will apply to all operations, which means it may break applications that expect the referint work to be done inside the transaction . . . |
Comment from nhosoi (@nhosoi) at 2014-04-30 03:03:58 Replying to [comment:8 richm]:
Ah, I see. Thanks, Rich. |
Comment from rmeggins (@richm) at 2014-04-30 03:08:48 I don't understand. The search code (op_shared_search) should be doing this checking for sub-suffixes and sub-databases. If this is the problem, then we will need to fix every single place in the server code where an internal subtree search can be done. Am I missing something here? |
Comment from mreynolds (@mreynolds389) at 2014-04-30 03:13:35 Replying to [comment:10 richm]:
In my testing, if the search base was "dc=example,dc=com", it would not return entries from the chained backend: "ou=chained,dc=example,dc=com" ldapsearch -xLLL -b "dc=example,dc=com" ou=chainedldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chaineddn: ou=chained,dc=example,dc=com |
Comment from rmeggins (@richm) at 2014-04-30 03:17:53 Replying to [comment:11 mreynolds389]:
Why is that? |
Comment from mreynolds (@mreynolds389) at 2014-04-30 03:20:08 Replying to [comment:12 richm]:
It selects the backend to search based on the base DN supplied. It does it for internal searches as well. |
Comment from mreynolds (@mreynolds389) at 2014-04-30 03:25:39 Replying to [comment:13 mreynolds389]:
Oh this is my fault. I created "ou=people" as a separate backend, not a sub suffix of "dc=example,dc=com". Okay, scratch this patch. |
Comment from mreynolds (@mreynolds389) at 2014-04-30 22:16:09 Closing ticket, tracking issue in ticket 47792 |
Comment from mreynolds (@mreynolds389) at 2017-02-11 23:13:14 Metadata Update from @mreynolds389:
|
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47777
Description of problem:
attribute uniqueness plugin fails when set as a chaining component
Version-Release number of selected component (if applicable):
389-ds-base.x86_64 0:1.3.1.6-24.el7
The attribute uniqueness plugin is set as a chaining component:
But It does not prevent adding an entry having a duplicated attribute across the chained backends. By default, the plugin type of the attribute uniqueness plugin is betxnpreoperation since RHEL-7.0. Once we set it back to preoperation, the functionality works as expected.
ldapadd -x -h localhost -p 13891 -D "cn=test_user,o=my_mux_suffix.com" -w test_passwd
dn: cn=ou0_target_user,ou=my_ou_0,o=my_suffix.com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
cn: ou0_target_user
uid: UID_TOKEN
sn: ou0_target_user sn
adding new entry "cn=ou0_target_user,ou=my_ou_0,o=my_suffix.com"
ldap_add: Constraint violation (19)
additional info: Another entry with the same attribute value already exists (attribute: "uid")
Actual results:
The text was updated successfully, but these errors were encountered: