Bug 741744 - MOD operations with chained delete/add get back error 53 on backend config
MOD operations with chained delete/add get back error 53 on backend config
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.2.9
Unspecified Unspecified
urgent Severity unspecified
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
Depends On:
Blocks: 389_1.3.0 742381
  Show dependency treegraph
 
Reported: 2011-09-27 15:39 EDT by Simo Sorce
Modified: 2015-01-04 18:51 EST (History)
3 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.0-0.1.a1.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 742381 (view as bug list)
Environment:
Last Closed: 2013-03-04 18:08:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
0001-Bug-741744-MOD-operations-with-chained-delete-add-ge.patch (12.34 KB, patch)
2011-09-29 13:45 EDT, Rich Megginson
nkinder: review+
Details | Diff
0001-Bug-741744-part2-MOD-operations-with-chained-delete-.patch (1.90 KB, patch)
2011-09-29 18:37 EDT, Rich Megginson
nhosoi: review+
Details | Diff
0001-Bug-741744-part3-MOD-operations-with-chained-delete-.patch (4.12 KB, patch)
2011-10-07 16:38 EDT, Rich Megginson
nhosoi: review+
Details | Diff

  None (edit)
Description Simo Sorce 2011-09-27 15:39:46 EDT
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.
Comment 1 Rich Megginson 2011-09-27 21:47:47 EDT
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.
Comment 2 Rich Megginson 2011-09-29 13:45:15 EDT
Created attachment 525605 [details]
0001-Bug-741744-MOD-operations-with-chained-delete-add-ge.patch
Comment 3 Nathan Kinder 2011-09-29 14:29:57 EDT
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?
Comment 4 Rich Megginson 2011-09-29 15:28:45 EDT
(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.
Comment 5 Rich Megginson 2011-09-29 16:35:34 EDT
To ssh://git.fedorahosted.org/git/389/ds.git
   0157534..c21515b  master -> master
commit 015b31e7bc8e7072aa78ac33567c7873979cf622
Author: Rich Megginson <rmeggins@redhat.com>
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
Comment 6 Rich Megginson 2011-09-29 18:37:38 EDT
Created attachment 525654 [details]
0001-Bug-741744-part2-MOD-operations-with-chained-delete-.patch
Comment 7 Rich Megginson 2011-09-29 18:48:00 EDT
To ssh://git.fedorahosted.org/git/389/ds.git
   c21515b..ede5dec  master -> master
commit ede5dec6304ef8beeb08bc2c7c9ba92484d29a7d
Author: Rich Megginson <rmeggins@redhat.com>
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
Comment 8 Rich Megginson 2011-10-07 16:38:50 EDT
Created attachment 526957 [details]
0001-Bug-741744-part3-MOD-operations-with-chained-delete-.patch
Comment 9 Rich Megginson 2011-10-07 22:41:29 EDT
To ssh://git.fedorahosted.org/git/389/ds.git
   1d2f5a0..0962a9f  master -> master
commit 0962a9f8f72aec607606c0b206c1dc180f4e4e0a
Author: Rich Megginson <rmeggins@redhat.com>
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
Comment 10 Rob Crittenden 2011-10-13 15:45:40 EDT
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.
Comment 11 Rich Megginson 2011-10-13 16:00:39 EDT
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
Comment 14 Martin Kosek 2012-01-04 08:21:12 EST
Upstream ticket:
https://fedorahosted.org/389/ticket/28
Comment 15 Nathan Kinder 2013-03-04 18:08:52 EST
This was fixed in 389-ds-base-1.3.0-0.1.a1.fc18.  Closing.

Note You need to log in before you can comment on or make changes to this bug.