openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

LMDB: iterating over the whole DB
by Vladimír Čunát 31 Aug '20

31 Aug '20

Hello. (I sent the same message 24h ago before subscribing, but it hasn't arrived so far. I hope you won't see a duplicate later.) We have a process that needs to analyze the contents of a whole LMDB. So far the approach was to open a read-only transaction and use a cursor to iterate over the whole contents in order. This long transaction apparently causes other concurrent process(es) to get MDB_MAP_FULL from mdb_put() even though that LMDB has plenty free pages at that moment. That would be a big problem for us, but fortunately we don't need the analysis to be atomic and splitting that iterating into smaller transactions seems to avoid the problem. That were just experiments without understanding why exactly it happens (though I get that long transactions are generally problematic). Could this behavior be considered a bug in LMDB? Is there a way of either distinguishing this MDB_MAP_FULL event from really full LMDB or avoiding it with confidence? (We only experimented with the number of keys accessed in one transaction.) By the way, thanks a lot for LMDB! --Vladimir https://knot-resolver.cz

3 6

OpenLDAP and Ansible
by Stefan Kania 31 Aug '20

31 Aug '20

I wrote some Ansible roles to set up a testing environment, mybe someone is interested in testing the roles. You can find all files and a descripton on my page: https://www.kania-online.de/using-ansible-to-set-up-an-openldap-environment/

3 3

Re: Antw: [EXT] Re: Have daemon reload rotated certs
by David Arnold 31 Aug '20

31 Aug '20

> Or maybe just check the modification time of the file from time to > time and re-initialize if files did change. > In Linux you could even set up a file change notification. I think > cron detects crontab changes that way (failing on symbolic links). I'm trying to make OpenLDAP play in concert with SPIFFE workload api. I figured a frontend overlay would be the right choice if I were to implement the whole of the SPIFFE workload attestation API in it. Maybe that would be a good thing to do, but I'm seriously constrained by my (nonexistent) C skillset, so my options are unfortunately somewhat limited. On the other hand, different folks might wish to roll their certificates differently without using SPIFFE (will SPIFFE prevail?). So I think the most useful solution for OpenLDAP users in a general sense would be OpenLDAP to recreate ssl contexts if it detects the current one got expired. I started looking at the code and was thinking on how to modify <https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/…> > #define HAS_TLS( sb ) ber_sockbuf_ctrl( sb, LBER_SB_OPT_HAS_IO, \ > (void *)tls_imp->ti_sbio ) It is used to check if a TLS context exists on the socket, and if not creates one. Modified semantics, that would perfectly cover the use case would check if the socket has a non-expired tls context. If expired, delete it and create it (exactly once and if still expired, bail out with an error) and if non-existent, create it (as currently implemented). Maybe directly implemented in `ldap_pvt_tls_accept` & `ldap_int_tls_connect` > if ( HAS_TLS( sb )) { > ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); > } else { But then I wonder if it's a good idea to reset the context out of tls2.c? And what's the difference between default tls context and other tls context? I understand the difference between a server tls and a non-server tls contexts, but how do I tell which is which? Does such a design make sense? - Note, I'm happy with a works for me patch, but if such thing would grow generally useful and would be accepted, I'd be more than happy. Best Regards, David A. On Mon, Aug 24, 2020 at 08:11, Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> David Arnold <dar(a)xoe.solutions <mailto:dar@xoe.solutions>> >>>> schrieb am 21.08.2020 um 23:53 in Nachricht > <7TOFFQ.C256O3KUUI8O1(a)xoe.solutions > <mailto:7TOFFQ.C256O3KUUI8O1@xoe.solutions>>: > > [...] >> Furthermore, would this dummy change also reload the certificates >> that >> are configured for the syncrepls? > > If your do not replicate cn=config, then: No. > > [...] >> I'm starting to think plain process signalling for reloading the TLS >> context would actually be a cleaner, more elegant and stable >> solution. > > Or maybe just check the modification time of the file from time to > time and re-initialize if files did change. > In Linux you could even set up a file change notification. I think > cron detects crontab changes that way (failing on symbolic links). > >> Would you be ok if I opened an issue for that? > [...] > > Regards, > Ulrich > >

2 4

RE24 testing call #2 (OpenLDAP 2.4.52)
by Quanah Gibson-Mount 28 Aug '20

28 Aug '20

