[Date Prev][Date Next]
Re: host schema conflict
At 03:18 PM 9/6/2004, Seth Faxon wrote:
>I'm sorry but I guess I didn't really state my question very well.
>The doc you mention says:
I've updated this answer.
This particular error refers to the rule about STRUCTURAL
objectclasses, which states that an object is of one
STRUCTURAL class, the structural class of the object. The
object is said to belong to this class, zero or more
auxiliaries classes, and their superclasses. While all
of these classes are commonly listed in the objectClass
attribute of the entry, one of these classes is the
structural object class of the entry. Thus, it is OK for
an objectClass attribute to contain inetOrgPerson,
organizationalPerson, and person because they inherit one
from another to form a single superclass chain. That is,
inetOrgPerson SUPs organizationPerson SUPs person. On the
other hand, it is invalid for both inetOrgPerson and account
to be listed in objectClass as inetOrgPerson and account are
not part of the same superclass chain (unless some other class
is also listed with is a subclass of both).
To resolve this problem, one must determine which class will
better serve structural object class for the entry, adding
this class to the objectClass attribute (if not already present),
and remove any other structural class from the entry's
objectClass attribute which is not a superclass of the
structural object class.
Which object class is better depends on the particulars of
the situation. One generally should consult the documentation
for the applications one is using for help in making the
Unless you are dealing with custom applications, I see little
reason why custom schema would be needed. Even with custom
applications, I believe custom schema should be avoided as
much as possible.
As the new FAQ answer suggests, I suggest you seek advice on
how to resolve the schema error from the documentation (and
support forums) for the applications you are using.