2:08 a.m.
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.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
8:16 a.m.
On 10/9/07, Guillaume Rousse <Guillaume.Rousse(a)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
2:10 a.m.
FRLinux a écrit :
On 10/9/07, Guillaume Rousse <Guillaume.Rousse(a)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.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
2:16 a.m.
On 10/10/07, Guillaume Rousse <Guillaume.Rousse(a)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
3:53 a.m.
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.
5819
days inactive
5831
days old
openldap-software@openldap.org
4 comments
3 participants
participants (3)
-
FRLinux -
Guillaume Rousse -
Michael Ströder