Avoiding further (LDAP) stack proliferation in Samba
cs at samba.org
Thu May 21 21:43:13 UTC 2020
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 being
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 can
see, tldap implements the async tevent model, with the exception of the
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?
More information about the samba-technical