openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

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

19 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 19 Aug '16

19 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

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