[Date Prev][Date Next]
Re: v2.2.24 structural object class modification not allowed
--On Friday, April 29, 2005 2:55 PM -0500 Curt Blank <email@example.com> wrote:
Well, you have two options, I think:
1) change uwmPerson thusly:
objectclass ( 184.108.40.206.4.1.4220.127.116.11 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 ( 18.104.22.168.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 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
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.
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
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html