Description of problem: We are trying to updated safely a few entries in cn=config,cn=ldbm database,cn=plugins,cn=config in order to change limits. We are using a modify operation with chained delete/add so that we change these defaults only if admins haven't set their own. DS is returning error 53 in this case (Unwilling to Perform). It should just realize the operation is equivalent to a replace and let the operation happen.
Allowing the dynamic setting of idlistscanlimit is going to be tricky. Because of copy/paste from the old idl code, the new idl code still uses this value in the private ai_idl field in the attrinfo structure. So, a couple of options: - add code to update all of these fields in every attrinfo* in the DSE ldbm modify callback - change the idl code to get the idlistscanlimit from the backend *be structure instead, and change the DSE ldbm modify callback to set the value in the backend structure I think the latter option is cleaner - in the new idl code, the only thing we use the attrinfo ai_idl for is the idlistscanlimit, so I would prefer to get rid of that code rather than add to it.
Created attachment 525605 [details] 0001-Bug-741744-MOD-operations-with-chained-delete-add-ge.patch
Comment on attachment 525605 [details] 0001-Bug-741744-MOD-operations-with-chained-delete-add-ge.patch The fix looks good. Is another quirk that an doing a MOD operation with an add of an attribute value will act as a replace if the attribute is currently set to the default value?
(In reply to comment #3) > Comment on attachment 525605 [details] > 0001-Bug-741744-MOD-operations-with-chained-delete-add-ge.patch > > The fix looks good. Is another quirk that an doing a MOD operation with an add > of an attribute value will act as a replace if the attribute is currently set > to the default value? Correct.
To ssh://git.fedorahosted.org/git/389/ds.git 0157534..c21515b master -> master commit 015b31e7bc8e7072aa78ac33567c7873979cf622 Author: Rich Megginson <rmeggins> Date: Tue Sep 27 16:36:57 2011 -0600 Reviewed by: nkinder (Thanks!) Branch: master Fix Description: Allow ldbm config mods to use MOD_ADD and MOD_DELETE. The purpose of this fix is to allow the specific sequence of changetype: modify delete: attrname - add: attrname attrname: somevalue Unfortunately, the way the DSE code works presents us with some quirks in the behavior: - There is an internal flag which keeps track of whether the value is the default value or not - Deleting an attribute resets the value to the default, but it will also delete the attribute from the internal DSE representation, which means if you attempt to delete an attribute which has already been deleted, the server will return No such attribute (16) because the attribute has already been deleted from the internal DSE - however, if you do an ldap search for the value, you will see it in the entry with the default value. - If the attribute gets in a weird state where it can't be deleted and it can't be added, a mod_replace will get it back to normal Platforms tested: RHEL6 x86_64 Flag Day: no Doc impact: no
Created attachment 525654 [details] 0001-Bug-741744-part2-MOD-operations-with-chained-delete-.patch
To ssh://git.fedorahosted.org/git/389/ds.git c21515b..ede5dec master -> master commit ede5dec6304ef8beeb08bc2c7c9ba92484d29a7d Author: Rich Megginson <rmeggins> Date: Thu Sep 29 16:34:39 2011 -0600 Reviewed by: nhosoi (Thanks!) Branch: master Fix Description: If a value was specified with a mod delete, fail the entire modify operation with LDAP_NO_SUCH_ATTRIBUTE if the specified value does not match the current value. Platforms tested: RHEL6 x86_64 Flag Day: no Doc impact: no
Created attachment 526957 [details] 0001-Bug-741744-part3-MOD-operations-with-chained-delete-.patch
To ssh://git.fedorahosted.org/git/389/ds.git 1d2f5a0..0962a9f master -> master commit 0962a9f8f72aec607606c0b206c1dc180f4e4e0a Author: Rich Megginson <rmeggins> Date: Thu Oct 6 17:13:20 2011 -0600 Reviewed by: nhosoi (Thanks!) Branch: master Fix Description: Remove the mods from the mods list that we don't want the dse code to handle. Add back the original values of the mods that we do want the dse code to handle. Tell the dse code to reapply the mods. Platforms tested: RHEL6 x86_64 Flag Day: no Doc impact: no
The Fedora equivalent is still failing for me (389-ds-base-1.2.10-0.4.a4.fc15.i686) The change is: [(0, 'nsslapd-lookthroughlimit', ['100002']), (1, 'nsslapd-lookthroughlimit', ['5000']), (0, 'nsslapd-idlistscanlimit', ['100002']), (1, 'nsslapd-idlistscanlimit', ['4000'])] Object class violation: cannot add a value to single valued attribute nsslapd-lookthroughlimit.
It's doing a mod/add then a mod/del for the attribute - I only tested mod/del followed by mod/add - the error is due to the ldbm_config code processing the add first, seeing that you are attempting to add another value to a single valued attribute, and throwing an error 65. The problem is that the dse code was never really designed to work with anything but mod/replace. mod/del followed by mod/add should work fine. ipa is going to work around this by using mod/replace. We should revisit this issue for DSIPA30
Upstream ticket: https://fedorahosted.org/389/ticket/28
This was fixed in 389-ds-base-1.3.0-0.1.a1.fc18. Closing.