openldap-devel

openldap-devel@openldap.org

4 participants
1420 discussions

RE24 Testing call #1 (OpenLDAP 2.4.38)
by Quanah Gibson-Mount 14 Nov '13

14 Nov '13

Current RE24 is ready for testing for the 2.4.38 release. Thanks! --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 4

conflicting types for ‘slap_reparse_sync_cookie’
by Michael Ströder 02 Nov '13

02 Nov '13

HI! Building current git master 0645878d5dc4c08b7fd8d5bf39a166d74650f15b fails (see below). Ciao, Michael. make[3]: Entering directory `/usr/src/michael/openldap-git/master/openldap/servers/slapd/overlays' make[3]: Nothing to be done for `static'. make[3]: Leaving directory `/usr/src/michael/openldap-git/master/openldap/servers/slapd/overlays' cc -g -O0 -DSLAP_SCHEMA_EXPOSE -DSLAP_CONFIG_DELETE -I../../include -I. -I./slapi -I. -I../../include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -c -o ldapsync.o ldapsync.c In file included from ldapsync.c:26:0: slap.h:65:0: warning: "SLAP_CONFIG_DELETE" redefined [enabled by default] <command-line>:0:0: note: this is the location of the previous definition ldapsync.c:375:1: error: conflicting types for ‘slap_reparse_sync_cookie’ In file included from slap.h:3342:0, from ldapsync.c:26: proto-slap.h:1188:20: note: previous declaration of ‘slap_reparse_sync_cookie’ was here make[2]: *** [ldapsync.o] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap-git/master/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap-git/master/openldap/servers' make: *** [all-common] Error 1

2 1

Fix for slapo-unique: filter in unique_uri not evaluated
by Michael Ströder 01 Nov '13

01 Nov '13

HI! Is there a chance to get ITS#6825 (dup ITS#6917) ever fixed? Ciao, Michael.

1 0

RE24 Testing call #1 (OpenLDAP 2.4.37)
by Quanah Gibson-Mount 24 Oct '13

24 Oct '13

Current RE24 is ready for testing for the 2.4.37 release. Thanks! --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

3 3

Fwd: Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by Howard Chu 02 Oct '13

02 Oct '13

