openldap-devel April 2018

openldap-devel@openldap.org

4 participants
4 discussions

asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder 04 Nov '21

04 Nov '21

hyc(a)symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. Maybe I missed something. But this is the first time I've heard about -DNDEBUG being mandatory when compiling binary packages for production use. Does it have other effects? And what are general rules for assert statements in OpenLDAP code? In my own (Python) code assert statements are supposed to be only triggered if something goes wrong *internally* (type issues etc.). If somebody manages to trigger an assert statement with invalid input from "outside" I always consider this to be a serious bug revealing insufficient error handling even though e.g. web2ldap just logs the exception but won't crash. YMMV, but please clarify. I also wonder whether there are more mandatory rules for building packages and where I can find them. Please don't get me wrong: My inquiry is in good faith to avoid unnecessary ITS based on misunderstanding. Ciao, Michael.

1 1

RE24 testing call #1 (2.4.46) LMDB RE0.9 testing call #1 (0.9.22)
by Quanah Gibson-Mount 15 Jun '18

15 Jun '18

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>

5 14

Binary log format
by Howard Chu 26 Apr '18

26 Apr '18

So, thinking along the lines of a binary log format for StatsLog, to avoid the syslog overhead, the first obvious idea was to just dump timestamped BER messages into a logfile, and have a separate postprocessor command produce human readable text. Thinking further about this, we could just dump PCAP format - and use tcpdump, WireShark, or whatever favorite tool to render the log. If all we want is a timestamped log of messages that slapd has processed, we can do that right now and won't have to invest any effort at all into postprocessors. That still leaves a question of what to do with Debug messages that also go to syslog - it's easier to identify problems if the error message appears somewhere close to the log of the original request. So we'd need a tool to interleave these in order, if we had to pull messages both from the binary log and from syslog. Or, we could define a new custom packet type for these Debug/diagnostic messages, and just spit them out into the PCAP file too. This might require us to write a custom parser plugin for WireShark or whatever, to render these messages. That's still not a big deal, compared to inventing our own entire log postprocessing framework. Thoughts, suggestions? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Beginner projects
by Lawrence, Andy 21 Apr '18

21 Apr '18

Hi, Me and one of my colleagues are interested in contributing to OpenLDAP. Do you have any interesting projects that new comers such as myself could work on? With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, United Kingdom mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation<http://www.siemens.com/rail-automation> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House, Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00016033

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel April 2018