[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 not allowed.

This is what I currently have.


objectclass ( NAME 'person'
objectclass ( NAME 'organizationalPerson'
       SUP person STRUCTURAL
objectclass ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'
       SUP organizationalPerson
objectclass ( NAME 'uwmPerson'
       SUP inetOrgPerson STRUCTURAL
objectclass ( 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?