Re: adding url attribute to Organization or Organizational unit

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

At 02:36 AM 1/18/00 +1100, Craig Silva wrote:
>I have been attempting to add a labeledURL attribute to the objectclass organization by following the suggestion in the documentation to use an auxilliary object class.
>

Yes, to add a labledURL, you can mix in labeledURLObject to any
existing entry.

>Ldapmodify returns an objectclass violation error.

Did you add labledURLObject to the list of object classes of the
entry?

>It may be that I have misinterpreted the documentation.
>
>It appears to say that you can add an auxilliary classobject to a previously defined classobject. (this is unclear)

No.  You add the objectclass to the previous defined ENTRY.

>Is it however the case that an auxilliary classobject is simply a new classobject with the appropriate attributes i.e. a local schema ?

No.  An auxiliary object class is a class which allows an entry
of a given structure to take on additional attributes.  In X.500,
an entry is of one structural objectclass (which might be derived
from other objectclasses).   The structure of an entry cannot be
changed, but you can augment an existing entry with auxiliary
objectclasses.   An abstract objectclass, such as 'top', is one
that cannot be instantiated.

In OpenLDAP 1.2 schema format doesn't explicitly state whether an
objectclass is "structural", "auxiliary", or "abstract" and, obvously
cannot enforce schema rules based on objectclass category.  You must
rely on the objectclass's documented definition (usually found in
an RFC or X.500 documentation).  However, you should use them them
in a manner consistent with their category as eventually we will
enforce such information model requirements.

That is, each entry should be of one structural objectclass.  You
should list derived classes as values of the objectclasses values.
Once created, you should never change, add, modify, delete the
objectclasses which affect the "structure" of the entry.  That is,
you shouldn't change a person to an inetOrgPerson (or vica versa)
after initial creation.

If you need to augment an entry, use an auxiliary objectclass.

>If so, and the objectclasses that come with openldap have either too few or too many or not the right attributes, how best can one stay on track - having spent a number of nights reading the documentation, I do not know  how I might  ensure that if I use a non-standard schema I can maintain compatibility so that when v2.0 is available I can move to adopt ldap v3.

In 1.2, the listed attribute of an objectclass are exploded to include
all allowed and/or required, including those allowed/required through
inherience.

The best way to maintain compatibility for the future is to add all
local attributes to "auxiliary" objectclasses and mix these in as
needed.  Then, when you update to 2.0, you'll have to sort out some
changes between LDAPv2 circa and LDAPv3 circa "standard" schema items,
but all your local objectclasses should translate fairly directly
into the new schema definition format.

----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>