[Date Prev][Date Next]
Re: v2.2.24 structural object class modification not allowed
Ya know, that is a d*mn good question, I really had to stop and think
about that. Best answer I can come up with is stay with what is current
and supported and going to the Berkeley backend does allow us to run
cached and get better performance. So I guess the bottom line to upgrade
was better performance.
Back to the topic at hand, I'm really trying to understand this. I
thought I asked a while ago if theses three new internal attributes, one
being structualObjectclass, meant anything to me and I thought I was
told no their internal. But obviously now this one means something to me
if an application cannot add a user because the value of
structualObjectclass needs to be changed for that to happen and that is
This is what I currently have.
objectclass ( 220.127.116.11 NAME 'person'
SUP top STRUCTURAL
objectclass ( 18.104.22.168 NAME 'organizationalPerson'
SUP person STRUCTURAL
objectclass ( 2.16.840.1.113722.214.171.124 NAME 'inetOrgPerson'
objectclass ( 126.96.36.199.4.1.4188.8.131.52 NAME 'uwmPerson'
SUP inetOrgPerson STRUCTURAL
objectclass ( 184.108.40.206.4.1.2672.3.3 NAME 'ctCalUser'
SUP uwmPerson STRUCTURAL
When a new user gets added to LDAP it appears structualObjectclass get
sets to uwmPerson, then when the Calendar application tries to give that
person a Calendar account slapd wants to change structualObjectclass to
ctCalUser and can't so it sends a failure status to the Calendar server
and the Calendar server fails to add the account.
Now, if structualObjectclass get sets to some value at the time a dn is
added and this restriction exists how can schema ever be extended?
Bottom line, how do I fix this? And allow for future schema additions?
Pierangelo Masarati wrote:
Yeah well that's all fine and dandy but 2.0.27 didn't have this problem
and now because slapd(8) enforces that this problem exists.
Then why don't you keep using 2.0.27?