[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: About superclasses and objectclass inheritance
Kurt, thanks for your quick reply and for the places where to start
looking. Investigation results are below :
Le 2002-08-27 13:01 (mardi), Kurt D. Zeilenga a écrit /
On 2002-08-27 13:01 (mardi), Kurt D. Zeilenga wrote :
> At 09:37 AM 2002-08-27, M.-A. DARCHE wrote:
> >
> >Please, could the ones who know tell me more about superclasses and
> >objectclass inheritance mechanisms as they are implemented in OpenLDAP ?
> >
> >My concern is, why, despite objectclass organizationalPerson is the
> >superclass of inetOrgPerson, if there are inetOrgPerson entries in an OpenLDAP
> >server can't I get them with the following query :
> >
> >$ ldapsearch -h localhost -b 'dc=mysite,dc=net' \
> >-x -D 'cn=Manager,dc=mysite,dc=net' -w secret \
> >'(objectclass=organizationalPerson)'
>
> If not using a current version of OpenLDAP (2.0.25 or 2.1.4), you
> should consider upgrading.
I run my tests on 2.1.4 on a Debian GNU/Linux station.
> >My understanding of the RFC is that when a client adds an entry to the
> >LDAP server, the server should add all the superclasses as objectclass
> >attributes to the given entry.
>
> Well, that's one interpretation. The other is that they are
> simply implicit in the entry's objectClass specification. This
> interpretation, I believe, is more consistent with the rest of
> the technical specification.
I agree that the interpretation I gave didn't fully satisfies me too.
I didn't though about implicit mechanisms : they could surely do a
better job.
> Anyways, whether superiors of listed classes are listed or not
> doesn't impact object class assertions. That is, asserting
> (objectClass=person) should match an entry which only lists
> inetOrgPerson.
I couldn't agree more. Query results are what is the more important in
this case :
(objectClass=person) should match an entry which only lists inetOrgPerson.
> Is test003 passing? It contains a case for this functionality.
Yes test003 is passing.
But, as I understand it, test003 doesn't exactly contain a case for this
functionality since test003 demonstrates querying only after populating
with the following LDIF content :
tests/data/test-ordered.ldif
And in this LDIF content, every OpenLDAPperson entry is _explicitly_
specified as a person objectclass :
dn: cn=Ursula Hampster,ou=Alumni Association,ou=People,o=University of Michigan,c=US
objectclass: top
objectclass: person
objectclass: OpenLDAPperson
To exactly test my point, just add the following entry at the end of :
tests/data/test-ordered.ldif
dn: cn=testEntry,ou=Alumni Association,ou=People,o=University of Michigan,c=US
objectclass: inetOrgPerson
cn: testEntry
sn: Test
And in test003-search, add the following :
echo "Testing inheritance searching..."
$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT \
'(objectclass=person)'
If OpenLDAP work as I understand it should, we should see the testEntry
entry returned... which is not the case.
With this test, could you tell me what is the behavior of OpenLDAP on
your configuration ?
What other tests could I take ?
Regards,
--
Marc-Aurèle DARCHE <http://www.cynode.org>
AFUL <http://www.aful.org>
Association Francophone des Utilisateurs de Linux/Logiciels Libres
French speaking Linux and Libre Software Users' Association