- openldap-bugs - openldap.org

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 31 Aug '16

31 Aug '16

Sorry, looks like I dropped this message. Yes, #ifdef F_NOCACHE / #elif defined O_DIRECT / #endif seems better. Included in branch "mdb/fopen" in my repo at UiO. On 24. des. 2013 18:18, Howard Chu wrote: > h.b.furuseth(a)usit.uio.no wrote: >> This was fixed in LMDB 0.9.9, except: If both O_DIRECT and >> F_NOCACHE are #defined, both are used. Looks a bit strange. >> Maybe just one should be used in that case. (Which?) Also I'm >> still wondering if env_open needs to fail if F_NOCACHE fails. >> >> Anyway, maybe it should be something like this. The "else {}" >> is in case O_DIRECT is an unsupported dummy definiton: > > Isn't that in the wrong order then? What you suggest here will use O_DIRECT > even if it's a dummy. > > I don't see any reason to fail the operation. They just want to make a > copy/backup; even if the optimization of avoiding pollution of the buffer > cache can't be done, they still want the copy to happen. > >> #ifdef O_DIRECT >> if ((rc = fcntl(newfd, F_GETFL)) != -1) >> (void) fcntl(newfd, F_SETFL, rc | O_DIRECT); >> else >> #endif >> { >> #ifdef F_NOCACHE /* __APPLE__ */ >> (void) fcntl(newfd, F_NOCACHE, 1); >> #endif >> } -- Hallvard

1 0

Re: (ITS#8488) OpenSSL 1.1.0
by hyc＠symas.com 30 Aug '16

30 Aug '16

norm.green(a)gemtalksystems.com wrote: > Full_Name: Norm Green > Version: 2.4.43 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.240.19.49) > > > Please support OpenSSL 1.1.0. Current versions of OpenLDAP will not build with > OpenSSL 1.1.0 due to OpenSSL API changes. > > Already supported in git master. Closing this ITS. -- -- 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#8488) OpenSSL 1.1.0
by norm.green＠gemtalksystems.com 30 Aug '16

30 Aug '16

Full_Name: Norm Green Version: 2.4.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.240.19.49) Please support OpenSSL 1.1.0. Current versions of OpenLDAP will not build with OpenSSL 1.1.0 due to OpenSSL API changes.

1 0

Re: (ITS#8487) Properly handle realloc() failures
by hyc＠symas.com 30 Aug '16

30 Aug '16

cissp(a)bryongloden.com wrote: > Full_Name: Bryon Gloden, CISSP. > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (161.133.194.55) > > > Greetings. On line numbers 123 and 134 of liblmdb/midl.c > (https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/midl.c) there > are two common realloc() mistakes. Passing one pointer into realloc() and > assigning the result directly into that same pointer variable can cause a memory > leak if the reallocation fails, because the original allocation will still > exist. The correct way to do this is to use a temporary pointer variable. > > Credit: http://stackoverflow.com/a/11548901 > > Found by https://github.com/bryongloden/cppcheck > > This is all false. On line number 123 we are shrinking the memory region - this will never fail. At worst it can only return the original pointer unchanged. On line number 134 we are leaving the original pointer unchanged on failure, it is not leaked. The caller can free it if it wants to. Closing this ITS. -- -- 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#8487) Properly handle realloc() failures
by cissp＠bryongloden.com 30 Aug '16

30 Aug '16

Full_Name: Bryon Gloden, CISSP. Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (161.133.194.55) Greetings. On line numbers 123 and 134 of liblmdb/midl.c (https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/midl.c) there are two common realloc() mistakes. Passing one pointer into realloc() and assigning the result directly into that same pointer variable can cause a memory leak if the reallocation fails, because the original allocation will still exist. The correct way to do this is to use a temporary pointer variable. Credit: http://stackoverflow.com/a/11548901 Found by https://github.com/bryongloden/cppcheck

1 0

(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

(ITS#8481) macOS shared libraries should be .dylib not .so
by ilovezfs＠icloud.com 19 Aug '16

19 Aug '16

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" ``` 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 ```

1 0

Re: (ITS#8480) running sample-mdb without ./testdb/
by hyc＠symas.com 17 Aug '16

17 Aug '16

gp.ciceri(a)gmail.com wrote: > Full_Name: gian paolo ciceri > Version: lmdb 0.9.18 > OS: OSX > URL: ftp://ftp.openldap/org/incoming > Submission from: (NULL) (5.170.1.95) > > > With lmdb (fresh git clone), if you run the standard sample-mdb.c example > program WITHOUT creating the ./testdb/ directory for the database before, you > take error 2 No such file or directory after the open. OK, but if you still > proceed to the begin the transaction, you take a segmentation fault 11: there's > what gdb says > There is no sample-mdb.c in a fresh git clone. There is a sample-mdb.txt. It is a text file, which you are expected to read, not run blindly. Closing this ITS. -- -- 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#8480) running sample-mdb without ./testdb/
by gp.ciceri＠gmail.com 17 Aug '16

17 Aug '16

Full_Name: gian paolo ciceri Version: lmdb 0.9.18 OS: OSX URL: ftp://ftp.openldap/org/incoming Submission from: (NULL) (5.170.1.95) With lmdb (fresh git clone), if you run the standard sample-mdb.c example program WITHOUT creating the ./testdb/ directory for the database before, you take error 2 No such file or directory after the open. OK, but if you still proceed to the begin the transaction, you take a segmentation fault 11: there's what gdb says sample-mdb Program received signal SIGSEGV, Segmentation fault. 0x0000000100001443 in mdb_txn_renew0 (txn=0x0) at ../mdb.c:2619 2619 MDB_env *env =xtxn->mt_env; Of course there is NO reason to begin the tnx if the open fails, but should not be better to trap this situation and comply instead of proceed and generate the segfault? Perhaps you suppose the program knows what is doing, but I (as programmer) am less sure of myself. Best regards, thanks for your attention. /gp

1 0

(ITS#8479) overlay unique + mdb: loop and OOM kill, 2 URS as olcUniqueURI value
by william.b.clay＠acm.org 15 Aug '16

15 Aug '16

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.15.115.130) The below modification to an otherwise correctly-functioning slapd instance provokes an infinite loop that eventually ends with allocation of all configured virtual memory, kernel invocation of its oom-killer (generally on an innocent bystander), and sometimes a kernel panic. This scenario is 100% repeatable on this installation. If I understand "man 5 slapo-unique" correctly, an instance of overlay unique may specify more than one olcUniqueURI attribute, each of which may specify more than one space-separated (?) URI. In this case, I am replacing two initially-configured olcUniqueURI attributes whose values comprise a single URI each (and which seem to work correctly) by one olcUniqueURI attribute with two URIs. bill@fuji:~$ sudo ldapmodify -YEXTERNAL -Hldapi:// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:olcOverlay={2}unique,olcDatabase={3}mdb,cn=config changetype: modify replace: olcUniqueURI olcUniqueURI: ldap:///ou=gruppi,dc=test?gidNumber?one ldap:///ou=gruppi,dc=test?owner?one modifying entry "olcOverlay={2}unique,olcDatabase={3}mdb,cn=config" ldap_result: Can't contact LDAP server (-1) bill@fuji:~$ This slapd is the following custom build on an otherwise fairly stock Debian Wheezy system. cd /usr/local/src/openldap-2.4.44 ./configure --sysconfdir=/etc --localstatedir=/ \ --disable-backends --enable-mdb --enable-monitor --enable-crypt \ --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-local \ --disable-overlays --enable-memberof --enable-refint --enable-unique \ --disable-modules --with-cyrus-sasl --with-tls --with-threads --with-gnu-ld # if --enable-shell, avoid --with threads I have uploaded files bill-clay-160815-<type>.txt to ftp://ftp.openldap.org/incoming/ for the following <types>: log: console log of slapd running foreground with -d1 (serial console at 57600 bps, allowing prompt manual termination via kill -KILL) cnf1-cnf3: slapadd specification of (1) the rootDSE, (2) {2}mdb's tree dc=epici,dc=it, and (3) {3}mdb's tree dc=test (subject of the failed ldapmodify). As is probably obvious from these files, I am an LDAP newbie, so there may be a configuration error here that's painfully obvious to the experienced practictioner.

1 0

Re: (ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by hyc＠symas.com 12 Aug '16

12 Aug '16

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.42 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.247.10.144) > > > When configuring syncrepl using slapd.d on a slave, if the replicator user does > not exist beforehand, replication won't catch with entries that were updated > prior the creation of the replicator user on the slave. OTOH, if we create this > replicator user *before* setting the replication configuration on the slave, > every updated entries on the master are replicated, even those created before > the configuration modification. Please provide a sample config that demonstrates the issue. -- -- 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#8478)
by elecharny＠gmail.com 12 Aug '16

12 Aug '16

IMO, it's a different issue. Ther ei no timing issue, it's reproductible in any case. FTR, I tested it on 2.4.44 (even if the original issue was seen on 2.4.42) The key here is really to create the replicator user before or after configuring syncrepl on the slave : if the user is created first, then all the entries get replicated from the master, and if teh user is created after the syncrepl configuration, no entry older than the moment the replicator user is added are read from the master.

1 0

Re: (ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by quanah＠zimbra.com 12 Aug '16

12 Aug '16

--On Friday, August 12, 2016 4:42 PM +0000 elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.42 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.247.10.144) > > > When configuring syncrepl using slapd.d on a slave, if the replicator > user does not exist beforehand, replication won't catch with entries that > were updated prior the creation of the replicator user on the slave. > OTOH, if we create this replicator user *before* setting the replication > configuration on the slave, every updated entries on the master are > replicated, even those created before the configuration modification. Is this any different from ITS#8281, ITS#8365? It sounds quite similar. Have you tested on a current release, which is general best practices before filing an ITS? --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by elecharny＠apache.org 12 Aug '16

12 Aug '16

Full_Name: Emmanuel L.charny Version: 2.4.42 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.247.10.144) When configuring syncrepl using slapd.d on a slave, if the replicator user does not exist beforehand, replication won't catch with entries that were updated prior the creation of the replicator user on the slave. OTOH, if we create this replicator user *before* setting the replication configuration on the slave, every updated entries on the master are replicated, even those created before the configuration modification.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by demiobenour＠gmail.com 11 Aug '16

11 Aug '16

On Wed, 2016-08-10 at 21:13 +0100, Howard Chu wrote: > demiobenour(a)gmail.com wrote: > > > > Full_Name: Demi Obenour > > Version: N/A > > OS: N/A > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (2601:840:8100:6720:2ae3:47ff:fe02:d99e) > > > > > > OpenLDAP.org has an expired self-signed TLS certificate, > > This is intentional. > > > > > which makes it > > impossible to securely access the Git repositories over HTTPS. > > The repos are only intended to be used via git: and http: anyway. > > This needs to be > > > > fixed to avoid man-in-the-middle attacks, which would allow > > arbitrary code > > execution on the developer's machine. > > When I discussed this with Kurt, we decided to leave things as-is. > Replacing > an expired self-signed cert with a non-expired self-signed cert > wouldn't > change anything, you still need to set an explicit exception in your > client to > trust the cert. > Why are the repos only intended to be used via git: and http: ? Is there some reason? This makes them unusable for anyone who cares about security. In the past http:// and https:// used an old dumb protocol that was slow, but that has long since been fixed in Git. Also, why the self-signed certificate at all? Let's Encrypt is providing free certificates.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by michael＠stroeder.com 10 Aug '16

10 Aug '16

hyc(a)symas.com wrote: > When I discussed this with Kurt, we decided to leave things as-is. Replacing > an expired self-signed cert with a non-expired self-signed cert wouldn't > change anything, you still need to set an explicit exception in your client to > trust the cert. Hmm, but browsers will likely not allow adding an exception anymore in the near future. And e.g. using Let's Encrypt isn't that hard (even without installing the bloated standard client on the system). Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs