For 2.5, it would be good to take a look at existing backends and overlays we ship as supported, and see if there are any we want to retire. I think it would be nice as well to make it so people could configure in various contrib modules via configure flags, rather than the current manual make process.
I'll start with my thoughts:
backends:
I would like to see us retire slapd-bdb and slapd-hdb. We first documented they were deprecated in March of 2013 and updated the man pages to officially note that in May of 2014. Nearly 2 years have passed since then, and it'll likely be at least another year before 2.5 is production ready. That's some 3 years. In addtion, both slapd-bdb and slapd-hdb depend on BDB versions that are not supported by Oracle, and the source to which Oracle is doing its best to remove and make inaccessible.
Another possibility is back-perl. back-sock is a better solution. OTOH, We have gotten contributions fixing issues in it as recently as April 2015, so there may be folks using it who would like to see it continue.
overlays:
I'd like to see the passwd/sha2 overlay be considered for promotion. Having the ability to set strong hashes for passwords is crucial in todays world.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
On Mon, 22 Feb 2016 18:33:47 -0800 Quanah Gibson-Mount quanah@zimbra.com wrote:
Hello,
For 2.5, it would be good to take a look at existing backends and overlays we ship as supported, and see if there are any we want to retire.
...
Another possibility is back-perl. ... We have gotten contributions fixing issues in it as recently as April 2015, so there may be folks using it who would like to see it continue.
There is a pretty elaborate back-perl-based backend available on: https://github.com/docelic/Viper/blob/master/Viper.pm
With the documentation on what it's been used for available here: http://spinlocksolutions.com/viper/doc/index.html http://spinlocksolutions.com/viper/doc/ldap.html
Could be someone finds it useful.
Thanks, D
--On Tuesday, February 23, 2016 4:06 AM +0100 docelic@spinlocksolutions.com wrote:
On Mon, 22 Feb 2016 18:33:47 -0800 Quanah Gibson-Mount quanah@zimbra.com wrote:
Hello,
For 2.5, it would be good to take a look at existing backends and overlays we ship as supported, and see if there are any we want to retire.
...
Another possibility is back-perl. ... We have gotten contributions fixing issues in it as recently as April 2015, so there may be folks using it who would like to see it continue.
There is a pretty elaborate back-perl-based backend available on: https://github.com/docelic/Viper/blob/master/Viper.pm
With the documentation on what it's been used for available here: http://spinlocksolutions.com/viper/doc/index.html http://spinlocksolutions.com/viper/doc/ldap.html
Could be someone finds it useful.
That's really cool. Thanks for the information! So sounds like it has active use.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
On Mon, Feb 22, 2016 at 06:33:47PM -0800, Quanah Gibson-Mount wrote:
I would like to see us retire slapd-bdb and slapd-hdb.
How much work is it costing to keep them around?
I agree completely with marking them deprecated and having configure disable them by default, but I also don't see a lot of reason to actually delete them as long as they keep working without having to spend any effort.
Is there any intermediate level in between deprecated and deleted? Demote to contrib?
For removing something like back-[bh]db or slapd.conf that was actually the default in the past, and therefore probably still has many users who have just carried working setups forward, I would personally be even more conservative: announce the removal (not just the fact that it's deprecated, but that it will be removed in a specific version e.g. 2.6), mention it in as many places as possible (mailing list, admin guide, man pages), and include that notice in a release a year or two in advance of the actual removal.
Another possibility is back-perl.
back-shell? Its manpage advises building slapd without threading, but last I looked, that doesn't even work any more. (Speaking of things that are broken enough to be considered for deletion...)
But to me, these both also look like things that should be disabled by default and marked deprecated, but not necessarily deleted outright, as long as they aren't actually broken.
overlays:
I'd like to see the passwd/sha2 overlay be considered for promotion.
Same. In fact I'd go as far to say I'd like to see it, or something like pbkdf2 or bcrypt, become the default, but that's wishful thinking as long as I lack cycles for helping make it happen.
I thought there was talk a while ago of autogroup possibly being promoted, is that still a possibility?
http://www.openldap.org/lists/openldap-technical/201503/msg00022.html
Ryan Tandy wrote:
On Mon, Feb 22, 2016 at 06:33:47PM -0800, Quanah Gibson-Mount wrote:
I would like to see us retire slapd-bdb and slapd-hdb.
How much work is it costing to keep them around?
I agree completely with marking them deprecated and having configure disable them by default, but I also don't see a lot of reason to actually delete them as long as they keep working without having to spend any effort.
Is there any intermediate level in between deprecated and deleted? Demote to contrib?
For removing something like back-[bh]db or slapd.conf that was actually the default in the past, and therefore probably still has many users who have just carried working setups forward, I would personally be even more conservative: announce the removal (not just the fact that it's deprecated, but that it will be removed in a specific version e.g. 2.6), mention it in as many places as possible (mailing list, admin guide, man pages), and include that notice in a release a year or two in advance of the actual removal.
As Quanah said 2.5 release will likely take another year. So I think it's ok to really get rid of back-[bh]db. The migration to back-mdb is really easy. Keeping this old cruft and later telling people all the times not to use it would be a awful waste of developer resources.
Another possibility is back-perl.
back-shell? Its manpage advises building slapd without threading, but last I looked, that doesn't even work any more. (Speaking of things that are broken enough to be considered for deletion...)
Yupp. And probably back-passwd.
Ciao, Michael.
Michael Ströder wrote:
Yupp. And probably back-passwd.
back-passwd remains as a readable model of how to write a minimal backend. It is still suitable for that purpose.
Ryan Tandy wrote:
I thought there was talk a while ago of autogroup possibly being promoted, is that still a possibility?
http://www.openldap.org/lists/openldap-technical/201503/msg00022.html
Personally I'm against this. I've seen autogroup being used in production and the size of resulting groups is ludicrous. IMO the better thing to do is make dynlist work with search filters and forget autogroup ever existed.
Quanah Gibson-Mount wrote:
back-sock is a better solution. OTOH, We have gotten contributions fixing issues in it as recently as April 2015, so there may be folks using it who would like to see it continue.
There is back-sock in production (as an overlay) for an OATH-LDAP installation.
I'd like to see the passwd/sha2 overlay be considered for promotion. Having the ability to set strong hashes for passwords is crucial in todays world.
Would be nice to have lastbind, noopsrch and passwd/pbkdf2 available as standard overlays too.
Ciao, Michael.
Le 23/02/2016 07:54, Michael Ströder a écrit :
Quanah Gibson-Mount wrote:
back-sock is a better solution. OTOH, We have gotten contributions fixing issues in it as recently as April 2015, so there may be folks using it who would like to see it continue.
There is back-sock in production (as an overlay) for an OATH-LDAP installation.
I'd like to see the passwd/sha2 overlay be considered for promotion. Having the ability to set strong hashes for passwords is crucial in todays world.
Would be nice to have lastbind, noopsrch and passwd/pbkdf2 available as standard overlays too.
in LTB packages, we also include : * autogroup * smbk5pwd
Clément OUDOT wrote:
Le 23/02/2016 07:54, Michael Ströder a écrit :
Quanah Gibson-Mount wrote:
back-sock is a better solution. OTOH, We have gotten contributions fixing issues in it as recently as April 2015, so there may be folks using it who would like to see it continue.
There is back-sock in production (as an overlay) for an OATH-LDAP installation.
I'd like to see the passwd/sha2 overlay be considered for promotion. Having the ability to set strong hashes for passwords is crucial in todays world.
Would be nice to have lastbind, noopsrch and passwd/pbkdf2 available as standard overlays too.
in LTB packages, we also include :
- autogroup
- smbk5pwd
I've also added these overlays to openSUSE package openldap2-contrib. But without krb5 support in smbk5pwd because heimdal is no longer used in openSUSe since years.
Ciao, Michael.
-
Clément OUDOT -
docelic＠spinlocksolutions.com -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy