Re: v2.2.24 structural object class modification not allowed

[Curt Blank <curt@uwm.edu>]

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