[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-software
Subject:    Re: v2.2.24 structural object class modification not allowed
From:       Curt Blank <curt () uwm ! edu>
Date:       2005-04-29 20:51:09
Message-ID: 42729E3D.7010108 () uwm ! edu
[Download RAW message or body]



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
[prev in list] [next in list] [prev in thread] [next in thread]