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:
dn: cn=config,cn=chaining database,cn=plugins,cn=config nspossiblechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config nsactivechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config
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.
dn: cn=attribute uniqueness,cn=plugins,cn=config nsslapd-pluginType: betxnpreoperation ==> nsslapd-pluginType: preoperation
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 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.
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.
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) ou=groups,dc=example,dc=com (backend #3)
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.
You have my ack. I'm wondering we should change the plugin type with your fix?
Replying to [comment:6 mreynolds]:
The attached patch does not change the plugin type in the config(that can be done manually for now), I see that in your comment (btw, found a typo "swsitch" ;). But why you don't change it back to preop by default? Currently, you need to swsitch it back to preoperation plugin, but that is not enough...
Replying to [comment:7 nhosoi]:
You have my ack. I'm wondering we should change the plugin type with your fix? Replying to [comment:6 mreynolds]: The attached patch does not change the plugin type in the config(that can be done manually for now), I see that in your comment (btw, found a typo "swsitch" ;). But why you don't change it back to preop by default? Currently, you need to swsitch it back to preoperation plugin, but that is not enough...
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 . . .
Replying to [comment:8 rmeggins]:
Ah, I see. Thanks, Rich.
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?
Replying to [comment:10 rmeggins]:
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"
dn: ou=chained,dc=example,dc=com ou: chained objectClass: top objectClass: organizationalunit
Replying to [comment:11 mreynolds]:
Replying to [comment:10 rmeggins]: 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? 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=chained ldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chained dn: ou=chained,dc=example,dc=com ou: chained objectClass: top objectClass: organizationalunit
Why is that?
Replying to [comment:12 rmeggins]:
Replying to [comment:11 mreynolds]: Replying to [comment:10 rmeggins]: 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? 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=chained ldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chained dn: ou=chained,dc=example,dc=com ou: chained objectClass: top objectClass: organizationalunit Why is that?
It selects the backend to search based on the base DN supplied. It does it for internal searches as well.
Replying to [comment:13 mreynolds]:
Replying to [comment:12 rmeggins]: Replying to [comment:11 mreynolds]: Replying to [comment:10 rmeggins]: 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? 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=chained ldapsearch -xLLL -b "ou=chained,dc=example,dc=com" ou=chained dn: ou=chained,dc=example,dc=com ou: chained objectClass: top objectClass: organizationalunit Why is that? It selects the backend to search based on the base DN supplied. It does it for internal searches as well.
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.
Closing ticket, tracking issue in ticket #47792
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.1.23
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1109
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Duplicate)
Login to comment on this ticket.