[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 2:55 PM -0500 Curt Blank <curt@uwm.edu> wrote:

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.


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


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



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: ctCalUser/" >new.ldif

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. :)


--Quanah

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