Tasks for OpenLDAP in Debian

[Ryan Tandy]

Hello John, thank you for getting in touch! I have been meaning to 
update the RFH with the current state of things, and your post has 
prompted me to finally do it. Please check there for a detailed update.

On Sat, Dec 05, 2020 at 12:11:33PM -0500, John Scott wrote:
>I've been increasingly using ldap-utils and programming with the
>OpenLDAP API for use with my organization, but am less knowledgeable about the
>server-side like slapd.

Most of the complexity and effort in the Debian package is for slapd. 
The library and client pieces are stable and not that complicated.

>I see an alphabet soup of licenses is involved, although I don't see the GPL
>mentioned. Does the FTP masters' recent decision on the system libraries
>exception or the upcoming Apache v2-licensed OpenSSL change things? If it were
>permitted, would switching to OpenSSL be something worth pursuing?

Upstream are actively interested in having us switch to OpenSSL. It 
would be a very disruptive change, and I want to see a detailed 
statement from ftp-master before I make any moves. More details on the 
RFH.

>I think I saw something about this in the 2.5 alpha release notes, so I take
>it it's still an issue. I don't know what cn=config is but I might could get
>creative making autopkgtests with other LDAP-enabled software (GnuPG
>particularly).

cn=config is the modern configuration backend for slapd, stored in an 
LDAP database instead of a slapd.conf file, and read/modified using an 
LDAP client instead of editing a text file. slapd.conf is still 
supported upstream but is deprecated and will be removed eventually.

Creating more autopkgtests would be an excellent way to start 
contributing! Right now we just have one superficial test that slapd 
starts and works. Upstream have a decent test suite, but where 
autopkgtests could really add value is the integration between LDAP and 
other packages such as Kerberos or Samba (note that some of these other 
packages already have autopkgtests involving slapd). Testing some slapd 
overlays might be useful too. As you mentioned you do some programming 
with the library, I would also welcome an autopkgtest that would build 
some code with libldap and run it against slapd.

>I love bug triaging 😀

The rate of incoming new bugs is pretty low these days. For the existing 
open bugs, I think I understand all of them pretty well already, and 
it's just a matter of coming up with the time/interest to actually work 
on them.

>I get the impression that the OpenLDAP package in Debian tries to follow
>upstream fairly closely. Do minor releases like 2.5 require a transition? I
>guess 2.4 was released in 2007, there may not be many to speak of.

Don't let the minor version number fool you... OpenLDAP 2.5 is a major 
release with 13+ years of accumulated code changes. The library API is 
very stable, so the transition part should not be too painful. Most of 
the changes (and all of the incompatible ones) are in slapd. Supporting 
slapd 2.4 to 2.5 upgrades in Debian is going to be a lot of work, 
especially for systems originally installed with an older Debian release 
(like squeeze or earlier) and upgraded since then.

>I see the TODO to clean up the debian/ directory and build rules which is well
>out of my reach, so I don't plan to dwell too much on that. Let me know if
>there's anything else particularly important to be done before Bullseye.

I think the current package is in OK shape for bullseye; at least I 
don't have any urgent tasks in mind. It's really the eventual upgrade to 
2.5 that I'm looking for help with, as well as some long-standing 
improvement projects which I have mentioned now in the RFH.

Thank you!

Ryan