[Date Prev][Date Next]
Re: v2.2.24 structural object class modification not allowed
Quanah Gibson-Mount wrote:
--On Friday, April 29, 2005 2:55 PM -0500 Curt Blank <email@example.com>
Well, you have two options, I think:
1) change uwmPerson thusly:
objectclass ( 18.104.22.168.4.1.422.214.171.124 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.
This means that uwmPerson would inherit the defintions in
inetOrgPerson, and the definitions in ctCalUser objectclasses. You
might have to tweak ctCalUser further to get rid of overlap. This is
probably the most difficult way to go. ;)
2) make ctCalUser AUXILIARY, so it can be present, but not strucural,
and get rid of the SUP uwmPerson bit in its definition:
objectclass ( 126.96.36.199.4.1.2672.3.3 NAME 'ctCalUser'
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?
Yes, it could be added to any objectClass chain in the future. This is
pretty much how we do our Stanford "account" tree, it has tons of AUX
objectClasses. Whether or not it is the "best" way depends on how you
are trying to define your schema of course. ;)
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
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
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?
Yes, you would need to slapcat to a DB, and then do something like:
cat the dumped DB, pipe to sed "s/structuralObjectClass:
ctCalUser/objectClass: ctCalUser/", redirect to new LDIF file.
cat X.ldif | sed "s/structuralObjectClass: ctCalUser/objectClass:
all off the top of my head, likely syntax to the sed bit.
Thanks. One last question here at least, can't I just remove the
structuralObjectClass attribute from the dump and let slapadd put it
back in? as what ever it wants? I only ask because when I did the
slapadd from 2.0.27 it wasn't there but now it is. And for the ones that
have it they already have a objectClass: ctCalUser attribute. My real
problem is the ones that have the objectClass: uwmPerson but need to
have it be ctCalUser. If I were to change every structuralObjectClass:
uwmPerson to structuralObjectClass: ctCalUser without that dn having the
objectClass: ctCalUser attribute would that fail? Just curious. Don't
think I want to do that. Following your #2 suggestion seems like the way
I will go. When I do that and assuming I just remove
structuralObjectClass from the dump and do the slapadd, then will
structuralObjectClass be uwmPerson for all? And will that be ok and
ctCalUser then being AUXILIARY be able to be added by the Calendar
server when needed to add a new user?
This part of the discussion is getting way off OpenLDAP though, so
further non-OpenLDAP related bits should likely email directory or to
a different list.
Understood, I will ride off into the sunset. If I every get out Stanford
way I owe you a beer. :)
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html