deprecate pdb_ldap and "NT4-like" domains in Samba 4.13 to allow removal for Samba 4.14 in March 2021?
abartlet at samba.org
Tue Jun 16 00:04:19 UTC 2020
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
For example, these functions all do the same concept:
We likewise have the client-side handling for paged searches in:
- ldb (paged_searches module)
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
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).
Andrew Bartlett https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Developer, Catalyst IT
More information about the samba-technical