Avoiding further (LDAP) stack proliferation in Samba
simo at samba.org
Thu May 21 21:45:54 UTC 2020
On Thu, 2020-05-21 at 14:43 -0700, Christof Schmitt via samba-technical
> On Wed, May 20, 2020 at 07:19:59PM -0700, Jeremy Allison wrote:
> > On Thu, May 21, 2020 at 01:53:36PM +1200, Andrew Bartlett wrote:
> > > On Wed, 2020-05-20 at 18:21 -0700, Jeremy Allison via samba-
> > > technical
> > > > Are there tevent_req async versions of ldb_search() and
> > > > ldb_request()
> > > > (haven't looked, don't have the time right now, sorry) ? If
> > > > not, is
> > > > is easy to add them ?
> > >
> > > No, and I've been told that gluing the two different async
> > > architectures together isn't trivial, but it would be worth
> > > someone who
> > > really understands (or perhaps the opposite, someone who doesn't
> > > and so
> > > doesn't know what is impossible?) having a red hot go.
> > >
> > > Thankfully in this case all the calls are synchronous (some with
> > > callbacks), none return to the main event loop, so this doesn't
> > > impact
> > > this use case. This is why I suggested ldb_search() and
> > > ldb_request()
> > > would be a good match.
> > >
> > > > New code is moving to tevent_req and async as much as possible,
> > > > so
> > > > to standardize on an internal ldap stack - which would be an
> > > > amazingly
> > > > good thing to do IMHO it needs to have tevent_req and async
> > > > functionality
> > > > I think.
> > >
> > > It may be that we are unwilling to commit to the use of LDB if
> > > there
> > > isn't a clear path to being able to use tevent_req in the
> > > future.
> > >
> > > In that case, all I would ask is that we do other things to merge
> > > the
> > > stacks first, for example:
> > > - have LDB use more common layers with tldap under the
> > > hood. Some
> > > ASN.1 parsing is shared, but there is a lot that is not.
> > > - have tldap and LDB share structures (and so helper functions)
> > > like
> > > ldb_message and ldb_dn
> > > - have common ASN.1 parsing for controls
> > > - do likewise with the smbldap code and libads.
> > >
> > > Currently we have at least thee different ways an LDAP search
> > > response
> > > is expressed, for example. This makes it harder to have common
> > > utility
> > > functions.
> > >
> > > Imagine if we could prepare a struct ldb_request, but instead of
> > > passing it to ldb, we pass it to (say) tldap, and the responses
> > > are
> > > again ldb stuctures that we can use ldb utility functions on?
> > >
> > > This would work around the existing non-tevent async architecture
> > > of
> > > LDB but still avoid all the collateral duplication (which is my
> > > bigger
> > > concern).
> > >
> > > I know I'm asking a lot, but as I said, unless we pause now and
> > > plan
> > > the later merge work becomes quite epic.
> > That sounds like a sensible plan to me, but having said
> > that I'm not going to be the one doing the work :-).
> > As we as a community have decided tevent_req is "The Way"
> > then helping our older stacks integrate better with it
> > is certainly a good way to make progress IMHO (and I'm
> > as guilty as anyone as the author of the horrible hack inside smbd
> > to do async opens which sidesteps tevent_req in order
> > to reduce code changes).
> So i am trying to understand where this leaves us. The driver behind
> Swen's patchset is to move away from libads with the end goal of
> able to better control the domain controller selection.
> Now there is tldap and ldb as possible ldap libraries. Do we need to
> look at the integration of those components first, before adding the
> ldap library usage in winbindd?
> The goal of having one ldap client stack is worthwhile. From what i
> see, tldap implements the async tevent model, with the exception of
> gensec part. Also the async calls are currently not used.
> I have not looked in ldb much, on a quick look, it seems to use the
> openldap library again. Would it make sense to have ldb use tldap as
> backend and eventually move away from openldap?
Do you have a good reason for wanting that.
Are the openldap libraries causing you any issue or being insufficient
in some way ?
More information about the samba-technical