This is the second testing call for OpenLDAP 2.4.52. Depending on the results, this may be the final testing call. Generally, get the code for RE24: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && "make its" to run through the regression suite. Thanks! OpenLDAP 2.4.52 Engineering Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318) Added libldap OpenSSL support for multiple EECDH curves (ITS#9054) Added slapd OpenSSL support for multiple EECDH curves (ITS#9054) Fixed librewrite malloc/free corruption (ITS#9249) Fixed libldap hang when using UDP and server down (ITS#9328) Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324) Fixed slapd syncrepl regression that could trigger an assert (ITS#9329) Fixed slapd-mdb index error with collapsed range (ITS#9135) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 7

Re: RE24 testing call #2 (OpenLDAP 2.4.52)
by Nick Folino 28 Aug '20

28 Aug '20

No issues on Fedora 32 - 5.7.17-200.fc32.x86_64 I no longer build with bdb/hdb 3 different computers with the following processors: AMD Ryzen 5 2500U Intel Xeon E5630 Intel Core i5-3470 On Thu, Aug 27, 2020 at 9:37 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the second testing call for OpenLDAP 2.4.52. Depending on the > results, this may be the final testing call. > > Generally, get the code for RE24: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && "make its" to run through the regression suite. > > Thanks! > > > OpenLDAP 2.4.52 Engineering > Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318) > Added libldap OpenSSL support for multiple EECDH curves (ITS#9054) > Added slapd OpenSSL support for multiple EECDH curves (ITS#9054) > Fixed librewrite malloc/free corruption (ITS#9249) > Fixed libldap hang when using UDP and server down (ITS#9328) > Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324) > Fixed slapd syncrepl regression that could trigger an assert > (ITS#9329) > Fixed slapd-mdb index error with collapsed range (ITS#9135) > > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

RE24 testing call #1 (OpenLDAP 2.4.52)
by Quanah Gibson-Mount 27 Aug '20

27 Aug '20

This is the first testing call for OpenLDAP 2.4.52. Depending on the results, this may be the only testing call. Generally, get the code for RE24: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.52 Engineering Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318) Added libldap OpenSSL support for multiple EECDH curves (ITS#9054) Added slapd OpenSSL support for multiple EECDH curves (ITS#9054) Fixed librewrite malloc/free corruption (ITS#9249) Fixed libldap hang when using UDP and server down (ITS#9328) Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324) Fixed slapd syncrepl regression that could trigger an assert (ITS#9329) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 5

Re: RE24 testing call #1 (OpenLDAP 2.4.52)
by Braiam 27 Aug '20

27 Aug '20

On Wed, Aug 26, 2020 at 7:07 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. Can't run the regression suite. ➜ tests make Making all in /«BUILDDIR»/openldap-OPENLDAP_REL_ENG_2_4/tests Entering subdirectory progs make[1]: Entering directory '/«BUILDDIR»/openldap-OPENLDAP_REL_ENG_2_4/tests/progs' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/«BUILDDIR»/openldap-OPENLDAP_REL_ENG_2_4/tests/progs' -- Braiam

2 1

Arbitrary Root CA works for TLS/SSL verification
by Dalton Zhang 26 Aug '20

26 Aug '20

My /etc/openldap/ldap.conf file include the following, #TLS_CACERT /etc/pki/CA/certs/chain2root.pem #TLS_CACERT /etc/openldap/cacerts/fc5a8fxx.0 TLS_REQCERT demand The two CAs are from different signers, but "ldapwhoami -x -ZZ" will output Anonymous (means TLS/SSL is working) when one of the two TLS_CACERT lines is uncommented. Actually the first is the right one, I just didn't expect that the second one also work. If both are commented, I get the following error, ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) Can someone help me to understand what's wrong? Dalton

2 2

Have daemon reload rotated certs
by David Arnold 22 Aug '20

22 Aug '20

Hello, I'm using SPIRE/SPIFFE for workload attestation and authC, work brilliant in combination with the spiffe-helper. The spiffe helper communicates with the workload attestation API over a linux socket and provides and rotates the certificates, and then starts the actual daemon process (slapd in our case). Every 5 minutes certificates are rotated and the helper proactively requests new certs at 80% of TTL. It goes on to provision the newly supplied certs and then signals the daemon process to reload (config-reload, certs-reload, restart, whatever) through a configurable singal (eg. SIGHUP). An alternative is to run the daemon independently and run the helper as a sidecar process which then communicates with the daemon process through other means (unix socket, TCP socket) to communicate the need for configuration reload. I - think - I understood that slapd does not have a SIGNAL API by which I can tell it to reload certificates (or subsidiarily configuration). Neither did I find a signal which causes slapd to restart, which still would be acceptable. Hece I figure, my only option is to deploy the helper as a sidecar process and have it cause the slapd daemon to reload its config over the ldap protocol. For postgres, such thing is achieved similarily for exmample by the query "SELECT pg_reload_config();". What are my options in ldap - given that slapd.conf is used by the underlying system, unfortunately not dn=config (olc)? Thank you in advance for your help! Best Regards, David Arnold

4 12

Symas OpenLDAP for Linux RHEL7 & RHEL8 2.4.51-1 now available
by Quanah Gibson-Mount 22 Aug '20

22 Aug '20

Symas OpenLDAP for Linux on RHEL7 and RHEL8 for OpenLDAP 2.4.51-1 are now available. As previously noted, the RHEL8 packages differ from the Red Hat packages in that they do not contain Red Hat's patch violating RFC 4513 and RFC 6125. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical