[Date Prev][Date Next]
RE: Combined object/referral entries
> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Hallvard B Furuseth
> Here is a suggestion for Work For Somebody - not for me for a while,
> I'm afraid:
> It would be useful to have directory objects that can be read and
> one-level searched for normally, but which turn into continuation
> references if one attempts to go below them. (Subtree search
> through them, or one-level search based at them, and noSuchObject
> with matchedDN = such an entry. Not sure about Bind.)
We have something similar to this in Connexitor, except it actually chains
the query (ala back-ldap). In general, LDAP referrals are mishandled so often
by clients that I rather the server just take care of it.
> One would probably also regularly contact all servers which such
> object/referral entries point to, and refresh the entries from these
> servers. That can be left to a client, though - at least for now.
If the server carrying the reference has to contact the remote server anyway,
then it may as well just always contact the remote, like I suggested above.
> Such entries cannot have the 'referral' object class, since they
> already have another structural object class. So they must instead
> use an auxiliary class which allows the 'ref' attribute, or some
> other hack. The options I can think of are:
> (1) Use the 'ref' attribute, but without the 'referral' object
> class. Use an auxiliary 'childReferral' object class instead.
> Unfortunately, where slapd currently turns a search with
> (FILTER) into (|(FILTER)(objectClass=referral)), it must now use
> or (|(FILTER)(ref=*)) where the administrator should add a
> presence filter for 'ref'. I imagine the latter is fastest.
Something like (1) must be done, in addition to any other choice.
> (3) Define 'childReferral' to be a subclass of 'referral' and all
> structural object classes in the entry in which it occurs. Add
> objectclasses 'referral' and 'childReferral'. Or generalize and
> define a 'bottom' structural object class which is a subclass of
> all structural object classes in the entry in which it occurs.
A "bottom" class sounds like a good idea, except that it's obviously a hack
to get around the objectclass inheritance rules. Why do we have these
inheritance rules in the first place if they only get in the way of doing
> An entirely different approach: Could this be made an overlay,
Easily. Just add a response callback that examines all sent search entries.
If any contains a ref attribute, (drop the entry or keep it) and send the
> Next step: Turn back-dnssrv into an overlay which intercepts
> noSuchObject responses and saves the SRV entries that it finds to an
> LDIF file. Save these as entry/referral objects, and they will be
> refreshed from their respective servers... Such entries must be
> regularly checked against their SRV records, though.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support