Re: The right way to add auxiliary classes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:22 PM 6/29/00 +0000, dan@docmail.docisp.com wrote:
>What's the right way to add auxiliary classes?

I suggest you design your schema in terms of LDAPv3.  Then
map this specification into OpenLDAP formats.  An LDAPv3 object
class can be mapped to a OpenLDAP object class which allows/requires
the MAY/MUST attributes of the auxiliary class (and its superiors).

See dcObject for an example of such.

>I am going to use 'organizationalPerson' object class that's shipped
>with OpenLDAP, but need to store additional information, like 'givenname'
>that's absent from that class. I createad a separate blah.oc.conf for my
>purposes that should be auxiliary to 'organizationalPerson'. If I'd like
>to create an entry in the database like rid=blah,dc=ldap,dc=domain,dc=com,
>what should be specified for it's 'objectclass' attribute if 
>that entry should contain attributes from both blah and organizational person?

In LDAPv3 terms, you list the structural object class of the entry, any
superior object classes of this structural object class, any auxiliary
object classes, and their superiors.  Not that 'top' is superior to
all structural object classes, so list it as well.

>Is the following correct? Since OpenLDAP does not distinguish between object
>class types, what's the most optimal way to create entries for easier migration
>to LDAP V.3 server in the future?

That depends.  I generally suggest you use auxiliary classes for local
additions and mix them in as needed.  When creating entries, list all
relevant classes as noted above.


>objectclass: person
>objectclass: organizationalperson
>objectclass: blah
>
>Also do I need to merge organizationalPerson definition with blah definition
>for best migration path to LDAP V.3?

Merge?  I suggest blah be an auxiliary class with no superior.