Fixing this will either require adding a bunch of ugly code, or changing the on-disk format again. Opinions? Currently the page in-use offsets mp_lower and mp_upper range from [PAGEHDRSZ to pagesize]. IMO this was a stupid choice, carried over from the original btree code. It should instead have ranged from [0 to pagesize-PAGEHDRSZ] and then we'd have no issue right now. Adjusting this would require only a few minor tweaks to the code, but would require a full dump/reload of existing databases. -------- Original Message -------- Subject: Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096. Date: Tue, 1 Oct 2013 07:16:11 GMT From: hyc(a)symas.com To: openldap-its(a)openldap.org sumantk2(a)linux.vnet.ibm.com wrote: > Full_Name: sumanth k > Version: 2.4.35 to any recent version with mdb support > OS: Linux - ppc64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.248.161.59) > > > The pagesize of Linux for x86 and s390x architecture is 4096. Whereas in Powerpc > <ppc64> , the pagesize is by default 65536. So when the pagesize is not equal to > 4096, the segmentation fault occurs. So tried to compile the powerpc64 kernel > with page size of 4096 and the problem disappears and runs smoothly. But by > default the powerpc64 architecture runs with 65536 pagesize . So there is some > problem in mdb_env_open2() function in mdb.c when the pagesize is not equal to > 4096. Thanks for the report. I believe you should be able to instead change the definition of MDB_PAGESIZE to 65536, instead of forcing your machine to use 4096 byte pages. There are other problems though; we use an unsigned short for page offsets. I'm not sure the assert that you tripped will succeed in this case. > > These are my observations : > > > Compiled the source with -O0 optimization . > /home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f > /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d > 0x4105 > > ./scripts/test000-rootdse: line 31: 19059 Aborted (core dumped) > $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 > > Core file : > bash-4.2# cat .gdbinit > b mdb_db_open > b mdb_env_open > b mdb_env_open2 > b mdb_txn_begin > b mdb_txn_renew0 > b mdb_dbi_open > b mdb_cursor_init > b mdb_cursor_set > b mdb_page_search > b mdb_page_get > b mdb_page_search_root > r -s0 -f /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h > ldap://localhost:9011/ -d 0x4105 > > > # Core was generated by `/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 > -f /home/openldap-2.4.36'. > Program terminated with signal 6, Aborted. > #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: debuginfo-install > cyrus-sasl-lib-2.1.26-8.mcp8_0.2.ppc64 cyrus-sasl-md5-2.1.26-8.mcp8_0.2.ppc64 > glibc-2.17-4.mcp8_0.6.ppc64 keyutils-libs-1.5.5-4.mcp8_0.2.ppc64 > krb5-libs-1.11.3-1.mcp8_0.2.ppc64 libcom_err-1.42.7-2.mcp8_0.1.ppc64 > libdb-5.3.21-8.mcp8_0.4.ppc64 libselinux-2.1.13-15.mcp8_0.3.ppc64 > nss-softokn-freebl-3.14.3-1.mcp8_0.2.ppc64 openssl-libs-1.0.1e-4.mcp8_0.1.ppc64 > pcre-8.32-7.mcp8_0.2.ppc64 zlib-1.2.7-10.mcp8_0.1.ppc64 > (gdb) where > #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 > #1 0x00001fffff7afb64 in .abort () from /lib64/libc.so.6 > #2 0x00001fffff7a455c in .__assert_fail_base () from /lib64/libc.so.6 > #3 0x00001fffff7a464c in .__assert_fail () from /lib64/libc.so.6 > #4 0x00000000101498cc in mdb_node_add (mc=0x3fffe89a7d40, indx=0, > key=0x3fffe89a7d20, data=0x3fffe89a7d30, pgno=0, flags=2) at > ./../../../libraries/liblmdb/mdb.c:6160 > #5 0x000000001014882c in mdb_cursor_put (mc=0x3fffe89a7d40, key=0x3fffe89a7d20, > data=0x3fffe89a7d30, flags=2) at ./../../../libraries/liblmdb/mdb.c:5877 > #6 0x00000000101516a8 in mdb_dbi_open (txn=0x1000f675980, name=0x1027b9c8 > "ad2i", flags=262152, dbi=0x1fffff0800a0) at > ./../../../libraries/liblmdb/mdb.c:7902 > #7 0x0000000010139cd4 in mdb_db_open (be=0x1000f4f83a0, cr=0x3fffe89a81c0) at > init.c:207 > #8 0x0000000010050e34 in backend_startup_one (be=0x1000f4f83a0, > cr=0x3fffe89a81c0) at backend.c:224 > #9 0x0000000010051588 in backend_startup (be=0x1000f4f83a0) at backend.c:325 > #10 0x0000000010089a7c in slap_startup (be=0x0) at init.c:219 > #11 0x000000001000a9c8 in main (argc=8, argv=0x3fffe89a8958) at main.c:991 > > > > Here is the error message : > > #/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f > /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d > 0x4105 > (...some messages...) > 524a2fe1 mdb_db_open: database "o=OpenLDAP Project,l=Internet": > dbenv_open(/home/openldap-2.4.36/tests/testrun/db.1.a). > slapd: ./../../../libraries/liblmdb/mdb.c:6160: mdb_node_add: Assertion > `mp->mp_pb.pb.pb_upper >= mp->mp_pb.pb.pb_lower' failed. < === fails in assert() > ; > Aborted (core dumped) > > > > Some of my observation : > > in this file libraries/liblmdb/mdb.c > in X86 : rc = mdb_cursor_set(&mc, &key, &data, MDB_SET, &exact); the value of > rc = MD_SUCCESS, but for ppc64 it is MDB_NOTFOUND. This is due to the fact that > md_root != 2 > > The value of md_root=2 for env->me_metas[1]->mm_dbs in X86 , but some huge value > in ppc64. The value of md_pad = 4096 in x86 and 65536 in ppc64 . > > in x86: > > Breakpoint 2, mdb_txn_begin (env=0x9c5050, parent=0x0, flags=0, > ret=0x7fffffffdf98) at ./../../../libraries/liblmdb/mdb.c:2219 > 2219 int rc, size, tsize = sizeof(MDB_txn); > (gdb) p env->me_metas[1]->mm_dbs > $1 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 1, md_branch_pages = 0, md_leaf_pages = 1, md_overflow_pages = 0, > md_entries = 4, md_root = 2}} > (gdb) p env->me_metas[0]->mm_dbs > $2 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, > md_entries = 0, md_root = 18446744073709551615}} > > > in ppc64: > > Breakpoint 2, mdb_txn_begin (env=0x10493ef0, parent=0x0, flags=0, > ret=0x3fffffffe590) at ./../../../libraries/liblmdb/mdb.c:2219 > 2219 int rc, size, tsize = sizeof(MDB_txn); > (gdb) p env->me_metas[0]->mm_dbs > $1 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, > md_entries = 0, md_root = 18446744073709551615}} > (gdb) p env->me_metas[1]->mm_dbs > $2 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, > md_entries = 0, md_root = 18446744073709551615}} > > > > > # From further investigation , the value of env->me_metas[1] is initialized in > mdb_env_open2() at : > > p = (MDB_page *)env->me_map; > env->me_metas[0] = METADATA(p); > env->me_metas[1] = (MDB_meta *)((char *)env->me_metas[0] + meta.mm_psize); > > Here the meta.mm_psize in ppc64 is 65536 , hence there is some problem.. If the > value of meta.mm_psize is 4096 , then everything works fine. > > > As i dont have deep knowledge in openldap ,some help is needed. > > Thank you, > Sumanth K > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

