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

Re: v2.2.24 structural object class modification not allowed





Quanah Gibson-Mount wrote:



--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

Thanks, but his confuses me a bit, I thought the reference had to be the preceding one (for lack of a better way to say that) where it inherited from? I'm just trying to understand how this works.



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

From what I've found out then this option would allow it to then be added to any objectClass chain, correct? Is this then the best way to define and add new schema in the future?


Right now I have dn's in LDAP that have strucutalObjectclass set to either uwmPerson or ctCalUser, if I make either of the modifications above would it be ok to leave it that way, would it even let me leave it that way, or do I have to do a dump and reload? FYI I'm not against doing a dump and reload (other people may be though, with the outage that is, and this is our Master server), just trying to determine if it's necessary.

And if I do a slapcat the dump obviously will have the structuralObjectClass in it so do I have to strip it out before doing a slapadd or will slapadd just ignore it and reassign it as necessary?

I really appreciate you taking the time to help with this.


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