Avoiding further (LDAP) stack proliferation in Samba
abartlet at samba.org
Thu May 21 01:53:36 UTC 2020
On Wed, 2020-05-20 at 18:21 -0700, Jeremy Allison via samba-technical
> On Thu, May 21, 2020 at 11:47:50AM +1200, Andrew Bartlett wrote:
> > However, I quite strongly feel that we should not further
> > proliferate
> > the new or substantial new use of tldap in Samba without:
> > - offsetting work to reduce, not increase the number of LDAP
> > protocol
> > stacks
> > and
> > - substantial sharing of structures, ASN.1 parsing and other
> > utility
> > code
> > My preference, as these are all sync or local callback based calls
> > is
> > that you implement this with LDB. LDB is a mature, extensively
> > used
> > LDAP client library (not just the directory store for the AD DC).
> > The routines you would need are ldb_search() and
> > ldb_request(). The
> > timeout can be easily set on each request and I can assist with
> > further
> > guidance if need be.
> 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
> good thing to do IMHO it needs to have tevent_req and async
> 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
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
I know I'm asking a lot, but as I said, unless we pause now and plan
the later merge work becomes quite epic.
Andrew Bartlett https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Developer, Catalyst IT
More information about the samba-technical