The following ldif fragment: dn: uid=melancon,ou=saclay,ou=futurs,ou=users,dc=futurs,dc=inria,dc=fr changetype: modify replace: userpassword userpassword: XXXXX - replace: gidnumber gidnumber: 5050 - replace: homedirectory homedirectory: /home/gravite/melancon - delete: pwdAccountLockedTime
causes the server to choke with error: ldapmodify: No such attribute (16) additional info: modify/delete: pwdAccountLockedTime: no such attribute
However, when removing other changes, and keeping only pwdAccountLockedTime deletion, everything works OK....
So, it is an expected behaviour than modificating operational attributes at the same time than normal attributes should fail, or is it a bug ?
openldap version is 2.3.27.
On 10/9/07, Guillaume Rousse Guillaume.Rousse@inria.fr wrote:
So, it is an expected behaviour than modificating operational attributes at the same time than normal attributes should fail, or is it a bug ?
Hello,
Don't think this is a bug, as far as I understand this, pwdAccountLockedTime is an operational pwdPolicy attribute which is not a normal attribute. So when dealing with it, you need to set its value whereas you'd first delete an attribute if it were a normal one.
Steph
FRLinux a écrit :
On 10/9/07, Guillaume Rousse Guillaume.Rousse@inria.fr wrote:
So, it is an expected behaviour than modificating operational attributes at the same time than normal attributes should fail, or is it a bug ?
Hello,
Don't think this is a bug, as far as I understand this, pwdAccountLockedTime is an operational pwdPolicy attribute which is not a normal attribute. So when dealing with it, you need to set its value whereas you'd first delete an attribute if it were a normal one.
I'm not sure to understand you there. If you're opposing 'deleting the attribute' vs 'setting the attribute to an empty value', it doesn't change anything here (I tried both). The issue seems to be concurrent modification of other attributes.
On 10/10/07, Guillaume Rousse Guillaume.Rousse@inria.fr wrote:
I'm not sure to understand you there. If you're opposing 'deleting the attribute' vs 'setting the attribute to an empty value', it doesn't change anything here (I tried both). The issue seems to be concurrent modification of other attributes.
I don't know if that is relevant in that discussion but I found that from time to time, order of attributes being deleted mattered a great deal (especially with early versions). Now, this doesn't answer your question for which I have no idea to that point :/ Sorry.
Steph
Guillaume Rousse wrote:
The following ldif fragment: dn: uid=melancon,ou=saclay,ou=futurs,ou=users,dc=futurs,dc=inria,dc=fr changetype: modify replace: userpassword userpassword: XXXXX
replace: gidnumber gidnumber: 5050
replace: homedirectory homedirectory: /home/gravite/melancon
delete: pwdAccountLockedTime
causes the server to choke with error: ldapmodify: No such attribute (16) additional info: modify/delete: pwdAccountLockedTime: no such attribute
However, when removing other changes, and keeping only pwdAccountLockedTime deletion, everything works OK....
You likely 1. enabled slapo-ppolicy, 2. set the userPassword attribute and 3. disabled slapo-ppolicy afterwards.
Since schema declaration of attribute type pwdAccountLockedTime is hard-coded in slapo-ppolicy and slapo-ppolicy also sets this operational attribute you now have an entry which contains an attribute for which no schema information is available anymore.
This also happened to me when having a master with slapo-ppolicy enabledn and having a consumer replica with slapo-ppolicy disabled.
Ciao, Michael.
openldap-software@openldap.org
-
FRLinux -
Guillaume Rousse -
Michael Ströder