6:33 p.m.
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
7:06 p.m.
On Mon, 22 Feb 2016 18:33:47 -0800
Quanah Gibson-Mount <quanah(a)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
7:29 p.m.
--On Tuesday, February 23, 2016 4:06 AM +0100 docelic(a)spinlocksolutions.com
wrote:
On Mon, 22 Feb 2016 18:33:47 -0800
Quanah Gibson-Mount <quanah(a)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
7:17 p.m.
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
11:14 p.m.
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.
4:57 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:54 p.m.
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.
12:51 a.m.
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
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
1:45 a.m.
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.
2762
days inactive
2772
days old
9 comments
6 participants
participants (6)
-
Clément OUDOT -
docelic＠spinlocksolutions.com -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy