openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠openldap.org 29 Aug '16

29 Aug '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) After setting the sessionlog for syncprov to a large size so as to avoid ITS#8125. However, due to the sessionlog being a linear linked list, it can be vastly inefficient to iterate, and slows down the master to the point that searches can time out. Howard suggests converting it into a tree instead to help obviate the load this currently induces.

1 0

(ITS#8485) [PATCH] Adding support for encrypted server private keys
by ahnolds＠gmail.com 29 Aug '16

29 Aug '16

Full_Name: Alec Cooper Version: HEAD of master branch OS: Ubuntu Linux 16.04 URL: ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch Submission from: (NULL) (73.134.243.211) Adding support for encrypted server private keys. The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and tls_o.c to send a password to the underlying TLS library. Changes to ldap.h, init.c and ldap-int.h expose the new LDAP_OPT_X_TLS_KEYPASSWORD in the main API. Changes in the contrib/ldapc++ directory expose the corresponding TlsOptions::KEYPASSWORD option in the C++ API. Changes in the servers directory expose equivalent options for servers as configuration file entries or environment variables. Changes in the doc directory add documentation about the new options and remove statements that indicated that encrypted keyfiles are not supported. New files in the test directory are for testing TLS connections, both in general and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM formatted certs and keys, and for MozNSS using cert/key databases. The new unit test (test065-tls) has been written to detect when using NSS, and use the cert/key databases in this case. I have been unable to get a working version of libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles - testing for this case would be welcome! Notice of origin: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Alec Cooper ahnolds(a)gmail.com. I have not assigned rights and/or interest in this work to any party. Rights statement: I, Alec Cooper, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. The patch has been uploaded to the OpenLDAP FTP server and can be found at ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch

1 0

Re: (ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined
by h.b.furuseth＠usit.uio.no 27 Aug '16

27 Aug '16

Seems the test for MultiByteToWideChar() == 0xFFFD can be dropped. The MultiByteToWideChar doc mentions U+FFFD under Return Value. But when I test bad UTF-8 characters, it inserts 0xFFFD for the bad character(s) in the output string. It doesn't return 0xFFFD. Or if we pass the MB_ERR_INVALID_CHARS flag, it returns 0 and sets GetLastError() as usual. (I wonder if I had a hand in this code - looks like my kind of thing to write a draft from the Windows doc but leave the Windows testing to someone else:-)

1 0

(ITS#8484) tlsm_register_shutdown_callonce needs to be reinitialized
by soohoon.lee＠f5.com 23 Aug '16

23 Aug '16

Full_Name: soohoon lee Version: HEAD OS: linux 7.2 URL: ftp://ftp.openldap.org/incoming/soohoon-lee-160823.patch Submission from: (NULL) (50.205.70.164) When there's a persistent daemon for auth and it sets LDAP_OPT_X_TLS_NEWCTX, it fails to auth at third login. 1. everything is good and destroyed after use but tlsm_register_shutdown_callonce.initialized=1. 2. still good but because tlsm_register_shutdown_callonce.initialized==1, it fails to register shutdown function. so pem_module is not destroyed at the end. 3. pem_module is not NULL so it's not initialized again and not added to modules list. And Login fails.

1 0

Re: (ITS#8483) CMake buildsystem support for LMDB
by hyc＠symas.com 20 Aug '16

20 Aug '16

Ivan Shapovalov wrote: > On 2016-08-20 at 03:32 +0100, Howard Chu wrote: >> intelfx(a)intelfx.name wrote: >>> >>> Full_Name: Ivan Shapovalov >>> Version: LMDB 0.9.18 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch >>> Submission from: (NULL) (77.41.63.43) >>> >>> >>> This patch adds a CMake buildsystem for LMDB, side-by-side with >>> existing >>> Makefile. >>> It builds the same targets except coverage tests. >> >> I am not a fan of CMake. Using it requires learning a whole new set >> of >> documentation in addition to knowing the rules of Make. It comes with >> a huge >> footprint of dependencies, and most people using it are misusing it. > > Mastering CMake is a lot easier than just learning to use Make... > If you don't like CMake out of personal motives, please just say so I have said so, right up front: "I am not a fan of CMake." > and don't cover it with made-up reasons. I don't need to make up reasons. I've spent a lot of time working with CMake already. When setting up a new build environment, it is ridiculously hard to debug a broken setup. Crucial information is hidden, and debug/verbose settings and log files don't reveal it. Been there, done that, no thanks. >> If you need to integrate LMDB into a particular CMake-based project, >> it's a >> lot simpler than this. E.g., >> https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/lib >> lmdb/CMakeLists.txt >> >> There's no reason to duplicate the entire Makefile when you're >> embedding LMDB >> into some other project. This also shows the correct way to use CMake >> and >> propagate threads dependencies. > This file does not cover packaging and exporting targets, which is > crucial when building multiple dependent projects in a staging tree (e. > g. cross-compiling stuff). You see, it is easier to have a single > correct build script in the upstream repo than to have many ad-hoc > build scripts in each project, each deficient in its own regard. There is no such thing as a single correct upstream CMake script since different projects have different requirements for how they intend to use their dependencies. Most projects won't need install targets for the utility commands or manpages. Most projects don't need packaging of intermediate dependencies. There's nothing to argue here. This project doesn't use CMake and we won't maintain files for tools we don't use. -- -- 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 0

Re: (ITS#8483) CMake buildsystem support for LMDB
by intelfx＠intelfx.name 20 Aug '16

20 Aug '16

--=-Nq65m7sM2GaofoKVHHN0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 2016-08-20 at 03:32 +0100, Howard Chu wrote: > intelfx(a)intelfx.name wrote: > >=20 > > Full_Name: Ivan Shapovalov > > Version: LMDB 0.9.18 > > OS: GNU/Linux > > URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch > > Submission from: (NULL) (77.41.63.43) > >=20 > >=20 > > This patch adds a CMake buildsystem for LMDB, side-by-side with > > existing > > Makefile. > > It builds the same targets except coverage tests. >=20 > I am not a fan of CMake. Using it requires learning a whole new set > of=C2=A0 > documentation in addition to knowing the rules of Make. It comes with > a huge=C2=A0 > footprint of dependencies, and most people using it are misusing it. Mastering CMake is a lot easier than just learning to use Make... >=20 > >=20 > > Rationale for this change: CMake simplifies building of LMDB with > > non-standard > > toolchains > > such as Android NDK which only support their custom buildsystem and > > CMake (via > > a > > provided CMake toolchain configuration file). >=20 > Building for Android is trivial using e.g. agcc > https://gist.github.com/angad/1033321 This "agcc" has all flags hard-coded and simply does not work with third-party NDKs such as CrystaX NDK, which is exactly the point I'm trying to make. >=20 > >=20 > > This way, one does not need to extract required compiler flags > > manually. > > Moreover, this simplifies life for projects which use CMake and > > LMDB, because a > > proper CMake buildsystem allows to e. g. automatically pass > > transitive > > dependencies like pthreads to dependent projects. >=20 > Using agcc allows one to build for Android any project that simply > uses Make,=C2=A0 > which was 100% of them before CMake came along. This is false, as shown above. >=20 > Transitive dependencies like pthreads, which you have now embedded > into your=C2=A0 > CMakeLists.txt file, are actually compiler and platform dependent. > That's why=C2=A0 > the LMDB Makefile sets it in an overridable macro, that a programmer > can=C2=A0 > easily change on the commandline when invoking make on their chosen > build=C2=A0 > platform. True; this can be fixed. >=20 > Rejecting this patch and all future patches involving CMake. We will > not use=C2=A0 > this tool ourselves and we will not maintain files that it uses in > the LMDB=C2=A0 > source tree. If you don't like CMake out of personal motives, please just say so and don't cover it with made-up reasons. >=20 > If you need to integrate LMDB into a particular CMake-based project, > it's a=C2=A0 > lot simpler than this. E.g., > https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/lib > lmdb/CMakeLists.txt >=20 > There's no reason to duplicate the entire Makefile when you're > embedding LMDB=C2=A0 > into some other project. This also shows the correct way to use CMake > and=C2=A0 > propagate threads dependencies. >=20 This file does not cover packaging and exporting targets, which is crucial when building multiple dependent projects in a staging tree (e. g. cross-compiling stuff). You see, it is easier to have a single correct build script in the upstream repo than to have many ad-hoc build scripts in each project, each deficient in its own regard. --=20 Ivan Shapovalov / intelfx / --=-Nq65m7sM2GaofoKVHHN0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXt8N1AAoJEHveF8jk4w6dxNMP/0rbPnFVC6SP7ouTI8XhSdRq YmTl5f3clANv29PV5d6VpEROrbom0Exw07oBFIo4pN01Wo8/Gc48P/2NWZhO+IIZ qvhxTjatCIIZWviZprzQqQK/1VaH4F0IPA7vDHTZGu6G6OHHw70rKIWRh00x0K46 PZfmHZCN5akfdWVniX/Uc7RplAFyOzrnZZRfulfNPPCgwtwoenJ6mO0k4zWwJtP8 Yk/ipwHpXFAkuU5UQ0ObHJfmcCSebFEt53knDfUV7u2aBg24bFTMK0IfX3RuNN1D /fAV0WuoMS6HtTEfaOiUtlemjejxiOxCHFwHbe31Q2XgO3fSOuyv3qrdJCBKwJAX 8/MUbTf2RRA5pdAgiELEZ8o3mMuf0Gjs9BYC+Who5F+cy/3v0ga44MmRZwjtRZre 7h9GeqcgInNtRj9eYOeHPmSdLh8v/6RJRm7OQ/NkeFcKQdooMqd0vsbCWSWkdpyo rb3opd+mv8iRM6rVpEOyQDfWEguVIhemUB6g5/jyjO3tAcjIhwxnImvPTJXjNB9z OmTwnoVezixG8cJ6dYZYr3tSq7okBJd3DjTyxpB5VkWcp12+59vBLfkVrhEzA7Qw fMOPItN/2FymaLsh2kYv3jVLCl3r2hQ+LP2rPD4NWTC5MLcsxRCgJLfTvrALuRp0 IJCyUdAOf+xXzd6VF53n =Ln4x -----END PGP SIGNATURE----- --=-Nq65m7sM2GaofoKVHHN0--

1 0

Re: (ITS#8483) CMake buildsystem support for LMDB
by hyc＠symas.com 20 Aug '16

20 Aug '16

intelfx(a)intelfx.name wrote: > Full_Name: Ivan Shapovalov > Version: LMDB 0.9.18 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch > Submission from: (NULL) (77.41.63.43) > > > This patch adds a CMake buildsystem for LMDB, side-by-side with existing > Makefile. > It builds the same targets except coverage tests. I am not a fan of CMake. Using it requires learning a whole new set of documentation in addition to knowing the rules of Make. It comes with a huge footprint of dependencies, and most people using it are misusing it. > Rationale for this change: CMake simplifies building of LMDB with non-standard > toolchains > such as Android NDK which only support their custom buildsystem and CMake (via > a > provided CMake toolchain configuration file). Building for Android is trivial using e.g. agcc https://gist.github.com/angad/1033321 > This way, one does not need to extract required compiler flags manually. > Moreover, this simplifies life for projects which use CMake and LMDB, because a > proper CMake buildsystem allows to e. g. automatically pass transitive > dependencies like pthreads to dependent projects. Using agcc allows one to build for Android any project that simply uses Make, which was 100% of them before CMake came along. Transitive dependencies like pthreads, which you have now embedded into your CMakeLists.txt file, are actually compiler and platform dependent. That's why the LMDB Makefile sets it in an overridable macro, that a programmer can easily change on the commandline when invoking make on their chosen build platform. Rejecting this patch and all future patches involving CMake. We will not use this tool ourselves and we will not maintain files that it uses in the LMDB source tree. If you need to integrate LMDB into a particular CMake-based project, it's a lot simpler than this. E.g., https://github.com/LMDB/bitmonero/blob/master/external/db_drivers/liblmdb/C… There's no reason to duplicate the entire Makefile when you're embedding LMDB into some other project. This also shows the correct way to use CMake and propagate threads dependencies. -- -- 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 0

(ITS#8483) CMake buildsystem support for LMDB
by intelfx＠intelfx.name 20 Aug '16

20 Aug '16

Full_Name: Ivan Shapovalov Version: LMDB 0.9.18 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ivan-shapovalov-160820.patch Submission from: (NULL) (77.41.63.43) This patch adds a CMake buildsystem for LMDB, side-by-side with existing Makefile. It builds the same targets except coverage tests. Rationale for this change: CMake simplifies building of LMDB with non-standard toolchains such as Android NDK which only support their custom buildsystem and CMake (via a provided CMake toolchain configuration file). This way, one does not need to extract required compiler flags manually. Moreover, this simplifies life for projects which use CMake and LMDB, because a proper CMake buildsystem allows to e. g. automatically pass transitive dependencies like pthreads to dependent projects.

1 0

(ITS#8482) Assertion failed with back-meta
by hydrazine＠bergzand.net 20 Aug '16

20 Aug '16

Full_Name: Koen Zandberg Version: 2.4.44 OS: Debian Jessie URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.89.160.191) I'm currently deploying an openldap server (version 2.4.44 ltb-project package) with back-meta and with config in the in database format. Slapd crashes with an assertion failed error whenever I modify the suffixmassaging property in the config of one of the backends of my meta backend. What did I do: I created an olcDatabase={2}meta,cn=config with multiple backends. The intial config was converted from a slapd.conf style configfile. Openldap loads the config correct and everything works as expected. I've tried editting one of the rewriterules of the meta URI backends (olcMetaSub={0}uri,olcDatabase={2}meta,cn=config) with ldapvi. specifically the olcDbRewrite: {0}suffixmassage What did I expect: Either an updated rewriterule or an error when committing. What happens: Slapd crashes with an assertion error: slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed. Aborted It seems to happen when any rewriterule is modified, not only when modifying the suffixmassage rules If more information is required such as more debug information or specific config options I gladly provide them Regards Koen Zandberg

1 0

Re: (ITS#8481) macOS shared libraries should be .dylib not .so
by hyc＠symas.com 19 Aug '16

19 Aug '16

ilovezfs(a)icloud.com wrote: > Full_Name: ilovezfs > Version: LMDB_0.9.18 > OS: macOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.168.32.161) > > > This is in regard to the Homebrew formula for LMDB (See > https://github.com/Homebrew/homebrew-core/pull/2317). Currently, we are having > to patch the shared library extensions from .so to .dylib, which is the correct > file extension on macOS. It would be great if this patch could be removed from > the formula, which would mean upstream support for automatically setting the > extension correctly based on platform in the build system. > > This is a pretty common practice, and it would be highly appreciated as we like > to as little patching as possible to upstream code for maintainability and > fidelity. > > In particular, we're currently having to do the following replacement: > ``` > inreplace "Makefile", ".so", ".dylib" > ``` Fixed in commit c6510147cee88d182af431c14a61fad6fae18be3 > Here's a typical example of how shared libraries get named on macOS: > ``` > libiconv.2.4.0.dylib -> libiconv.2.dylib > libiconv.2.dylib > libiconv.dylib -> libiconv.2.4.0.dylib > ``` > > -- -- 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 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs