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

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

-- 
Andrew Bartlett                       https://samba.org/~abartlet/
Authentication Developer, Samba Team  https://samba.org
Samba Developer, Catalyst IT          
https://catalyst.net.nz/services/samba

On Tue, Jun 16, 2020 at 12:04:19PM +1200, 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 for bringing this up Andrew. I would love to be
able to remove pdb_ldap and pdb_nds. They are legacy
connections from a time (NT-PDCs) that has long since
gone.

Even if we don't immediately remove the code, marking
them as deprecated should help put people on notice
that we don't have the resources to keep maintaining
these things forever.

So a big +1 from me.

Cheers,

	Jeremy.

A very big +1 from me!

Am 16.06.20 um 02:04 schrieb Andrew Bartlett via samba:
> 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
> 
-- 
Stefan Kania
Landweg 13
25693 St. Michaelisdonn


Signieren jeder E-Mail hilft Spam zu reduzieren und sch?tzt Ihre
Privatsph?re. Ein kostenfreies Zertifikat erhalten Sie unter
https://www.dgn.de/dgncert/index.html

On Tue, Jun 16, 2020 at 12:04:19PM +1200, 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?
From what i see, this is still being used. The main usecase i see with
users is having a stand-alone file server with all the backend data
(including the Samba/SMB specific objects and attributes) stored on a
LDAP server. One of the reasons is probably to not depend on Active
Directory.

If we decide to move away from this code, i would vote for a long
deprecation period, so that we can get the message out and users can
prepare accordingly.

Christof

Mandi! Christof Schmitt via samba
  In chel di` si favelave...
> If we decide to move away from this code, i would vote for a long
> deprecation period, so that we can get the message out and users can
> prepare accordingly.
+1

-- 
dott. Marco Gaiarin				        GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''         
http://www.lanostrafamiglia.it/
  Polo FVG   -   Via della Bont?, 7 - 33078   -   San Vito al Tagliamento (PN)
  marco.gaiarin(at)lanostrafamiglia.it   t +39-0434-842711   f +39-0434-842797

		Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
      http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
	(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)