deprecate pdb_ldap and "NT4-like" domains in Samba 4.13 to allow removal for Samba 4.14 in March 2021?

[Jeremy Allison]

On Wed, Jun 17, 2020 at 08:35:30AM +0300, Alexander Bokovoy wrote:
> 
> ipasam implements all but few passdb calls. I need to complete some of
> group/group type lookups and then it would be more complete.
> 
> The problem I see is not FreeIPA usage of those but rather lack of
> testing in autobuild for the code paths that lead to the PASSDB calls.

That is an excellent point !

> For example, tdbsam has no support for group lookups, no trusted domains
> support, and that means any related RPC calls will not get tested
> upstream even though they are used in environments like FreeIPA.
> 
> It is on my side to add those tests and I am working on them. Since the
> whole set is simply missing, it is not an easy job and requires time.

Thanks Alexander, that is much appreciated.

> I am not sure what is 'crufty' about this code. It actually works and
> works surprisingly well. Sure, we might change smbldap to be based on
> something else but what does it actually give us in reality? I am
> genuinely asking because to me it would look like a lot of churn for
> relatively small gain, if any.

Well what I mean when I say 'crufty' is that it isn't being
refactored/updated in line with other parts of Samba.

The goal (my goal at least) is to reduce the number of
different ldap client stacks in use in Samba. The less code
we have to support internally the better.

> I had somewhere an unfinished tree with some of smbldap refactoring but
> I couldn't find it anymore. One of bigger refactoring was to move to use
> tevent-based approach but it was not really needed for PASSDB because
> this API is synchronous and doesn't care whether operations underneath
> are asynchronous themselves.

Sure - that's right. This is very similar to the libsmb client work,
async tevent API's introduced underneath which drop seamlessly into the sync
calls using a private event context wrapped with tevent_req_poll()
calls to wait for completion.

It doesn't help the sync operations at all, but basing everything
on async calls underneath causes everything to go through one code
path for testing, and the exposed async calls mean we have the flexibility
to do non-blocking things later (even if we don't yet know what
they will be :-).

Synchronous-only API's are a dead-end IMHO :-).

> My attempt to see if I can use libldb for the same purpose led to
> immediate crashes because libldb code is not capable to run against LDAP
> servers with a schema that doesn't include (in DSE) attributes expected
> by libldb. It makes it useless for the purpose of pdb_ldap and ipasam
> PASSDB modules, for example. The crashes need to be fixed but it shows
> there is very little testing of libldb against real world LDAP servers.

That needs fixing. Can you log a bug for that explaining
how to reproduce ?

> I think adding a test environment that imitates a typical pdb_ldap usage
> can also help with libldb testing coverage.

100% agree.

> > Well that's good to know. But if Synology and QNAP need
> > this also, then if would be good to hear from them directly
> > on what their usage requirements are.
> 
> This can be said about almost all our users embedding Samba components
> into their products. We hardly hear from most of NAS vendors on public
> mailing lists, yet there is a lot of effort to maintain stable and
> predictable API around file server operations.

Actually we do hear quite a bit from the vendors using Samba,
but many of them don't use the public lists for that. Most of
their concerns are around the fileserver internals or winbind
use - I've never heard any questions or comments raised around
the passdb modules.

> I find this a bit
> amuzing: there is a need to be fair at a treatment of various code paths
> and yet somehow there is simply a rejection of that.

I don't think that's completely fair - now I know
you need this stuff there's no fear it will get removed,
I now know who to bug when I need things looked at :-).