[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: updated app schemas?





--On Mittwoch, 5. März 2003 17:08 -0500 "Brian K. Jones" <jonesy@CS.Princeton.EDU> wrote:

Hi all.

I just upgraded from 2.0 to 2.1 and, as initially suspected, I have
fallen prey to the inheritance chain issues.  Luckily, I seem to have an
ok grip on this stuff - the whole reason for upgrading was to confirm my
suspicions and prove a few related guesses :-)

Anyway, what I'm wondering now is this:  Have the different application
vendors begun overhauling their (improperly created?) schemas so that
they will play nice with the standard schemas and the stricter schema
checking of 2.1 - or is this left as an exercise for the user?  Any
pointers to *published* schemas would be helpful.  I prefer them over
rolling my own.  At least then there's a chance someone *else* is using
them as well.

Ask your vendors to align their schemas with existing LDAP (really X.500) standards. It helps - at least it did for samba:
<http://lists.samba.org/pipermail/samba-technical/2002-May/036988.html>


For example, officePerson, evolutionPerson, and zillaPerson are all
defined as STRUCTURAL, which I can't fathom being necessary, but what's
worse is that they're also all derived from inetOrgPerson!

Maybe I'm missing a rule or two and Kurt can help out here, but I
thought that I read that when you define an object - zillaPerson for
example - and you subclass an existing object - in this case
inetOrgPerson - the new objectclass must be of the same type
(STRUCTURAL, ABSTRACT or AUXILIARY) as its parent.  Is this true?  If
so, there's much work ahead for those out there supporting multiple
email clients, posixAccounts, samba, sendmail and other 'stuff'.

Assuming a typical 'ou=People' entry in OpenLDAP 2.0 created with this
goal of supporting everything, what I gather then is that we need to
gather up all the objectclasses which claim to be STRUCTURAL and have
the same SUP, pick ONE of them, and then simply continue the chain?  So
I can keep evolutionPerson the way it is, and then change officePerson
and zillaPerson to follow the chain (in fact, they probably could be AUX
anyway, no?).

You shouldn't modify published schemas. Instead create a new structural object class which SUPs officePerson, evolutionPerson and zillaPerson. The X.500 data model supports multiple inheritance.


Norbert