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
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.
--On Monday, February 12, 2018 6:33 AM +0200 Alexander Bokovoy abokovoy@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
On Thu, 15 Feb 2018, Quanah Gibson-Mount wrote:
--On Monday, February 12, 2018 6:33 AM +0200 Alexander Bokovoy abokovoy@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 wrote:
On Thu, 15 Feb 2018, Quanah Gibson-Mount wrote:
--On Monday, February 12, 2018 6:33 AM +0200 Alexander Bokovoy abokovoy@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 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.
--On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder michael@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
Quanah Gibson-Mount wrote:
--On Thursday, February 15, 2018 10:45 PM +0100 Michael Ströder michael@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.
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@stroeder.com To: "Quanah Gibson-Mount" quanah@symas.com, "hyc" hyc@symas.com Cc: openldap-devel@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@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.
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@stroeder.com To: "Quanah Gibson-Mount" quanah@symas.com, "hyc" hyc@symas.com Cc: openldap-devel@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@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.
--On Friday, June 15, 2018 10:38 AM +0200 Michael Ströder michael@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
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.
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.
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.
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/configu...
-
Alexander Bokovoy -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy