1:11 p.m.
Hello everyone,
At this point, I believe we're ready to being testing for a 2.4.46 release.
The primary focus on this release has been to fix several long standing
issues with replication, both for "standard" and "delta" based
syncrepl.
These fixes have been tested against databases and workloads known to
trigger the problems that were encountered. Special thanks to Paul B.
Henson for doing additional validation for those issues that were
discovered in his deployment.
OpenLDAP 2.4.46 Engineering
Fixed libldap connection delete callbacks when TLS fails to start
(ITS#8717)
Fixed libldap to not reuse tls_session if TLS hostname check fails
(ITS#7373)
Fixed libldap cross-compiling with OpenSSL 1.1 (ITS#8687)
Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791)
Fixed libldap MozNSS CA certificate hash matching (ITS#7374)
Fixed libldap MozNSS with PEM certs when also using an NSS cert db
(ITS#7389)
Fixed libldap MozNSS initialization (ITS#8484)
Fixed libldap GnuTLS with GNUTLS_E_AGAIN (ITS#8650)
Fixed libldap memory leak with cancel operations (ITS#8782)
Fixed slapd Eventlog registry key creation on 64-bit Windows (ITS#8705)
Fixed slapd to maintain SSF across SASL binds (ITS#8796)
Fixed slapd syncrepl deadlock when updating cookie (ITS#8752)
Fixed slapd syncrepl callback to always be last in the stack (ITS#8752)
Fixed slapd telephoneNumberNormalize when the value is spaces and
hyphens (ITS#8778)
Fixed slapd CSN queue processing (ITS#8801)
Fixed slapd-ldap TLS connection timeout with high latency connections
(ITS#8720)
Fixed slapd-ldap to ignore unknown schema when omit-unknown-schema is
set (ITS#7520)
Fixed slapd-mdb with an optimization for long lived read transactions
(ITS#8226)
Fixed slapd-meta assert when olcDbRewrite is modified (ITS#8404)
Fixed slapd-sock with LDAP_MOD_INCREMENT operations (ITS#8692)
Fixed slapo-accesslog cleanup to only occur on failed operations
(ITS#8752)
Fixed slapo-accesslog to not expire the last entry in the database
(ITS#8100)
Fixed slapo-dds entryTTL to actually decrease as per RFC 2589 (ITS#7100)
Fixed slapo-syncprov memory leak with delete operations (ITS#8690)
Fixed slapo-syncprov to not clear pending operation when checkpointing
(ITS#8444)
Fixed slapo-syncprov to initialize an empty accesslog db if configured
(ITS#8100)
Fixed slapo-syncprov not to log checkpoints to accesslog db (ITS#8607)
Fixed slapo-syncprov to process changes from this SID on REFRESH
(ITS#8800)
Fixed slapo-syncprov session log parsing to not block other operations
(ITS#8486)
Build Environment
Fixed Windows build with newer MINGW version (ITS#8697)
Fixed compiler warnings and removed unused variables (ITS#8578)
Contrib
Fixed ldapc++ Control structure (ITS#8583)
Documentation
Delete stub manpage for back-ldbm (ITS#8713)
Fixed ldap_bind(3) to mention the LDAP_SASL_SIMPLE mechanism
(ITS#8121)
Fixed slapd-config(5) typo for olcTLSCipherSuite (ITS#8715)
Fixed slapo-syncprov(5) indexing requirements (ITS#5048)
LMDB 0.9.22 Engineering
Fix regression with new db from 0.9.19 (ITS#8760)
Fix liblmdb to build on Solaris (ITS#8612)
Fix delete behavior with DUPSORT DB (ITS#8622)
Fix mdb_cursor_get/mdb_cursor_del behavior (ITS#8722)
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:33 p.m.
On su, 11 helmi 2018, Quanah Gibson-Mount wrote:
Hello everyone,
At this point, I believe we're ready to being testing for a 2.4.46
release. The primary focus on this release has been to fix several
long standing issues with replication, both for "standard" and "delta"
based syncrepl. These fixes have been tested against databases and
workloads known to trigger the problems that were encountered.
Special thanks to Paul B. Henson for doing additional validation for
those issues that were discovered in his deployment.
OpenLDAP 2.4.46 Engineering
Fixed libldap connection delete callbacks when TLS fails to start
(ITS#8717)
Fixed libldap to not reuse tls_session if TLS hostname check fails
(ITS#7373)
Fixed libldap cross-compiling with OpenSSL 1.1 (ITS#8687)
Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791)
Fixed libldap MozNSS CA certificate hash matching (ITS#7374)
Fixed libldap MozNSS with PEM certs when also using an NSS cert db
(ITS#7389)
Fixed libldap MozNSS initialization (ITS#8484)
Fixed libldap GnuTLS with GNUTLS_E_AGAIN (ITS#8650)
Fixed libldap memory leak with cancel operations (ITS#8782)
Fixed slapd Eventlog registry key creation on 64-bit Windows (ITS#8705)
Fixed slapd to maintain SSF across SASL binds (ITS#8796)
Fixed slapd syncrepl deadlock when updating cookie (ITS#8752)
Fixed slapd syncrepl callback to always be last in the stack (ITS#8752)
Fixed slapd telephoneNumberNormalize when the value is spaces and
hyphens (ITS#8778)
Fixed slapd CSN queue processing (ITS#8801)
Fixed slapd-ldap TLS connection timeout with high latency
connections (ITS#8720)
Fixed slapd-ldap to ignore unknown schema when omit-unknown-schema
is set (ITS#7520)
Fixed slapd-mdb with an optimization for long lived read
transactions (ITS#8226)
Fixed slapd-meta assert when olcDbRewrite is modified (ITS#8404)
Fixed slapd-sock with LDAP_MOD_INCREMENT operations (ITS#8692)
Fixed slapo-accesslog cleanup to only occur on failed operations
(ITS#8752)
Fixed slapo-accesslog to not expire the last entry in the database
(ITS#8100)
Fixed slapo-dds entryTTL to actually decrease as per RFC 2589 (ITS#7100)
Fixed slapo-syncprov memory leak with delete operations (ITS#8690)
Fixed slapo-syncprov to not clear pending operation when
checkpointing (ITS#8444)
Fixed slapo-syncprov to initialize an empty accesslog db if
configured (ITS#8100)
Fixed slapo-syncprov not to log checkpoints to accesslog db (ITS#8607)
Fixed slapo-syncprov to process changes from this SID on REFRESH
(ITS#8800)
Fixed slapo-syncprov session log parsing to not block other
operations (ITS#8486)
Build Environment
Fixed Windows build with newer MINGW version (ITS#8697)
Fixed compiler warnings and removed unused variables (ITS#8578)
Contrib
Fixed ldapc++ Control structure (ITS#8583)
Documentation
Delete stub manpage for back-ldbm (ITS#8713)
Fixed ldap_bind(3) to mention the LDAP_SASL_SIMPLE mechanism
(ITS#8121)
Fixed slapd-config(5) typo for olcTLSCipherSuite (ITS#8715)
Fixed slapo-syncprov(5) indexing requirements (ITS#5048)
It would really help
Samba if ITS#8671 "Declare ldap_init_fd() in
ldap.h to help external consumers" would make a release too.
It is not a code change, only a documentation update but it would have
allowed us to get distributions changed with regards to ldap_init_fd
availability.
--
/ Alexander Bokovoy
9:09 a.m.
--On Monday, February 12, 2018 6:33 AM +0200 Alexander Bokovoy
<abokovoy(a)redhat.com> wrote:
It would really help Samba if ITS#8671 "Declare ldap_init_fd()
in
ldap.h to help external consumers" would make a release too.
It is not a code change, only a documentation update but it would have
allowed us to get distributions changed with regards to ldap_init_fd
availability.
Hi Alexander,
The "ldap.h" file is specifically for RFC defined interfaces. I discussed
this with Howard, and we thought that the best way to address this issue
would be to rename "ldap_pvt.h" to "openldap.h", to indicate that the
methods found in it are openldap specific. This should resolve the issue
with packagers not packaging the file as well. What do you think?
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
9:15 a.m.
On Thu, 15 Feb 2018, Quanah Gibson-Mount wrote:
--On Monday, February 12, 2018 6:33 AM +0200 Alexander Bokovoy
<abokovoy(a)redhat.com> wrote:
>It would really help Samba if ITS#8671 "Declare ldap_init_fd() in
>ldap.h to help external consumers" would make a release too.
>
>It is not a code change, only a documentation update but it would have
>allowed us to get distributions changed with regards to ldap_init_fd
>availability.
Hi Alexander,
The "ldap.h" file is specifically for RFC defined interfaces. I
discussed this with Howard, and we thought that the best way to
address this issue would be to rename "ldap_pvt.h" to "openldap.h", to
indicate that the methods found in it are openldap specific. This
should resolve the issue with packagers not packaging the file as
well. What do you think?
That would help too, thanks.
--
/ Alexander Bokovoy
9:46 a.m.
Alexander Bokovoy wrote:
On Thu, 15 Feb 2018, Quanah Gibson-Mount wrote:
> --On Monday, February 12, 2018 6:33 AM +0200 Alexander Bokovoy
> <abokovoy(a)redhat.com> wrote:
>
>> It would really help Samba if ITS#8671 "Declare ldap_init_fd() in
>> ldap.h to help external consumers" would make a release too.
>>
>> It is not a code change, only a documentation update but it would have
>> allowed us to get distributions changed with regards to ldap_init_fd
>> availability.
>
> Hi Alexander,
>
> The "ldap.h" file is specifically for RFC defined interfaces. I discussed
> this with Howard, and we thought that the best way to address this issue
> would be to rename "ldap_pvt.h" to "openldap.h", to indicate that
the
> methods found in it are openldap specific. This should resolve the issue
> with packagers not packaging the file as well. What do you think?
That would help too, thanks.
In the interest of maintaining the narrow bugfix-only focus of .46, I'd rather
defer this change till later. It affects quite a few files in our own source
tree, and there's evidence that it will affect a large number of 3rd party
modules as well.
We can schedule it for .47, and .47 can be pushed out shortly after .46. We
can also include other minor non-core enhancements in.47 (like back-sock
extensions) as well.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:45 p.m.
Howard Chu wrote:
We can schedule it for .47, and .47 can be pushed out shortly after
.46.
We can also include other minor non-core enhancements in.47 (like
back-sock extensions) as well.
Hmm, the back-sock changes are well tested and do not have any
incompatible impact. When .47 would be released?
Ciao, Michael.
3:56 p.m.
--On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
Howard Chu wrote:
> We can schedule it for .47, and .47 can be pushed out shortly after .46.
> We can also include other minor non-core enhancements in.47 (like
> back-sock extensions) as well.
Hmm, the back-sock changes are well tested and do not have any
incompatible impact. When .47 would be released?
Howard and I discussed probably 2-3 weeks after 2.4.46 is released.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
11:31 a.m.
New subject: 2.4.27? (was: RE24 testing call ..)
Quanah Gibson-Mount wrote:
--On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
> Howard Chu wrote:
>> We can schedule it for .47, and .47 can be pushed out shortly after .46.
>> We can also include other minor non-core enhancements in.47 (like
>> back-sock extensions) as well.
>
> Hmm, the back-sock changes are well tested and do not have any
> incompatible impact. When .47 would be released?
Howard and I discussed probably 2-3 weeks after 2.4.46 is released.
Any chance this will happen in this time-frame?
Ciao, Michael.
11:27 a.m.
New subject: 2.4.27? (was: RE24 testing call ..)
Hi Michael,
I'm currently out of the office (last week, this week, next week), so there is no
further release work going on at this time. Once I'm back in the office, I'll be
happy to look into the 2.4.47 release with the additional features we'd previously
discussed.
Warm regards,
Quanah
----- Original Message -----
From: "Michael Ströder" <michael(a)stroeder.com>
To: "Quanah Gibson-Mount" <quanah(a)symas.com>, "hyc"
<hyc(a)symas.com>
Cc: openldap-devel(a)openldap.org
Sent: Friday, April 6, 2018 11:31:47 AM
Subject: 2.4.27? (was: RE24 testing call ..)
Quanah Gibson-Mount wrote:
> --On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder
> <michael(a)stroeder.com> wrote:
>
>> Howard Chu wrote:
>>> We can schedule it for .47, and .47 can be pushed out shortly after .46.
>>> We can also include other minor non-core enhancements in.47 (like
>>> back-sock extensions) as well.
>>
>> Hmm, the back-sock changes are well tested and do not have any
>> incompatible impact. When .47 would be released?
>
> Howard and I discussed probably 2-3 weeks after 2.4.46 is released.
Any chance this will happen in this time-frame?
Ciao, Michael.
--
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
12:38 a.m.
New subject: 2.4.27? (was: RE24 testing call ..)
On 04/13/2018 08:27 PM, Quanah Gibson-Mount wrote:
I'm currently out of the office (last week, this week, next
week), so
there is no further release work going on at this time. Once I'm
back in the office, I'll be happy to look into the 2.4.47 release
with the additional features we'd previously discussed.
Any chance that there
will be a 2.4.47 release with my back-sock patches?
People keep asking me about the password sync to MS AD and it is much
easier for them to just build a release than to add back-port patches
themselves.
Ciao, Michael.
----- Original Message -----
> From: "Michael Ströder" <michael(a)stroeder.com>
> To: "Quanah Gibson-Mount" <quanah(a)symas.com>, "hyc"
<hyc(a)symas.com>
> Cc: openldap-devel(a)openldap.org
> Sent: Friday, April 6, 2018 11:31:47 AM
> Subject: 2.4.27? (was: RE24 testing call ..)
> Quanah Gibson-Mount wrote:
>> --On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder
>> <michael(a)stroeder.com> wrote:
>>
>>> Howard Chu wrote:
>>>> We can schedule it for .47, and .47 can be pushed out shortly after .46.
>>>> We can also include other minor non-core enhancements in.47 (like
>>>> back-sock extensions) as well.
>>>
>>> Hmm, the back-sock changes are well tested and do not have any
>>> incompatible impact. When .47 would be released?
>>
>> Howard and I discussed probably 2-3 weeks after 2.4.46 is released.
>
> Any chance this will happen in this time-frame?
>
> Ciao, Michael.
8:58 a.m.
New subject: 2.4.27? (was: RE24 testing call ..)
--On Friday, June 15, 2018 10:38 AM +0200 Michael Ströder
<michael(a)stroeder.com> wrote:
On 04/13/2018 08:27 PM, Quanah Gibson-Mount wrote:
> I'm currently out of the office (last week, this week, next week), so
> there is no further release work going on at this time. Once I'm
> back in the office, I'll be happy to look into the 2.4.47 release
> with the additional features we'd previously discussed.
Any chance that there will be a 2.4.47 release with my back-sock patches?
People keep asking me about the password sync to MS AD and it is much
easier for them to just build a release than to add back-port patches
themselves.
There will absolutely be a 2.4.47 and as previously discussed, it would
include those patches to back-sock.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
10:01 a.m.
New subject: making ldap_pvt.h public (was: Re: RE24 testing call #1 (2.4.46) LMDB RE0.9 testing call #1 (0.9.22))
On Thu, Feb 15, 2018 at 09:09:53AM -0800, Quanah Gibson-Mount wrote:
The "ldap.h" file is specifically for RFC defined
interfaces. I
discussed this with Howard, and we thought that the best way to
address this issue would be to rename "ldap_pvt.h" to "openldap.h", to
indicate that the methods found in it are openldap specific. This
should resolve the issue with packagers not packaging the file as
well.
With my packager hat on - the main thing that would affect whether I
package the file is not the name, but whether 'make install' installs it
into the public header directory i.e. /usr/include, and whether it's
subject to interface stability guarantees similar to ldap.h.
My understanding was the _pvt interfaces are for internal consumption
and therefore subject to change without notice. I can't really package a
header, if its API/ABI might change in a patch release because some
internal slapd or tool code needed a change.
(API/ABI changes across major releases i.e. 2.4->2.5 would be fine.)
If I misunderstood the semantics and it's not "private interfaces that
could change any time" but rather "OpenLDAP extensions to the LDAP API",
then great, and let's do it :) and the rename would make sense in that
case.
10:29 a.m.
New subject: making ldap_pvt.h public
Ryan Tandy wrote:
On Thu, Feb 15, 2018 at 09:09:53AM -0800, Quanah Gibson-Mount wrote:
> The "ldap.h" file is specifically for RFC defined interfaces. I discussed
> this with Howard, and we thought that the best way to address this issue
> would be to rename "ldap_pvt.h" to "openldap.h", to indicate that
the
> methods found in it are openldap specific. This should resolve the issue
> with packagers not packaging the file as well.
With my packager hat on - the main thing that would affect whether I package
the file is not the name, but whether 'make install' installs it into the
public header directory i.e. /usr/include, and whether it's subject to
interface stability guarantees similar to ldap.h.
My understanding was the _pvt interfaces are for internal consumption and
therefore subject to change without notice. I can't really package a header,
if its API/ABI might change in a patch release because some internal slapd or
tool code needed a change.
(API/ABI changes across major releases i.e. 2.4->2.5 would be fine.)
If I misunderstood the semantics and it's not "private interfaces that could
change any time" but rather "OpenLDAP extensions to the LDAP API", then
great,
and let's do it :) and the rename would make sense in that case.
ldap_pvt.h is meant to be stable. ldap-int.h can change at any time.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:28 a.m.
Quanah Gibson-Mount wrote:
At this point, I believe we're ready to being testing for a
2.4.46
release.
I know 2.4.x should not add new features.
But these two ITS patches run well in production, affect only back-sock
and would avoid that I have to use backport-patches:
(ITS#8714) RFE: Sendout EXTENDED operation message in back-sock
(ITS#8051) add DN qualifier
So getting these into 2.4.46 would be helpful.
Ciao, Michael.
8:10 p.m.
On Sun, Feb 11, 2018 at 01:11:09PM -0800, Quanah Gibson-Mount wrote:
OpenLDAP 2.4.46 Engineering
'make check' passed on Debian unstable with the Debian build flags (via
dpkg-buildflags(1)) and configure options [1].
Will try to squeeze in some manual testing, maybe this weekend...
[1]
https://anonscm.debian.org/git/pkg-openldap/openldap.git/tree/debian/conf...
1931
days inactive
2055
days old
14 comments
5 participants
participants (5)
-
Alexander Bokovoy -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy