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

Re: v2.2.24 structural object class modification not allowed





--On Friday, April 29, 2005 12:28 PM -0500 Curt Blank <curt@uwm.edu> wrote:

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.

top->person->organizationalPerson->inetOrgPerson->uwmPerson->ctCalUser

objectclass ( 2.5.6.6 NAME 'person'
        SUP top STRUCTURAL
objectclass ( 2.5.6.7 NAME 'organizationalPerson'
        SUP person STRUCTURAL
objectclass ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'
        SUP organizationalPerson
objectclass ( 1.3.6.1.4.1.4170.1.1.25 NAME 'uwmPerson'
        SUP inetOrgPerson STRUCTURAL
objectclass ( 1.3.6.1.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?

Well, you have two options, I think:

1) change uwmPerson thusly:


objectclass ( 1.3.6.1.4.1.4170.1.1.25 NAME 'uwmPerson' SUP ( inetOrgPerson $ ctCalUser ) STRUCTURAL

2) make ctCalUser AUXILIARY, so it can be present, but not strucural, and get rid of the SUP uwmPerson bit in its definition:

objectclass ( 1.3.6.1.4.1.2672.3.3 NAME 'ctCalUser'
        AUXILIARY

Hard to say for sure without knowing exactly how your calendar stuff works/directory data is laid out.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html