RE: Combined object/referral entries

["Howard Chu" <hyc@highlandsun.com>]

> -----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
>     (|(FILTER)(objectClass=referral)(objectClass=childReferral)),
>     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
actual work?

> 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
search_reference.

> 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
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support