TechnoSophos wrote:
> On 1/15/07, Brandon McCombs <bmccombs@ma.rr.com> wrote:
>> Hello all,
>>
>> Is there a published list somewhere or something in the schema that will
>> allow me to determine all object classes that are or are not able to
>> contain other objects? For example, inetorgpersons, printers, and
>> ntusers are "leaf" nodes and therefore can never have anything below
>> them (as far as I know; maybe some specialized objects like policies may
>> be allowed to be under them).
>>
>> Any pointers to information?
>>
>> thanks
>> Brandon
>>
>
> Brandon,
>
> I'm interpreting your question a little differently than Kurt, in
> hopes that one or the other of us is interpreting your question
> correctly.
>
> You might want to read RFC 4512 to get a better idea for how object
> classes work, particularly the sections on the types of object
> classes. inetOrgPersons, printers, and ntusers are "leaf nodes" only
> because they are structural object classes that have no subclasses. A
> new object class could be defined (let's call it myCustomClass) that,
> for example, had inetOrgPerson as its superior. Then the object class
> attribute values for such an entry would look like this:
>
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> objectclass: myCustomPerson
>
> But then there are auxiliary object classes that can be "mixed in"
> with structural object classes. The simpleSecurityObject is an
> example.
>
> The ditcontentrule directive in slapd.conf can be used to explicitly
> set which auxiliary object classes an object of a particular
> structural object class can have.
>
> Matt
>
Does everything you say above still apply if I said that when I meant
"leaf" nodes I meant with respect to the DIT and not to the schema
structure itself?
For example, with the default schema, can I create an instance of an
inetOrgPerson underneath an organizationalPerson entry as opposed to the
usual organizationalUnit?
thanks