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

[Rowland penny]

On 16/06/2020 01:04, Andrew Bartlett via samba-technical wrote:
> With all the recent talk about ldap stacks, I wondered if we could
> discuss deprecating and eventually removing pdb_ldap?
>
> The reason is that pdb_ldap is primary user of smbldap.  smbldap is in
> turn yet another of our ldap stacks (I have found four so far), in the
> sense that while it uses OpenLDAP under the hood, it replicates with
> libads, ldb and tldap the 'get AD-thing out of an LDAP reply' part.
>
> I've huffed and puffed about so much over the past little while that
> sometimes it isn't clear what I'm really most frustrated by, but it
> comes down to:
>   - number of LDAP ASN.1 parsers
> and in particular
>   - number of incompatible stacks (structures and helpers) above those
> parsers
>
> For example, these functions all do the same concept:
>   - smbldap_get_single_attribute
>   - tldap_talloc_single_attribute
>   - ads_pull_string
>   - ldb_msg_find_attr_as_string
>
> We likewise have the client-side handling for paged searches in:
>   - ldb (paged_searches module)
>   - libads/ldap.c
>   - lib/smbldap.c
>   - tldap
>
> Of the two, I (perhaps strangely) actually care most about the upper
> 'helper' layer, because it is in this that we encode Samba and AD style
> LDAP on top of LDAP.  If you look around the functions I list there you
> see so much borrowed, but never made common between them.
>
> -
>
> The extensive smbldap layer, largely in duplicate with the others, is
> provided for pdb_ldap (and the pdb_nds for Netware, remember that?),
> net sam (for pdb_ldap installations), idmap_ldap and idmap_rfc2307.
>
> While it would hit a significant number of large and legacy sites that
> still have not made the move the AD, but I wondered if we could
> deprecate pdb_ldap?
>
> pdb_ldap has never been automatically tested, and is primarily in
> support of NT4-like domains (which we should deprecate at the same
> time, for consistency).
>
> Merge work is hard, particularly when the users are untested.  Removing
> smbldap would reduce by one the number of LDAP stacks, and allow us to
> focus on finding a common way forward for ldb, tldap and libads without
> needing to accommodate smbldap as well (presuming that the idmap
> modules can be migrated).
>
> What do folks think, can we move on from these features in 2021?
>
> (To be clear, we won't break stuff actually needed by FreeIPA, but
> individual codepaths might only be available to FreeIPA in some future
> release, or be only in selftest like the NTVFS file server, or be
> passed over the the FreeIPA side of the fence entirely).
>
> Thanks,
>
> Andrew Bartlett
>
Well, after I picked myself up of the floor ;-)

A very huge +1 from myself and as a side note, I noticed that Red Hat 
has sort of beat you to it, smbldap-tools isn't in epel8

Rowland