5 5

Re: mdb_drop in lmdb
by Howard Chu 14 Sep '13

14 Sep '13

Conrad Steenberg wrote: > [resending to the list, doesn't seem to have gotten through] > > Hi there, > > I'm in the process of creating a binding for lmdb for the Crack > language. So far everything works really well, except that I'm not sure > about the workings of mdb_drop() to clear all the items from a database. > > Is there an example usage somewhere that I can look at? The definitive example of how to use LMDB is OpenLDAP slapd back-mdb. mdb_drop is used in back-mdb/tools.c. You can also take a look at the dict_lmdb.c driver in Postfix 2.11 for another example. > Basically for an already open db handle inside an MDB_env I do > _tmpTxn = mdb_txn_begin(_env, NULL, 0) > mdb_drop(_tmpTxn, _dbi, 0) > mdb_txn_commit(_tmpTxn) > mdb_reader_check(_env) > > However, when the db is opened again with mdb_dbi_open() I sometimes get > MDB_BAD_RSLOT: Invalid reuse of reader locktable slot That seems a bit odd, mdb_dbi_open() cannot return MDB_BAD_RSLOT. > I'm sure I'm missing a step somewhere! Any ideas? Might help to see your actual code that causes this situation. > > Thanks! > Conrad > > > > -- -- 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

LMDB write performance on Linux
by Howard Chu 11 Sep '13

11 Sep '13

Quanah noted a few times in IRC that LMDB write performance was a lot slower after upgrading from Linux 2.6.x to 3.x. I've also observed some major slowdowns on an Ubuntu 3.5.0-23 kernel whenever the dirty page flusher is active. Apparently this is a known issue introduced in the 3.0 kernel series http://lwn.net/Articles/486311/ I'm told that this has been fixed as of Linux 3.10. Unfortunately our most recent round of benchmarks has all been run on our 3.5.0-23 system. The SLAMD results we obtained for LMDB Modify throughput (tested back in February this year) are only about 60% of the speed we expected. http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/01585.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

next release
by Howard Chu 09 Sep '13

09 Sep '13

A lot of my recent commits are actually intended for OpenLDAP 2.5. A few of the recent TLS-related changes added to the libldap API, so one way or another they will require a library version bump. The question is whether these changes should go into the next 2.4 release: channel binding support OpenSSL elliptic curve support logging tls version/cipher info It seems that given the heightened awareness of encryption matters due to recent revelations about NSA data gathering, it might be a good idea to include these in 2.4 as well. Any opinions? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 5

EC_KEY undefined in master (was: openldap.git branch master updated)
by Hallvard Breien Furuseth 08 Sep '13

08 Sep '13

openldap-commit2devel(a)OpenLDAP.org writes: > commit e631ce808ed56119e61321463d06db7999ba5a08 > Author: Howard Chu <hyc(a)openldap.org> > Date: Sat Sep 7 09:47:19 2013 -0700 > > ITS#7595 Add Elliptic Curve support for OpenSSL tls_o.c:326: error: 'EC_KEY' undeclared. /usr/include/openssl/ssl.h has #define SSL_OP_SINGLE_ECDH_USE 0x00080000L. "grep -w EC_KEY /usr/include/openssl/*.h" finds nothing. OPENSSL_VERSION_NUMBER = 0x10000003L. -- Hallvard

2 1

Re: openldap.git branch master updated. 34f832faee9f215dfdb61de52506f2905258b147
by Quanah Gibson-Mount 17 Aug '13

17 Aug '13

--On Saturday, August 17, 2013 2:06 AM +0000 openldap-commit2devel(a)OpenLDAP.org wrote: > commit f230503b108b1c1fd2dec072b0ad5d6785da4968 > Author: Howard Chu <hyc(a)openldap.org> > Date: Fri Aug 16 18:56:31 2013 -0700 > > Tweak mutex acquisition The mutex block around the CSN bits here was to fix ITS#5709. Are we sure moving it further down won't resurrect 5709? --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel