Avoiding further (LDAP) stack proliferation in Samba

[Jeremy Allison]

On Tue, Jun 09, 2020 at 11:03:18AM +0100, Rowland penny via samba-technical wrote:
> On 09/06/2020 10:53, Ralph Boehme via samba-technical wrote:
> > Am 6/9/20 um 11:15 AM schrieb Andrew Bartlett via samba-technical:
> > > I'm sorry, I still hold to my disagreement.
> > > 
> > > It is really important to understand that while this will fix bugs, I
> > > don't see this as a bug fix.  This is a lift-and-shift.  These
> > > operations are both delicate and risky.  They also often fix bugs and
> > > introduce important new features.
> > > 
> > > But this change needs to be evaluated at that, fully aware of the
> > > implications, not just passed in as a bug fix.
> > > 
> > > I've been involved in implementing and in particular reviewing a large
> > > number of lift-and-shift operations in Samba.  Rarely are they as
> > > simple as they appear, and this one has the added complexity in what
> > > I've raised about the target.
> > > 
> > > Therefore this cannot be simple regarded as a 'bug fix'.  I'm very
> > > sorry.
> > > 
> > > Furthermore I've been told that this is actually the culmination of a
> > > significant amount of work over a period of months or even a year.  I'm
> > > incredibly sad that this work got to this late stage before public
> > > discussions allowed these issues became apparent.
> > > 
> > > That is awful for everyone, and for that I'm sorry.
> > I'm sorry, but to me this looks like the better is the enemy of the
> > good. Replacing libads with the existing and already used tldap library
> > is a step in the right direction.
> > 
> > -slow
> > 
> Hi, can I ask a few questions here ? What, if anything,  will change from
> the users point of view if libads is changed for the tldap library ? Will a
> user notice, will everything work as before, will the user experience be
> better or worse ?

That's a *really* good question IMHO, and should be the driver
of everything we do (just my 2cents).

I *think* (this not being directly my area) that moving internally
to tldap allows winbindd to become much more async internally,
thus allowing improved responsiveness when under heavy load,
and preventing the "winbindd is hanging" reports from users.

Now how we get there from here is the $64000 (or should that
be £50,243.20 in your case :-) question..