- openldap-bugs - openldap.org

Re: (ITS#8328) Information leak in slapo-auditlog
by hyc＠symas.com 03 Dec '15

03 Dec '15

moritz(a)wikimedia.org wrote: > Full_Name: Moritz M.hlenhoff > Version: 2.4.40 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.96.145.189) > > > I setup a test system which made use of the slapo-auditlog overlay using these > config options: > > moduleload auditlog > overlay auditlog > auditlog /var/lib/ldap/slapd-audit.log > > The /var/lib/ldap/slapd-audit.log was created with world-readable permissions, > which constitutes a security issue since that file also logs sensitive > attributes which are otherwise protected by ACLs (such as password hashes). > > > Proposed patch: > > diff -aur openldap-2.4.40+dfsg.orig/servers/slapd/overlays/auditlog.c > openldap-2.4.40+dfsg/rvrvers/slapd/overlays/auditlog.c > --- openldap-2.4.40+dfsg.orig/servers/slapd/overlays/auditlog.c 2014-09-19 > 01:48:49.000000000 +0000 > +++ openldap-2.4.40+dfsg/servers/slapd/overlays/auditlog.c 2015-12-02 > 11:08:24.331146770 +0000 > @@ -121,6 121,7 @@ > > peername = op->o_conn->c_peer_name; > ldap_pvt_thread_mutex_lock(&ad->ad_mutex); > + umask(027); > if((f = fopen(ad->ad_logfile, "a")) == NULL) { > ldap_pvt_thread_mutex_unlock(&ad->ad_mutex); > return SLAP_CB_CONTINUE; > > > The patch is unacceptable, umask() is process-wide and persistent. No slapd code should be overriding any umask that may have been set when slapd was launched. The correct fix for this is to set the desired umask in whatever startup script you use to start slapd. 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

Re: (ITS#8330) Fix robust mutex detection for glibc 2.10 and 2.11
by hyc＠symas.com 03 Dec '15

03 Dec '15

sebastien(a)slaunay.fr wrote: > Full_Name: Sebastien Launay > Version: LMDB 0.9.17 > OS: Ubuntu 10.04.4 LTS x86_64 > URL: https://gist.githubusercontent.com/slaunay/3252415fad66d641e5b1/raw/356a57a… > Submission from: (NULL) (104.36.15.110) > > > I am having trouble compiling version 0.9.17 as well as the master branch of > LMDB with Ubuntu Lucid. > > When compiling the project under Ubuntu Lucid x86_64 (glibc 2.11), I get the > following errors: Thanks, fixed in git mdb.master > The exact version of the glibc is the following: > > $ ldd --version > ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.21) 2.11.1 > Copyright (C) 2009 Free Stwtware Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > Written by Roland McGrath and Ulrich Drepper. > $ lsb_release -a > No LSB modules are available. > Distribut I ID: Ubuntu > Description: Ubuntu 10.04.4 LTS > Release: 10.04 > Codename: lucid > > I noticed that pthread_mutexattr_setrobust and pthread_mutex_consistent are > provided since 2.12 not 2.10: > https://github.molgen.mpg.de/git-mirror/glibc/commit/402cd98775db1478f64c9b… > https://github.molgen.mpg.de/git-mirror/glibc/commit/78ee21859939ff75ccf8bb… > > After applying the provided fix against master (see attached patch URL), the > compilation and runtime are working properly. > > -- -- 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#8329) id_query config in the back_sql module
by hyc＠symas.com 03 Dec '15

03 Dec '15

paterry(a)gmx.com wrote: > Full_Name: Paul Terry > Version: 2.4.43 > OS: Red Hat Enterprise Server 6.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.91.5.16) > > > If the following line is in slapd.conf for the back_sql.la module: > > id_query "SELECT id, keyval, oc_map_id, dn FROM ldap_entries WHERE pusername = > ?" > > Then slapd will not start and logs the following error: > > Nov 30 12:00:59 testbrazilldap01 slapd[24111]: /etc/openldap/slapd.conf: line > 36: unknown directive <id_query> inside backend database definition. > > This worked correctly in version 2.4.23. > > After looking through the code, the 'id_query' configuration appears to be > missing from servers/slapd/back-sql/config.c, while it was present in that file > for version 2.4.23. > > I've sent a patch for config.c named paul-terry-151203.patch > > Thanks for the patch. It's incomplete though, the olcSqlIdQuery attribute also needs to be added to the config objectclass. -- -- 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#8330) Fix robust mutex detection for glibc 2.10 and 2.11
by sebastien＠slaunay.fr 03 Dec '15

03 Dec '15

Full_Name: Sebastien Launay Version: LMDB 0.9.17 OS: Ubuntu 10.04.4 LTS x86_64 URL: https://gist.githubusercontent.com/slaunay/3252415fad66d641e5b1/raw/356a57a… Submission from: (NULL) (104.36.15.110) I am having trouble compiling version 0.9.17 as well as the master branch of LMDB with Ubuntu Lucid. When compiling the project under Ubuntu Lucid x86_64 (glibc 2.11), I get the following errors: $ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c: In function 'mdb_mutex_failed': mdb.c:10137: warning: implicit declaration of function 'pthread_mutex_consistent' gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c midl.c ar rs liblmdb.a mdb.o midl.o ar: creating liblmdb.a gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c mdb.c -o mdb.lo mdb.c: In function 'mdb_mutex_failed': mdb.c:10137: warning: implicit declaration of function 'pthread_mutex_consistent' gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -fPIC -c midl.c -o midl.lo gcc -pthread -shared -o liblmdb.so mdb.lo midl.lo gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb_stat.c gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat liblmdb.a(mdb.o): In function `mdb_mutex_failed': /home/vagrant/lmdb/libraries/liblmdb/mdb.c:10137: undefined reference to `pthread_mutex_consistent' liblmdb.a(mdb.o): In function `mdb_env_setup_locks': /home/vagrant/lmdb/libraries/liblmdb/mdb.c:4752: undefinerereference to `pthread_mutexattr_setrobust' collect2: ld returned 1 exit status make: *** [mdb_stat] Error 1 The exact version of the glibc is the following: $ ldd --version ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.21) 2.11.1 Copyright (C) 2009 Free Stwtware Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. $ lsb_release -a No LSB modules are available. Distribut I ID: Ubuntu Description: Ubuntu 10.04.4 LTS Release: 10.04 Codename: lucid I noticed that pthread_mutexattr_setrobust and pthread_mutex_consistent are provided since 2.12 not 2.10: https://github.molgen.mpg.de/git-mirror/glibc/commit/402cd98775db1478f64c9b… https://github.molgen.mpg.de/git-mirror/glibc/commit/78ee21859939ff75ccf8bb… After applying the provided fix against master (see attached patch URL), the compilation and runtime are working properly.

1 0

Re: (ITS#8329) id_query config in the back_sql module
by quanah＠zimbra.com 03 Dec '15

03 Dec '15

--On Thursday, December 03, 2015 5:57 PM +0000 paterry(a)gmx.com wrote: > Full_Name: Paul Terry > Version: 2.4.43 > OS: Red Hat Enterprise Server 6.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.91.5.16) > > > If the following line is in slapd.conf for the back_sql.la module: > > id_query "SELECT id, keyval, oc_map_id, dn FROM ldap_entries WHERE > pusername = ?" > > Then slapd will not start and logs the following error: > > Nov 30 12:00:59 testbrazilldap01 slapd[24111]: /etc/openldap/slapd.conf: > line 36: unknown directive <id_query> inside backend database definition. > > This worked correctly in version 2.4.23. > > After looking through the code, the 'id_query' configuration appears to be > missing from servers/slapd/back-sql/config.c, while it was present in > that file for version 2.4.23. > > I've sent a patch for config.c named paul-terry-151203.patch > Broken in 6d57371903bccab23eaf7b909136d9e7a7e1ec81 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8329) id_query config in the back_sql module
by paterry＠gmx.com 03 Dec '15

03 Dec '15

Full_Name: Paul Terry Version: 2.4.43 OS: Red Hat Enterprise Server 6.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.91.5.16) If the following line is in slapd.conf for the back_sql.la module: id_query "SELECT id, keyval, oc_map_id, dn FROM ldap_entries WHERE pusername = ?" Then slapd will not start and logs the following error: Nov 30 12:00:59 testbrazilldap01 slapd[24111]: /etc/openldap/slapd.conf: line 36: unknown directive <id_query> inside backend database definition. This worked correctly in version 2.4.23. After looking through the code, the 'id_query' configuration appears to be missing from servers/slapd/back-sql/config.c, while it was present in that file for version 2.4.23. I've sent a patch for config.c named paul-terry-151203.patch

1 0

(ITS#8328) Information leak in slapo-auditlog
by moritz＠wikimedia.org 03 Dec '15

03 Dec '15

Full_Name: Moritz M.hlenhoff Version: 2.4.40 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.96.145.189) I setup a test system which made use of the slapo-auditlog overlay using these config options: moduleload auditlog overlay auditlog auditlog /var/lib/ldap/slapd-audit.log The /var/lib/ldap/slapd-audit.log was created with world-readable permissions, which constitutes a security issue since that file also logs sensitive attributes which are otherwise protected by ACLs (such as password hashes). Proposed patch: diff -aur openldap-2.4.40+dfsg.orig/servers/slapd/overlays/auditlog.c openldap-2.4.40+dfsg/rvrvers/slapd/overlays/auditlog.c --- openldap-2.4.40+dfsg.orig/servers/slapd/overlays/auditlog.c 2014-09-19 01:48:49.000000000 +0000 +++ openldap-2.4.40+dfsg/servers/slapd/overlays/auditlog.c 2015-12-02 11:08:24.331146770 +0000 @@ -121,6 121,7 @@ peername = op->o_conn->c_peer_name; ldap_pvt_thread_mutex_lock(&ad->ad_mutex); + umask(027); if((f = fopen(ad->ad_logfile, "a")) == NULL) { ldap_pvt_thread_mutex_unlock(&ad->ad_mutex); return SLAP_CB_CONTINUE;

1 0

Re: (ITS#8327) The mod->sm_numvals values is checked and not seen as valid in mods.c
by elecharny＠gmail.com 03 Dec '15

03 Dec '15

The full stack trace that didn't get copied in the original ITS : #0 0x0000003a9b632625 in raise () from /lib64/libc.so.6 #1 0x0000003a9b633e05 in abort () from /lib64/libc.so.6 #2 0x0000003a9b62b74e in __assert_fail_base () from /lib64/libc.so.6 #3 0x0000003a9b62b810 in __assert_fail () from /lib64/libc.so.6 #4 0x000000000047efc8 in modify_add_values (e=0x7f7027ffdc90, mod=0x7f7018105560, permissive=0, text=0x7f7027ffe170, textbuf=0x7f7027ffdd00 "", textlen=256) at /home/build/sold-2.4.42.2/openldap/servers/slapd/mods.c:64 #5 0x00007f706e1909b9 in mdb_modify_internal (op=0x7f7027ffe1c0, tid=0x2685180, modlist=0x7f7018105560, e=0x7f7027ffdc90, text=0x7f7027ffe170, textbuf=0x7f7027ffdd00 "", textlen=256) at /home/build/sold-2.4.42.2/openldap/servers/slapd/back-mdb/modify.c:168 #6 0x00007f706e191a1c in mdb_modify (op=0x7f7027ffe1c0, rs=0x7f7027ffe150) at /home/build/sold-2.4.42.2/openldap/servers/slapd/back-mdb/modify.c:623 #7 0x00000000004945f0 in overlay_op_walk (op=0x7f7027ffe1c0, rs=0x7f7027ffe150, which=op_modify, oi=0x24fcef0, on=0xfefefefefefefeff) at /home/build/sold-2.4.42.2/openldap/servers/slapd/backover.c:677 #8 0x00000000004946a3 in over_op_func (op=0x7f7027ffe1c0, rs=0x7f7027ffe150, which=op_modify) at /home/build/sold-2.4.42.2/openldap/servers/slapd/backover.c:730 #9 0x00007f706df53a74 in ppolicy_bind_response (op=0x7f7018106040, rs=0x7f7027ffe9f0) at /home/build/sold-2.4.42.2/openldap/servers/slapd/overlays/ppolicy.c:1277 #10 0x000000000043d40c in slap_response_play (op=0x7f7018106040, rs=0x7f7027ffe9f0) at /home/build/sold-2.4.42.2/openldap/servers/slapd/result.c:521 #11 0x000000000043d83b in send_ldap_response (op=0x7f7018106040, rs=0x1da6) at /home/build/sold-2.4.42.2/openldap/servers/slapd/result.c:596 #12 0x000000000043ddd2 in slap_send_ldap_result (op=0x7f7018106040, rs=0x7f7027ffe9f0) at /home/build/sold-2.4.42.2/openldap/servers/slapd/result.c:891 #13 0x00007f706e18e9f1 in mdb_bind (op=0x7f7018106040, rs=0x7f7027ffe9f0) at /home/build/sold-2.4.42.2/openldap/servers/slapd/back-mdb/bind.c:150 #14 0x00000000004945f0 in overlay_op_walk (op=0x7f7018106040, rs=0x7f7027ffe9f0, which=op_bind, oi=0x24fcef0, on=0xfefefefefefefeff) at /home/build/sold-2.4.42.2/openldap/servers/slapd/backover.c:677 #15 0x00000000004946a3 in over_op_func (op=0x7f7018106040, rs=0x7f7027ffe9f0, which=op_bind) at /home/build/sold-2.4.42.2/openldap/servers/slapd/backover.c:730 #16 0x000000000044a769 in fe_op_bind (op=0x7f7018106040, rs=0x7f7027ffe9f0) at /home/build/sold-2.4.42.2/openldap/servers/slapd/bind.c:383 #17 0x0000000000449f51 in do_bind (op=0x7f7018106040, rs=0x7f7027ffe9f0) at /home/build/sold-2.4.42.2/openldap/servers/slapd/bind.c:205 #18 0x000000000042ecb6 in connection_operation (ctx=0x7f7027ffeb70, arg_v=0x7f7018106040) at /home/build/sold-2.4.42.2/openldap/servers/slapd/connection.c:1158 #19 0x000000000042f4b3 in connection_read_thread (ctx=0x7f7027ffeb70, argv=<value optimized out>) at /home/build/sold-2.4.42.2/openldap/servers/slapd/connection.c:1294 #20 0x00007f707002a7bc in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at /home/build/sold-2.4.42.2/openldap/libraries/libldap_r/tpool.c:956 #21 0x0000003a9ba07a51 in start_thread () from /lib64/libpthread.so.0 #22 0x0000003a9b6e896d in clone () from /lib64/libc.so.6

1 0

(ITS#8327) The mod->sm_numvals values is checked and not seen as valid in mods.c
by elecharny＠apache.org 03 Dec '15

03 Dec '15

Full_Name: Emmanuel Lecharny Version: 2.4.42 OS: Linux CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:cb04:49:8d00:e9fd:e874:85a8:1553) On an architecture with 2 servers replicated using delta-syncrepl (MMR), doing some modififications on one server might lead to a core dump, where the stack trace shows that the mod->sm_numvals value is not what is expcted in the modify_add_values value : ... if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) { unsigned i; for ( i = 0; !BER_BVISNULL( &mod->sm_values[i] ); i++ ); assert( mod->sm_numvals == i ); } ... Here, the assert fails. Here is the stacktrace : (gdb) bt #0 0x0000003a9b632625 in raise () from /lib64/libc.so.6 #1 0x0000003a9b633e05 in abort () from /lib64/libc.so.6 #2 0x0000003a9b62b74e in __assert_fail_base () from /lib64/libc.so.6 #3 0x0000003a9b62b810 in __assert_fail () from /lib64/libc.so.6

1 0

Re: (ITS#8325) Building Problems openLDAP 2.4.43 pthread_mutexattr_setrobust
by bernhard.pfeiffer33＠gmail.com 02 Dec '15

02 Dec '15

--001a11407ed8d5462d0525e599d1 Content-Type: text/plain; charset=UTF-8 Work-Around works perfectly! Thanks. Issue can be closed. Greets, Bernhard --001a11407ed8d5462d0525e599d1 Content-Type: text/html; charset=UTF-8 <div dir="ltr"><div><div><div><div>Work-Around works perfectly!<br><br></div>Thanks.<br><br></div>Issue can be closed.<br><br></div>Greets,<br></div>Bernhard<br></div> --001a11407ed8d5462d0525e599d1--

1 0

Re: (ITS#8325) Building Problems openLDAP 2.4.43 pthread_mutexattr_setrobust
by hyc＠symas.com 01 Dec '15

01 Dec '15

bernhard.pfeiffer33(a)gmail.com wrote: > Full_Name: Bernhard Pfeiffer > Version: openLDAP 2.4.43 > OS: SUSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.158.227.32) > > > Since the new version i get building problems under SUSE11: Unfortunate. Read liblmdb/mdb.c around lines 241 onward. Either the glibc version detection is wrong, or your system just has a weirdly patched glibc. You can either try to fix the version detection, or just compile with -DMDB_USE_ROBUST=0 to bypass this. > cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o > search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o > operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o > bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o > init.o user.o lock.o controls.o extended.o passwd.o schema.o schema_check.o > schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o > saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o > module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o > matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o > frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o > slaptest.o slapauth.o slapacl.o component.o aci.o alock.o txn.o slapschema.o > version.o -pthread -L/products/db-5.2.42/lib -L/products/openssl-1.0.2d/lib > libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a > ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a > ../../libraries/libldap_r/.libs/libldap_r.a > /data0/install/openLDAP_v2/openldap-2.4.43/libraries/liblber/.libs/liblber.a > ../../libraries/liblber/.libs/liblber.a /products/db-5.2.42/lib/libdb-5.2.so > -lpthread -lssl -lcrypto -lresolv -pthread -Wl,--rpath > -Wl,/products/db-5.2.42/lib -Wl,--rpath -Wl,/products/openssl-1.0.2d/lib > daemon.o: In function `alap_listener': > /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/daemon.c:1873: warning: > `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead > /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/daemon.c:1873: warning: > `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead > libbackends.a(mdbmdb.o): In function `mdb_mutex_failed': > /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/back-mdb/./../../../libraries/liblmdb/mdb.c:9977: > undefined reference to `pthread_mutex_consistent' > libbackends.a(mdbmdb.o): In function `mdb_env_setup_locks': > /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/back-mdb/./../../../libraries/liblmdb/mdb.c:4620: > undefined reference to `pthread_mutexattr_setrobust' > collect2: ld returned 1 exit status > make[2]: *** [slapd] Error 1 > make[2]: Leaving directory > `/data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/data0/install/openLDAP_v2/openldap-2.4.43/servers' > make: *** [all-common] Error 1 > > > -- -- 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#8326) failure to start due to pwdMaxRecordedFailure
by afrunning＠gmail.com 01 Dec '15

01 Dec '15

> > You need to replace your ppolicy.schema/ppolicy.ldif from 2.4.42 with the > one bundled in 2.4.43. Yep - that was it. Thanks. Sorry for the noise. Al

1 0

Re: (ITS#8326) failure to start due to pwdMaxRecordedFailure
by hyc＠symas.com 01 Dec '15

01 Dec '15

afrunning(a)gmail.com wrote: > Full_Name: Al F > Version: 2.4.43 > OS: Redhat 6.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.123.146.10) > > > Hi, > > I just attepted to upgrade my development environment from 2.4.42 to 43, but > unfortunately the service won't start. The following is in my logs: > > Dec 1 08:44:45 myserver slapd[5698]: @(#) $OpenLDAP: slapd 2.4.43 (Dec 1 2015 > 08:19:43) $#012#011root@myserver:/root/openldap-2.4.43/servers/slapd > Dec 1 08:44:45 myserver slapd[5698]: User Schema load failed for attribute > "pwdMaxRecordedFailure". Error code 17: attribute type undefined > Dec 1 08:44:45 myserver slapd[9698]: config error processing > olcOverlay={2}ppolicy,olcDatabase={1}mdb,cn=config: User Schema load failed for > attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined > > I do not have any pwdMaxRecordedFailure attributes in my ppolicy objects - which > I'm assuming is the issue. I rely on the defaults. > > Let me know what else I can do to help. You need to replace your ppolicy.schema/ppolicy.ldif from 2.4.42 with the one bundled in 2.4.43. -- -- 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#8326) failure to start due to pwdMaxRecordedFailure
by afrunning＠gmail.com 01 Dec '15

01 Dec '15

Full_Name: Al F Version: 2.4.43 OS: Redhat 6.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.123.146.10) Hi, I just attepted to upgrade my development environment from 2.4.42 to 43, but unfortunately the service won't start. The following is in my logs: Dec 1 08:44:45 myserver slapd[5698]: @(#) $OpenLDAP: slapd 2.4.43 (Dec 1 2015 08:19:43) $#012#011root@myserver:/root/openldap-2.4.43/servers/slapd Dec 1 08:44:45 myserver slapd[5698]: User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined Dec 1 08:44:45 myserver slapd[9698]: config error processing olcOverlay={2}ppolicy,olcDatabase={1}mdb,cn=config: User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined I do not have any pwdMaxRecordedFailure attributes in my ppolicy objects - which I'm assuming is the issue. I rely on the defaults. Let me know what else I can do to help. Regards, Al

1 0

(ITS#8325) Building Problems openLDAP 2.4.43 pthread_mutexattr_setrobust
by bernhard.pfeiffer33＠gmail.com 01 Dec '15

01 Dec '15

Full_Name: Bernhard Pfeiffer Version: openLDAP 2.4.43 OS: SUSE 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.158.227.32) Since the new version i get building problems under SUSE11: cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o alock.o txn.o slapschema.o version.o -pthread -L/products/db-5.2.42/lib -L/products/openssl-1.0.2d/lib libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.a /data0/install/openLDAP_v2/openldap-2.4.43/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a /products/db-5.2.42/lib/libdb-5.2.so -lpthread -lssl -lcrypto -lresolv -pthread -Wl,--rpath -Wl,/products/db-5.2.42/lib -Wl,--rpath -Wl,/products/openssl-1.0.2d/lib daemon.o: In function `alap_listener': /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/daemon.c:1873: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/daemon.c:1873: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead libbackends.a(mdbmdb.o): In function `mdb_mutex_failed': /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/back-mdb/./../../../libraries/liblmdb/mdb.c:9977: undefined reference to `pthread_mutex_consistent' libbackends.a(mdbmdb.o): In function `mdb_env_setup_locks': /data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd/back-mdb/./../../../libraries/liblmdb/mdb.c:4620: undefined reference to `pthread_mutexattr_setrobust' collect2: ld returned 1 exit status make[2]: *** [slapd] Error 1 make[2]: Leaving directory `/data0/install/openLDAP_v2/openldap-2.4.43/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/data0/install/openLDAP_v2/openldap-2.4.43/servers' make: *** [all-common] Error 1

1 0

(ITS#8324) LMDB - grow file incrementally on Windows
by hyc＠openldap.org 30 Nov '15

30 Nov '15

Full_Name: Howard Chu Version: LMDB 0.9.17 OS: Win32 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.236.172) Submitted by: hyc Currently LMDB uses the WIN32 API to setup the memory-mapped DB file, which requires that the file size is equal to the map size. If we use the native NT API instead it's possible to grow the file incrementally, which will reduce the number of complaints we get from Windows users who think their disk space is getting eaten up for no reason. There is probably a performance reduction from taking this approach, but I haven't benchmarked it and have no plans to. I frankly don't care and no one is paying me to care.

1 0

(ITS#8323) LMDB nested txn bugs
by hyc＠openldap.org 24 Nov '15

24 Nov '15

Full_Name: Howard Chu Version: LMDB 0.9.16 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.230.13) Submitted by: hyc When committing a child transaction, the merge of the child's dirty pages must remove the child's spilled pages from the merge.

1 0

(ITS#8322) mdb_env_set_mapsize default size mismatch
by bernard＠zeroc.com 23 Nov '15

23 Nov '15

Full_Name: Bernard Normier Version: lmdb latest OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.241.237.165) lmdb.h, used by Doxygen, documents a default size of 10MB: > * The size should be a multiple of the OS page size. The default is > * 10485760 bytes. The size of the memory map is also the maximum size while mdb.c uses a default size of 1MB: > #define DEFAULT_MAPSIZE 1048576

1 0

Re: (ITS#8320) [PATCH] mdb_load: fix loading data from simple text files
by hyc＠symas.com 23 Nov '15

23 Nov '15

orivej(a)gmx.fr wrote: > Full_Name: Orivej Desh > Version: > OS: > URL: https://github.com/orivej/openldap/commit/326faf4da40bc42c3b6a8431f761815a5… > Submission from: (NULL) (31.220.42.127) > > > mdb_load -T was supposed to read escaped text, but 21b51cb7 "Add mdb_load" > made it read hex. > > This patch is free and unencumbered software released into the public domain. Thanks, added to git. -- -- 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#8319) [PATCH] mdb_load: explain readline and mdb_cursor_put errors
by hyc＠symas.com 23 Nov '15

23 Nov '15

orivej(a)gmx.fr wrote: > Full_Name: Orivej Desh > Version: > OS: > URL: https://github.com/orivej/openldap/commit/338f038f10c6d77288135204df8a94cbe… > Submission from: (NULL) (31.220.42.127) > > > This patch adds printing of error messages where previously mdb_load would exit > silently. > > This patch is free and unencumbered software released into the public domain. > > Thanks, added to git. -- -- 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#8321) LMDB cursor fixup bugs
by hyc＠openldap.org 23 Nov '15

23 Nov '15

Full_Name: Howard Chu Version: 2.4.42 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.230.13) Submitted by: hyc Multiple bugs were fixed in the cursor fixups which adjust other open cursors in response to various write ops. Patches will be merged shortly.

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by ondra＠mistotebe.net 22 Nov '15

22 Nov '15

On Tue, Oct 27, 2015 at 09:50:10AM +0000, michael(a)stroeder.com wrote: > Strange: testrun/test.out has zero bytes. :-/ > But the DB files are created. > > Other tests with -b hdb seem to work ok. > Maybe it's just the test script? I've let slapmodify honour logging settings in branch ITS8291 at https://github.com/mistotebe/openldap, could you paste the output of test.out with that enabled and possibly loglevel set to -1? Thanks, Ondrej

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by ondra＠mistotebe.net 22 Nov '15

22 Nov '15

On Tue, Jul 22, 2014 at 07:38:26PM +0000, michael(a)stroeder.com wrote: > Would be nice if this gets ever fixed to match the RFC. Hi, can you test the changes in branch ITS7100 at https://github.com/mistotebe/openldap? Thanks, Ondrej

1 0

(ITS#8320) [PATCH] mdb_load: fix loading data from simple text files
by orivej＠gmx.fr 22 Nov '15

22 Nov '15

Full_Name: Orivej Desh Version: OS: URL: https://github.com/orivej/openldap/commit/326faf4da40bc42c3b6a8431f761815a5… Submission from: (NULL) (31.220.42.127) mdb_load -T was supposed to read escaped text, but 21b51cb7 "Add mdb_load" made it read hex. This patch is free and unencumbered software released into the public domain.

1 0

(ITS#8319) [PATCH] mdb_load: explain readline and mdb_cursor_put errors
by orivej＠gmx.fr 22 Nov '15

22 Nov '15

Full_Name: Orivej Desh Version: OS: URL: https://github.com/orivej/openldap/commit/338f038f10c6d77288135204df8a94cbe… Submission from: (NULL) (31.220.42.127) This patch adds printing of error messages where previously mdb_load would exit silently. This patch is free and unencumbered software released into the public domain.

1 0

Re: (ITS#8317) Problem with "force user to password reset at first login"
by quanah＠zimbra.com 20 Nov '15

20 Nov '15

--On Friday, November 20, 2015 7:18 AM +0000 rajagopal.rc(a)tcs.com wrote: > Please help me configure the option to force all users to change their > password at first login or after pwd reset by administrator. The ITS system is for bug reports, not usage questions. Usage questions should be directed to the openldap-technical(a)openldap.org mailing list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8318) Add RECNUM support in LMDB
by lkrispen＠redhat.com 20 Nov '15

20 Nov '15

Full_Name: Ludwig Krispenz Version: 2.4.5 OS: Fedora22 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.203.101.97) In BDB the btree databases did also allow RECNUM access, allowing to access and cursor through the btree. LMDB does not include this feature, but for migrating existing deployments from BDB to LMDB this would be helpful. Discussing this with Howard Chu at LDAPCone susuggested to create this issue to get the request evaluated and implemented

1 0

(ITS#8317) Problem with "force user to password reset at first login"
by rajagopal.rc＠tcs.com 20 Nov '15

20 Nov '15

Full_Name: Rajagopal Version: openldap-2.4.39-7.el7_1.x86_64 OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.242.29.87) Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Rajagopal

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 hyc＠symas.com 20 Nov '15

20 Nov '15

oskari.timperi(a)iki.fi wrote: > Full_Name: Oskari Timperi > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/oskari-timperi-141205.zip > Submission from: (NULL) (109.204.204.106) > > > The patches make some changes so that compiling lmdb when UNICODE is defined is > possible. This is achieved by using the A-versions of WinApi functions where > they are needed. Thanks, this part of the patch was done in merging ITS#8069. > > Also use CreateFileW to open files so that one can use exotic characters in > paths. The library interface is not modified, but the code makes an assumption > that paths passed to lmdb functions are encoded as UTF-8. The UTF-8 encoded > paths are encoded to UTF-16 which is then passed to CreateFileW. This patch is now in git mdb.master. -- -- 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#8316) Broken cursor after mdb_cursor_del()
by h.b.furuseth＠usit.uio.no 19 Nov '15

19 Nov '15

Full_Name: Hallvard B Furuseth Version: mdb.master, a98b74e6df6fdb9dbc29d44fe2879f96191d8904 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151119.c Submission from: (NULL) (2001:700:100:202::105) Submitted by: hallvard The test program does not find V(4) with the cursor which did mdb_cursor_del(). It does find it with the unused cursor. Broken by fca18d2586259c0e802d "ITS#7829 more for prev commit".

1 0

(ITS#8315) assert in commit(nested txn)
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

Full_Name: Hallvard B Furuseth Version: mdb.master, f08b70d0df323ccb33b94a648e9a1b6efd718cae OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151118-3.c Submission from: (NULL) (81.191.45.31) Submitted by: hallvard commit(nested txn) will sometimes hit mdb.c:3528:mdb_tassert(txn, i == x). A fix is to drop the optimization /* Simplify the above for single-ancestor case */ and always use the "if (parent->mt_parent)" branch. Don't know yet if that just hides the symptom though. To reproduce: gcc -pthread -g -I. Hallvard-Furuseth-151118-3.c rm -f testdb/*; ./a.out -r313873253

1 0

Re: (ITS#8313) crash in mdb_rebalance(): uninited cursor flags
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

On 18. nov. 2015 12:07, h.b.furuseth(a)usit.uio.no wrote: > The test program can crash dereferencing mp==NULL at > mdb_cursor_del0() line 8244 "nkeys = NUMKEYS(mp);" Broken by 8bdadf68c580 "ITS#8258 fix rebalance/split". (It broke differently in LMDB 0.9.16. Assertion NUMKEYS(mp)>1, fixed by d84fae3fe31c "ITS#8237 fix ITS#7589 regression".) -- Hallvard

1 0

Re: (ITS#8312) LMDB corruption, perhaps in freelist code
by martin＠bzero.se 18 Nov '15

18 Nov '15

On 2015-11-18 16:32, Hallvard Breien Furuseth wrote: > On 18. nov. 2015 11:51, martin(a)bzero.se wrote: >> Please find linked a test program (replay.c) that consistently fails on >> my centos 7 system. It parses captured commands from a text file. > > Fixed in mdb.master. Please test. Thanks, this resolves my issues.

1 0

Re: (ITS#8312) LMDB corruption, perhaps in freelist code
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

On 18. nov. 2015 11:51, martin(a)bzero.se wrote: > Please find linked a test program (replay.c) that consistently fails on > my centos 7 system. It parses captured commands from a text file. Fixed in mdb.master. Please test. -- Hallvard

1 0

(ITS#8314) ldap_back_is_proxy_authz returned 0 - misconfigured uri? - Maybe a Bug?
by dominique.voest＠neclab.eu 18 Nov '15

18 Nov '15

Full_Name: Dominique V.st Version: 2.4.40 OS: Debian,CentOS,BSDs URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.37.70.39) Hi everyone, I installed a new OpenLDAP Server (Debian Jessy) (OpenLDAP Version 2.4.40) which is used to proxy parts of the Active Directory. However, from time to time it is not able to get Entries (does not answer to querys but returns success) from the Active Directory. What I see in the logs is the following: Jun 10 11:37:38 openldap-proxy slapd[41657]: conn=1166 op=1 ldap_back_retry: retrying URI="ldaps://dc.ourdomain.com" DN="cn=ldap-binder,ou=serviceaccounts,dc= ourdomain,dc=com" Jun 10 11:37:38 openldap-proxy slapd[41657]: Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? First of all, the URI is correct and the System works well during most of the time(except for this error), those errors only happen from time to time. The Strange thing is, that this new LDAP Server is running via the exactly same configuration as another OpenLDAP-Server which has been running over 2 Years now and the old OpenLDAP Server (Debian Wheezy) (OpenLDAP Version 2.4.31) does also show the first Log Entry from time to time (the ldap_back_retry one), But does not show the ldap_back_is_proxy_authz error afterwards. Furthermore it does also always return the right answer. For Debugging reasons I tried Wiresharking the Domain Controller, TCP-Dumping the LDAP-Server and the Client. The Traffic looks okay, in case of that error the OpenLDAP Server simply is asking the Domain Controller which returns Success but no results. Since once this error occurs, the query right after the error works and then it takes some time until that error occurs again and due to the fact that in the older OpenLDAP Version it is working, could it be a Bug in the new OpenLDAP Version? I also looked in the Logs of the Domain Controller, everything is fine there. Furthermore I installed test OpenLDAP Systems (Centos[yum], OpenBSD[pkg] and one via compilation from sources via minimal module configuration) (2.4.40) and tried the same configuration there, same Problem. While googling and searching for a solution I stumbled across a guy having the same problem, reporting this 2013 to this mailing list. Someone suggested to add the Active Directory Schema to the OpenLDAP, which I did andhihich did not solve this issue. I tried adding the full schema as well as adding only Attributes and Object classes that are used. Problem still persists. After looking into the code of the bind.c and the commits in the ldap-back Module I saw a change of the code lines in servers/slapd/back-ldap/bind.c (around line 1407): rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred ); - assert( rc == 1 ); + if ( rc != 1 ) { + Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz " + "returned %d, misconfigured URI?\n", rc, 0, 0 ); + rs->sr_err = LDAP_OTHER; + rs->sr_text = "misconfigured URI?"; + LDAP_BACK_CONN_ISBOUND_CLEAR( lc ); + if ( sendok & LDAP_BACK_SENDERR ) { + send_ldap_result( op, rs %;%B + } + goto done; + } } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); goto done; Diff: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blobdiff;f=server… Is it intended that there is a call to goto done? Which obviously prevents the ldap_back_proxy_autzh_bind to happen ? - Since in older Versions of OpenLDAP it works. Best Regards, Dominique Voest

1 0

(ITS#8313) crash in mdb_rebalance(): uninited cursor flags
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

Full_Name: Hallvard B Furuseth Version: mdb.master, 355f64ad07537a4f21dc6fe4cef66324316aa84b OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151118-2.c Submission from: (NULL) (129.240.203.186) Submitted by: hallvard The test program can crash dereferencing mp==NULL at mdb_cursor_del0() line 8244 "nkeys = NUMKEYS(mp);" Apparently because mdb_rebalance() pushes cursor 'dummy' to mt_cursors[] without initializing mc_flags. The test also uses pagesize 0x8000. This prevents the crash. Don't know if it's the right fix: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 6bd025d..8bbc54c 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -8174,2 +8174,3 @@ mdb_rebalance(MDB_cursor *mc) MDB_cursor dummy; + dummy.mc_flags = C_INITIALIZED; oldki += NUMKEYS(mn.mc_pg[mn.mc_top]); OTOH setting dummy.mc_flags = 0 keeps crashing. To reproduce: gcc -O3 -pthread -I. Hallvard-Furuseth-151118-2.c mkdir testdb rm -f testdb/*; ./a.out -d -i100 -p32768 -r617974163 May need to repeat last line a few times. Add option -v to see the Put/Del commands.

1 0

(ITS#8312) LMDB corruption, perhaps in freelist code
by martin＠bzero.se 18 Nov '15

18 Nov '15

Full_Name: Martin Hedenfalk Version: N/A OS: centos 7 URL: http://bzero.se/patches/lmdb/ Submission from: (NULL) (62.181.224.2) Please find linked a test program (replay.c) that consistently fails on my centos 7 system. It parses captured commands from a text file. I'm afraid they are quite large, I haven't been able to reduce them further. The problem manifests itself in many different ways in my real system, sometimes I get MDB_CORRUPTED, sometimes MDB_BAD_TXN, sometimes errno EFBIG (and an unexpectedly large file) and sometimes a NULL pointer crash in mdb_freelist_save. Given that valgrind complains about invalid read of size 8 in mdb_freelist_save/mdb_cursor_put, I'm *guessing* that the freelist code is put'ing an invalid MDB_val, leading to corruption. Any help is greatly appreciated. See the linked backtrace.txt for example runs. There are three captured replay logs (replay[123].txt) that show different failures. This was tested with lmdb git master from github: commit 355f64ad07537a4f21dc6fe4cef66324316aa84b Author: Howard Chu <hyc(a)openldap.org> Date: Wed Nov 18 10:24:41 2015 +0000 ITS#8311 add comment .martin

1 0

(ITS#8311) Crash in mdb_page_split(): negative cursor index
by h.b.furuseth＠usit.uio.no 18 Nov '15

18 Nov '15

Full_Name: Hallvard B Furuseth Version: mdb.master, 3360cbad668f678fb23c064ca4efcc5c9ae95d10 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151118.c Submission from: (NULL) (129.240.203.186) Submitted by: hallvard The test program crashes in mdb_page_split() line 8546 because ptop == -1: if (SIZELEFT(mn.mc_pg[ptop]) < mdb_branch_size(env, &sepkey)) {

1 0

Re: (ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at 18 Nov '15

18 Nov '15

--Apple-Mail=_3EB99AE2-FF47-483D-BB84-C56407123944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Will there be a patch or will this be fixed in the next version? > On 17 Nov 2015, at 16:56 , Ryan Tandy <ryan(a)openldap.org> wrote: >=20 > On Tue, Nov 17, 2015 at 09:13:46AM +0000, B=D6SCH Christian wrote: >> The slapcat output is attached below. >=20 > Thanks for that. Now I did reproduce the bug, in current git master = and also in RE24. >=20 > The backtrace (line numbers from master) is: >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004d9de3 in mdb_txn_begin (env=3D0x0, parent=3D0x0, flags=3D0,= ret=3D0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > 2760 flags |=3D env->me_flags & MDB_WRITEMAP; > (gdb) bt > #0 0x00000000004d9de3 in mdb_txn_begin (env=3D0x0, parent=3D0x0, = flags=3D0, ret=3D0x7fffffe6c750) at = ./../../../libraries/liblmdb/mdb.c:2760 > #1 0x0000000000534d82 in mdb_opinfo_get (op=3D0x7fffffe6ca20, = mdb=3D0x7ffff6eb0010, rdonly=3D0, moip=3D0x7fffffe6c738) at = id2entry.c:472 > #2 0x00000000005256d9 in mdb_add (op=3D0x7fffffe6ca20, = rs=3D0x7fffffe6c9b0) at add.c:68 > #3 0x0000000000557376 in accesslog_response (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at accesslog.c:1867 > #4 0x00000000004ba728 in over_back_response (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at backover.c:245 > #5 0x0000000000441997 in slap_response_play (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at result.c:551 > #6 0x0000000000441bba in send_ldap_response (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at result.c:626 > #7 0x0000000000442ad1 in slap_send_ldap_result (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at result.c:905 > #8 0x00000000004f358d in mdb_search (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at search.c:1186 > #9 0x00000000004bb665 in overlay_op_walk (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0, which=3Dop_search, oi=3D0x9e4f30, on=3D0x0) at = backover.c:696 > #10 0x00000000004bb889 in over_op_func (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0, which=3Dop_search) at backover.c:749 > #11 0x00000000004bb969 in over_op_search (op=3D0x7fffffffd660, = rs=3D0x7fffffffd5c0) at backover.c:776 > #12 0x000000000055d817 in dds_count (ctx=3D0x895e40 = <ldap_int_main_thrctx>, be=3D0x7fffffffdd90) at dds.c:1670 > #13 0x000000000055daaf in dds_db_open (be=3D0x7fffffffdd90, = cr=3D0x7fffffffdfa0) at dds.c:1737 > #14 0x00000000004ba3b2 in over_db_open (be=3D0x9e4460, = cr=3D0x7fffffffdfa0) at backover.c:157 > #15 0x000000000043c6ee in backend_startup_one (be=3D0x9e4460, = cr=3D0x7fffffffdfa0) at backend.c:224 > #16 0x000000000043cc38 in backend_startup (be=3D0x9e4460) at = backend.c:330 > #17 0x0000000000468fcf in slap_startup (be=3D0x0) at init.c:220 > #18 0x0000000000405e86 in main (argc=3D8, argv=3D0x7fffffffe308) at = main.c:997 >=20 > At first glance it looks like another problem related to ITS#8133, = where dds triggers calls into another module (this time, accesslog) = before it has actually initialized. --Apple-Mail=_3EB99AE2-FF47-483D-BB84-C56407123944 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQjCCBQAw ggPooAMCAQICEANL7hcft+EGNy/UckJAvSowDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTE0MTExODEyMDAwMFoXDTI0MTExODEy MDAwMFowaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMalux9VgvSlNHIUcmWbX9XqoGjYm4KJT1Ni nHuMzg7a1DIOrxuMy6br2+DrAzSUwYd+UyCoHvkbF4p9AWYSV2heLZwuKyGoVS9TZwl4zdJpGwuT YGy4KBPOH02xiCatRfrQoc6rt5gpVnFs8VYkXacw4G4xc27aoFdMZIt4tcec28bevtMvMaDWgDm1 4DFAToSjzJJJ4hds/vBkHvq6vCWHnU8huslmOQON1BUQuHs6VM/VY7pP8d/oGwR94VymhrV74xb+ XDRV61M88dDXkdgpg/ZZiiEfHMOIL5BTATtRlUGWn1xcinAe4PNKJtzlEbfPSf+PZJALHQOTkUwB QSsCAwEAAaOCAaYwggGiMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkGCCsG AQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUF BzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxo dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMB0GA1UdDgQWBBTwIelJd3Ofha4YO+hScBQG7ULu yjAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEAOsIb K/5j3rthtLlHqPx8BbEmICJRm8g9+fXFWB6wXqOynAJBjzEaf8wbTh34mH3sjwj9d/Hb0kQQWrat CbDg/GI71GINnvGgPE13iutENHuOu04pA/wn6j5qHS9I4/raGcP/M9Ls1Ey0jJVLYbbvsoAvl8hH raeCv3zh+YmCEO/RuyMYCZ67cQ/TGFSwMlPrUigAagoGfEE8B6DdZex1Kbgaftu3K9qR7IW1h5uv YqY4FJrbw9GoZIO6vnppmEmgzZ4zNzqmua8bDC0DNGxzm3Y6wpG4dZXo7dqc/YrbuMZlHZuLVVfU 1BS8hulU1O7COb5dxm2xr8AAkX0oaQSx4DCCBTowggQioAMCAQICEA2YtdiSBlHYQKDqqgqWaMww DQYJKoZIhvcNAQELBQAwaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQ BgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29u YWwgQ0EgMzAeFw0xNTA1MjkwMDAwMDBaFw0xODA1MjkxMjAwMDBaMHkxCzAJBgNVBAYTAkFUMRMw EQYDVQQIEwpWb3JhcmxiZXJnMREwDwYDVQQHEwhEb3JuYmlybjEnMCUGA1UEChMeRmFjaGhvY2hz Y2h1bGUgVm9yYXJsYmVyZyBHbWJIMRkwFwYDVQQDDBBDaHJpc3RpYW4gQsO2c2NoMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzp4fre091WBIlsq2ZvDkwShPkJuGNnXNBlbXxIeR0/rz 1RHTw9pTHFB0vfSK/eVytrPwdr+jQdMVlZ6CuLjmOkV2Ivy1Af9P2aClsYIteht/LfwkmOJZrl3F mjdJ7fOvvxHstMRj6UCuz1/x1ARMaYVxLYZeBcbisDApA+bKikZ88bTeLNGE0n1mXREYZTFlLCqZ b5+UNyae8iLilr7LDSGIeGbN2OH4ZbfWLT8Xuol+Qpcpcitja84G5iyBEx/v1H9qnrIdID4aLZAN 64UiCgKDUPutx+V3BVRJKBiVt4w5LGvXJPG8djApeVTW+YmBmQTdt4we+xCuYtvOPUxtgQIDAQAB o4IBzDCCAcgwHwYDVR0jBBgwFoAU8CHpSXdzn4WuGDvoUnAUBu1C7sowHQYDVR0OBBYEFJaOo3g6 6TwrK6OMuIrmPweKN1SaMAwGA1UdEwEB/wQCMAAwGAYDVR0RBBEwD4ENYm9lc2NoQGZodi5hdDAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDow OAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25hbENB My5jcmwwcwYIKwYBBQUHAQEEZzBlMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5j b20wPQYIKwYBBQUHMAKGMWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcnQwDQYJKoZIhvcNAQELBQADggEBAH3jDh6ahP08DrzZ4HrSvyCFr/Jnu2s/7F77HZuH jf77zODdRDCpoKj1TfOQE7gTA9nW/dpuOzSVhNauWisD6lF1tSLXnFDlkUaQmg7MzE1laV4anMb2 WGU5sKHawq4FH1SQyS1sjuilmc69Y6gRFRSx2XZ3CiG+3drAiV1DVpYvLc4Yd4Izw1RsayxnMxaw uX+RUngMgtw92b1bmiQM1DlJq+g6sFoz7iUdMEReX+zapXCDtxGb65v2LjB1w35CVu5D6YW38JxF qQ7CeFdFpd3NEIcV6eykiaX5P55E2SX0wY+kpFvm64F5lAPqlc28qtKv560BiN7W9eJUotHyUA0x ggMlMIIDIQIBATB9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD VQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFs IENBIDMCEA2YtdiSBlHYQKDqqgqWaMwwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTE4MDgwNDUyWjAjBgkqhkiG9w0BCQQxFgQUgORc 1r/bZHizrJ1k7JU9oUbrUr0wgYwGCSsGAQQBgjcQBDF/MH0waTELMAkGA1UEBhMCTkwxFjAUBgNV BAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0w GwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMwIQDZi12JIGUdhAoOqqCpZozDCBjgYLKoZIhvcN AQkQAgsxf6B9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENB IDMCEA2YtdiSBlHYQKDqqgqWaMwwDQYJKoZIhvcNAQEBBQAEggEArBvb84qOOqcZdi7Oo2q+UpC+ BfKpeDyVcv5h9IDvVR4JAzuvsQ5tXvIZ8oBlFQy3Ik1617MRh1pxXCT2eTnfN35hAP56ypAar+Sb 0O7ZzE1XuNKVtQ7LkdrY/QKuProOnS3F/MdBCeoPRIVlG/Gv9liCO63jQ0pM7FXXpeCwfjZbkm9S JrAM2Vy+gJYF/F1NdsPIXASKgSpM+486FHjMdNXyrIzE3EiRFxx9d3SRhhspJsyuwy5XSehDIiDr 1+Zd0MBhU2d8Eav413Po6yl+lUancFi261vYhRjHu+LRNEHerGLRxk4Hte7e9+hIUvGGMpmvycOj FWV1eN+ubNFjBgAAAAAAAA== --Apple-Mail=_3EB99AE2-FF47-483D-BB84-C56407123944--

1 0

Re: (ITS#8307) startup failed with DDS enabled
by hyc＠symas.com 17 Nov '15

17 Nov '15

ryan(a)openldap.org wrote: > On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote: >> The slapcat output is attached below. > > Thanks for that. Now I did reproduce the bug, in current git master and > also in RE24. This particular problem can be fixed by setting op->o_do_not_cache in dds_count. Not sure what's needed for a more general solution. > The backtrace (line numbers from master) is: > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > 2760 flags |= env->me_flags & MDB_WRITEMAP; > (gdb) bt > #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 > #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 > #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 > #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 > #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 > #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 > #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 > #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 > #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 > #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 > #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 > #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 > #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 > #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 > #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 > #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 > #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 > #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 > #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997 > > At first glance it looks like another problem related to ITS#8133, where > dds triggers calls into another module (this time, accesslog) before it > has actually initialized. > > > > -- -- 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#8307) startup failed with DDS enabled
by ryan＠openldap.org 17 Nov '15

17 Nov '15

On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote: >The slapcat output is attached below. Thanks for that. Now I did reproduce the bug, in current git master and also in RE24. The backtrace (line numbers from master) is: Program received signal SIGSEGV, Segmentation fault. 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 2760 flags |= env->me_flags & MDB_WRITEMAP; (gdb) bt #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997 At first glance it looks like another problem related to ITS#8133, where dds triggers calls into another module (this time, accesslog) before it has actually initialized.

1 0

Re: (ITS#8307) startup failed with DDS enabled
by ryan＠openldap.org 17 Nov '15

17 Nov '15

Hello Christian, On Mon, Nov 16, 2015 at 07:46:31AM +0000, BÖSCH Christian wrote: >The last lines of debug.log are: > >[…] > >The build config is: >[…] Thanks for that information, however I still need more details about your actual running config in order to reproduce the problem. Could you please provide the output of slapcat -b 'cn=config' (plus an appropriate -F setting) either from a test setup that shows the problem, or from your actual config with passwords/sensitive information removed (note some are emitted in base64 form). On Mon, Nov 16, 2015 at 02:06:17PM +0000, BÖSCH Christian wrote: >on freebsd 10.2 build from source failed with the message: > > cd back-mdb; make all >/bin/sh ../../../libtool --tag=disable-shared --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c > cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c -o mdb.o >./../../../libraries/liblmdb/mdb.c:4758:39: error: use of undeclared identifier 'O_DSYNC' > env->me_mfd = open(dpath, oflags | MDB_DSYNC, mode); > ^ >./../../../libraries/liblmdb/mdb.c:409:20: note: expanded from macro 'MDB_DSYNC' ># define MDB_DSYNC O_DSYNC > ^ >./../../../libraries/liblmdb/mdb.c:9681:46: warning: data argument not used by format string [-Wformat-extra-args] > (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid); > ^ >1 warning and 1 error generated. >*** Error code 1 > >Stop. >make[3]: stopped in /root/openldap/servers/slapd/back-mdb >*** Error code 1 This is ITS#7209 <http://www.openldap.org/its/?findid=7209>. The patch linked at the top of that should allow it to build. thanks, Ryan

1 0

Re: (ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at 16 Nov '15

16 Nov '15

--Apple-Mail=_6635199E-F0F1-40A8-B683-4F6C4A79B399 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E8C6C2A-A71D-4391-8691-0E1DBECC9F17" --Apple-Mail=_6E8C6C2A-A71D-4391-8691-0E1DBECC9F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Nov 2015, at 06:30 , Ryan Tandy <ryan(a)openldap.org> wrote: >=20 > Hello Christian, >=20 > On Thu, Nov 12, 2015 at 12:54:09PM +0000, boesch(a)fhv.at wrote: >> I installed OpenLDAP 2.4.42, enabled these overlays on the mdb = database: >> olcOverlay=3D{0}syncprov.ldif >> olcOverlay=3D{1}dds.ldif >> olcOverlay=3D{2}accesslog.ldif >> olcOverlay=3D{3}unique.ldif >> olcOverlay=3D{4}ppolicy.ldif >> olcOverlay=3D{5}refint.ldif >> olcOverlay=3D{6}memberof.ldif >> olcOverlay=3D{7}dynlist.ldif >> started, everything is fine. >>=20 >> Then I added an empty base tree: >> dn: dc=3Dexample,dc=3Dnet >> objectClass: dcObject >> objectClass: organization >> o: ORG >> dc: example >>=20 >> dn: cn=3Dadmin,dc=3Dexample,dc=3Dnet >> objectClass: organizationalRole >> cn: LDAP Admin >> cn: admin >>=20 >> dn: o=3Dorg,dc=3Dexample,dc=3Dnet >> o: ORG >> objectClass: organization >> objectClass: top >=20 > I tried to reproduce your problem under openldap 2.4.42 on Linux = (Debian), using the attached config and the data LDIF you provided, but = didn't observe any problems. Would you please provide more details about = the configuration that causes the problem, including the options = specified when you built OpenLDAP, and any applicable log messages? It = would also be good to know if you can reproduce the problem using = current sources from git branch OPENLDAP_REL_ENG_2_4, which is the = 2.4.43 release candidate. on freebsd 10.2 build from source failed with the message: cd back-mdb; make all /bin/sh ../../../libtool --tag=3Ddisable-shared --mode=3Dcompile cc -g = -O2 -I../../../include -I../../../include -I.. -I./.. = -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c cc -g -O2 -I../../../include -I../../../include -I.. -I./.. = -I./../../../libraries/liblmdb -c ./../../../libraries/liblmdb/mdb.c -o = mdb.o ./../../../libraries/liblmdb/mdb.c:4758:39: error: use of undeclared = identifier 'O_DSYNC' env->me_mfd =3D open(dpath, oflags | MDB_DSYNC, = mode); ^ ./../../../libraries/liblmdb/mdb.c:409:20: note: expanded from macro = 'MDB_DSYNC' # define MDB_DSYNC O_DSYNC ^ ./../../../libraries/liblmdb/mdb.c:9681:46: warning: data argument not = used by format string [-Wformat-extra-args] (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, = txnid); = ^ 1 warning and 1 error generated. *** Error code 1 Stop. make[3]: stopped in /root/openldap/servers/slapd/back-mdb *** Error code 1 regards, chris >=20 > thanks, > Ryan >=20 > dn: cn=3Dconfig > objectClass: olcGlobal >=20 > dn: cn=3Dschema,cn=3Dconfig > objectClass: olcSchemaConfig >=20 > include: file:servers/slapd/schema/core.ldif >=20 > include: file:servers/slapd/schema/cosine.ldif >=20 > include: file:servers/slapd/schema/inetorgperson.ldif >=20 > include: file:servers/slapd/schema/nis.ldif >=20 > include: file:servers/slapd/schema/dyngroup.ldif >=20 > include: file:servers/slapd/schema/ppolicy.ldif >=20 > dn: olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcMdbConfig > olcSuffix: dc=3Dexample,dc=3Dnet > olcDbDirectory: data.d > olcRootDN: cn=3Droot,dc=3Dexample,dc=3Dnet > olcRootPW: secret >=20 > dn: olcDatabase=3D{2}mdb,cn=3Dconfig > objectClass: olcMdbConfig > olcSuffix: cn=3Daccesslog > olcDbDirectory: accesslog.d >=20 > dn: olcOverlay=3D{0}syncprov,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcSyncProvConfig >=20 > dn: olcOverlay=3D{1}dds,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcDDSConfig >=20 > dn: olcOverlay=3D{2}accesslog,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcAccessLogConfig > olcAccessLogDB: cn=3Daccesslog >=20 > dn: olcOverlay=3D{3}unique,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcUniqueConfig >=20 > dn: olcOverlay=3D{4}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcPPolicyConfig >=20 > dn: olcOverlay=3D{5}refint,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcRefintConfig >=20 > dn: olcOverlay=3D{6}memberof,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcMemberOf >=20 > dn: olcOverlay=3D{7}dynlist,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcDynamicList --Apple-Mail=_6E8C6C2A-A71D-4391-8691-0E1DBECC9F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 13 Nov 2015, at 06:30 , Ryan Tandy <<a = href=3D"mailto:ryan@openldap.org" class=3D"">ryan(a)openldap.org</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">Hello Christian,<br class=3D""><br class=3D"">On Thu, Nov 12, = 2015 at 12:54:09PM +0000, <a href=3D"mailto:boesch@fhv.at" = class=3D"">boesch(a)fhv.at</a> wrote:<br class=3D""><blockquote = type=3D"cite" class=3D"">I installed OpenLDAP 2.4.42, enabled these = overlays on the mdb database:<br class=3D"">olcOverlay=3D{0}syncprov.ldif<= br class=3D"">olcOverlay=3D{1}dds.ldif<br = class=3D"">olcOverlay=3D{2}accesslog.ldif<br = class=3D"">olcOverlay=3D{3}unique.ldif<br = class=3D"">olcOverlay=3D{4}ppolicy.ldif<br = class=3D"">olcOverlay=3D{5}refint.ldif<br = class=3D"">olcOverlay=3D{6}memberof.ldif<br = class=3D"">olcOverlay=3D{7}dynlist.ldif<br class=3D"">started, = everything is fine.<br class=3D""><br class=3D"">Then I added an empty = base tree:<br class=3D"">dn: dc=3Dexample,dc=3Dnet<br = class=3D"">objectClass: dcObject<br class=3D"">objectClass: = organization<br class=3D"">o: ORG<br class=3D"">dc: example<br = class=3D""><br class=3D"">dn: cn=3Dadmin,dc=3Dexample,dc=3Dnet<br = class=3D"">objectClass: organizationalRole<br class=3D"">cn: LDAP = Admin<br class=3D"">cn: admin<br class=3D""><br class=3D"">dn: = o=3Dorg,dc=3Dexample,dc=3Dnet<br class=3D"">o: ORG<br = class=3D"">objectClass: organization<br class=3D"">objectClass: top<br = class=3D""></blockquote><br class=3D"">I tried to reproduce your problem = under openldap 2.4.42 on Linux (Debian), using the attached config and = the data LDIF you provided, but didn't observe any problems. Would you = please provide more details about the configuration that causes the = problem, including the options specified when you built OpenLDAP, and = any applicable log messages? It would also be good to know if you can = reproduce the problem using current sources from git branch = OPENLDAP_REL_ENG_2_4, which is the 2.4.43 release candidate.<br = class=3D""></div></div></blockquote><div><br class=3D""></div>on freebsd = 10.2 build from source failed with the message:</div><div><br = class=3D""></div><div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D"">  cd = back-mdb; make   all</div><div style=3D"margin: 0px; font-size: = 11px; line-height: normal; font-family: Menlo;" class=3D"">/bin/sh = ../../../libtool --tag=3Ddisable-shared --mode=3Dcompile  cc -g -O2 = -I../../../include -I../../../include -I.. -I./.. = -I./../../../libraries/liblmdb     -c = ./../../../libraries/liblmdb/mdb.c</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D""> cc -g -O2 -I../../../include -I../../../include -I.. = -I./.. -I./../../../libraries/liblmdb -c = ./../../../libraries/liblmdb/mdb.c -o mdb.o</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D""><b class=3D"">./../../../libraries/liblmdb/mdb.c:4758:39: = </b><span style=3D"font-variant-ligatures: no-common-ligatures; color: = #c33720" class=3D""><b class=3D"">error: </b></span><b class=3D"">use of = undeclared identifier 'O_DSYNC'</b></div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">                =         env->me_mfd =3D open(dpath, oflags | = MDB_DSYNC, mode);</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo; color: rgb(52, 189, 38);" = class=3D""><b class=3D"">             =                     =                     =       ^</b></div><div style=3D"margin: 0px; font-size: = 11px; line-height: normal; font-family: Menlo;" class=3D""><b = class=3D"">./../../../libraries/liblmdb/mdb.c:409:20: note: </b>expanded = from macro 'MDB_DSYNC'</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D""># define = MDB_DSYNC      O_DSYNC</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(52, = 189, 38);" class=3D""><b class=3D"">          =               ^</b></div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D""><b = class=3D"">./../../../libraries/liblmdb/mdb.c:9681:46: </b><span = style=3D"font-variant-ligatures: no-common-ligatures; color: #d53bd3" = class=3D""><b class=3D"">warning: </b></span><b class=3D"">data argument = not used by format string [-Wformat-extra-args]</b></div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">              =                   = (int)mr[i].mr_pid, (size_t)mr[i].mr_tid, txnid);</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo; color: rgb(52, 189, 38);" class=3D""><b class=3D"">   =                     =                     =                     =           ^</b></div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">1 = warning and 1 error generated.</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">*** = Error code 1</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo; min-height: 13px;" class=3D""><br= class=3D""></div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D"">Stop.</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">make[3]: stopped in = /root/openldap/servers/slapd/back-mdb</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">*** = Error code 1</div><div class=3D""><br class=3D""></div><div class=3D""><br= class=3D""></div><div class=3D"">regards,</div><div = class=3D"">chris</div><div class=3D""><br class=3D""></div><blockquote = type=3D"cite" class=3D""><div class=3D""><div class=3D""><br = class=3D"">thanks,<br class=3D"">Ryan<br class=3D""><br class=3D"">dn: = cn=3Dconfig<br class=3D"">objectClass: olcGlobal<br class=3D""><br = class=3D"">dn: cn=3Dschema,cn=3Dconfig<br class=3D"">objectClass: = olcSchemaConfig<br class=3D""><br class=3D"">include: = file:servers/slapd/schema/core.ldif<br class=3D""><br class=3D"">include: = file:servers/slapd/schema/cosine.ldif<br class=3D""><br = class=3D"">include: file:servers/slapd/schema/inetorgperson.ldif<br = class=3D""><br class=3D"">include: file:servers/slapd/schema/nis.ldif<br = class=3D""><br class=3D"">include: = file:servers/slapd/schema/dyngroup.ldif<br class=3D""><br = class=3D"">include: file:servers/slapd/schema/ppolicy.ldif<br = class=3D""><br class=3D"">dn: olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcMdbConfig<br class=3D"">olcSuffix: = dc=3Dexample,dc=3Dnet<br class=3D"">olcDbDirectory: data.d<br = class=3D"">olcRootDN: cn=3Droot,dc=3Dexample,dc=3Dnet<br = class=3D"">olcRootPW: secret<br class=3D""><br class=3D"">dn: = olcDatabase=3D{2}mdb,cn=3Dconfig<br class=3D"">objectClass: = olcMdbConfig<br class=3D"">olcSuffix: cn=3Daccesslog<br = class=3D"">olcDbDirectory: accesslog.d<br class=3D""><br class=3D"">dn: = olcOverlay=3D{0}syncprov,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcSyncProvConfig<br class=3D""><br class=3D"">dn:= olcOverlay=3D{1}dds,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcDDSConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{2}accesslog,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcAccessLogConfig<br class=3D"">olcAccessLogDB: = cn=3Daccesslog<br class=3D""><br class=3D"">dn: = olcOverlay=3D{3}unique,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcUniqueConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{4}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcPPolicyConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{5}refint,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcRefintConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{6}memberof,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcMemberOf<br class=3D""><br class=3D"">dn: = olcOverlay=3D{7}dynlist,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcDynamicList<br = class=3D""></div></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_6E8C6C2A-A71D-4391-8691-0E1DBECC9F17-- --Apple-Mail=_6635199E-F0F1-40A8-B683-4F6C4A79B399 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQjCCBQAw ggPooAMCAQICEANL7hcft+EGNy/UckJAvSowDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTE0MTExODEyMDAwMFoXDTI0MTExODEy MDAwMFowaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMalux9VgvSlNHIUcmWbX9XqoGjYm4KJT1Ni nHuMzg7a1DIOrxuMy6br2+DrAzSUwYd+UyCoHvkbF4p9AWYSV2heLZwuKyGoVS9TZwl4zdJpGwuT YGy4KBPOH02xiCatRfrQoc6rt5gpVnFs8VYkXacw4G4xc27aoFdMZIt4tcec28bevtMvMaDWgDm1 4DFAToSjzJJJ4hds/vBkHvq6vCWHnU8huslmOQON1BUQuHs6VM/VY7pP8d/oGwR94VymhrV74xb+ XDRV61M88dDXkdgpg/ZZiiEfHMOIL5BTATtRlUGWn1xcinAe4PNKJtzlEbfPSf+PZJALHQOTkUwB QSsCAwEAAaOCAaYwggGiMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkGCCsG AQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUF BzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxo dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMB0GA1UdDgQWBBTwIelJd3Ofha4YO+hScBQG7ULu yjAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEAOsIb K/5j3rthtLlHqPx8BbEmICJRm8g9+fXFWB6wXqOynAJBjzEaf8wbTh34mH3sjwj9d/Hb0kQQWrat CbDg/GI71GINnvGgPE13iutENHuOu04pA/wn6j5qHS9I4/raGcP/M9Ls1Ey0jJVLYbbvsoAvl8hH raeCv3zh+YmCEO/RuyMYCZ67cQ/TGFSwMlPrUigAagoGfEE8B6DdZex1Kbgaftu3K9qR7IW1h5uv YqY4FJrbw9GoZIO6vnppmEmgzZ4zNzqmua8bDC0DNGxzm3Y6wpG4dZXo7dqc/YrbuMZlHZuLVVfU 1BS8hulU1O7COb5dxm2xr8AAkX0oaQSx4DCCBTowggQioAMCAQICEA2YtdiSBlHYQKDqqgqWaMww DQYJKoZIhvcNAQELBQAwaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQ BgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29u YWwgQ0EgMzAeFw0xNTA1MjkwMDAwMDBaFw0xODA1MjkxMjAwMDBaMHkxCzAJBgNVBAYTAkFUMRMw EQYDVQQIEwpWb3JhcmxiZXJnMREwDwYDVQQHEwhEb3JuYmlybjEnMCUGA1UEChMeRmFjaGhvY2hz Y2h1bGUgVm9yYXJsYmVyZyBHbWJIMRkwFwYDVQQDDBBDaHJpc3RpYW4gQsO2c2NoMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzp4fre091WBIlsq2ZvDkwShPkJuGNnXNBlbXxIeR0/rz 1RHTw9pTHFB0vfSK/eVytrPwdr+jQdMVlZ6CuLjmOkV2Ivy1Af9P2aClsYIteht/LfwkmOJZrl3F mjdJ7fOvvxHstMRj6UCuz1/x1ARMaYVxLYZeBcbisDApA+bKikZ88bTeLNGE0n1mXREYZTFlLCqZ b5+UNyae8iLilr7LDSGIeGbN2OH4ZbfWLT8Xuol+Qpcpcitja84G5iyBEx/v1H9qnrIdID4aLZAN 64UiCgKDUPutx+V3BVRJKBiVt4w5LGvXJPG8djApeVTW+YmBmQTdt4we+xCuYtvOPUxtgQIDAQAB o4IBzDCCAcgwHwYDVR0jBBgwFoAU8CHpSXdzn4WuGDvoUnAUBu1C7sowHQYDVR0OBBYEFJaOo3g6 6TwrK6OMuIrmPweKN1SaMAwGA1UdEwEB/wQCMAAwGAYDVR0RBBEwD4ENYm9lc2NoQGZodi5hdDAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDow OAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25hbENB My5jcmwwcwYIKwYBBQUHAQEEZzBlMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5j b20wPQYIKwYBBQUHMAKGMWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcnQwDQYJKoZIhvcNAQELBQADggEBAH3jDh6ahP08DrzZ4HrSvyCFr/Jnu2s/7F77HZuH jf77zODdRDCpoKj1TfOQE7gTA9nW/dpuOzSVhNauWisD6lF1tSLXnFDlkUaQmg7MzE1laV4anMb2 WGU5sKHawq4FH1SQyS1sjuilmc69Y6gRFRSx2XZ3CiG+3drAiV1DVpYvLc4Yd4Izw1RsayxnMxaw uX+RUngMgtw92b1bmiQM1DlJq+g6sFoz7iUdMEReX+zapXCDtxGb65v2LjB1w35CVu5D6YW38JxF qQ7CeFdFpd3NEIcV6eykiaX5P55E2SX0wY+kpFvm64F5lAPqlc28qtKv560BiN7W9eJUotHyUA0x ggMlMIIDIQIBATB9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD VQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFs IENBIDMCEA2YtdiSBlHYQKDqqgqWaMwwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTE2MTQwNjE2WjAjBgkqhkiG9w0BCQQxFgQUKOCp RayljBV9dnmgox8AUJE6r9MwgYwGCSsGAQQBgjcQBDF/MH0waTELMAkGA1UEBhMCTkwxFjAUBgNV BAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0w GwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMwIQDZi12JIGUdhAoOqqCpZozDCBjgYLKoZIhvcN AQkQAgsxf6B9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENB IDMCEA2YtdiSBlHYQKDqqgqWaMwwDQYJKoZIhvcNAQEBBQAEggEAxTMptbs+oKCvo5HyF3f0j8Ot MDihbSDVwXXBl4Wee2eQ6A+SnjWU89d78VF1rXanmRwCxuO4oNwIjmzagS7t/L12kTneZ5Pdc7vB RS9XkYcNM+fgiPj9EFOdVQjZRLNneNNXzjQtJi2tS6cIzFtqh78JryT359y/eDyjx5Ker6gFtfMe KkOx1Z9DoFptSrG+rF68L8HtWkUV71pwXRLTnUkMUnVEc82gcaKPdL+Knvvq+tTI/FP9Ta+Ys95M vO9uq7k6bX+rrvGXu6UxWlKtKxEsTyvbiGE4fM6pNZyk1QIiUgVDFonWM1yCrtV1KhI1MdaccwOU jjGhIfKpdl+WeAAAAAAAAA== --Apple-Mail=_6635199E-F0F1-40A8-B683-4F6C4A79B399--

1 0

Re: (ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at 16 Nov '15

16 Nov '15

--Apple-Mail=_372DE61B-D3BA-4719-A35F-AC49091503C9 Content-Type: multipart/alternative; boundary="Apple-Mail=_5D31F49F-5A56-4ADF-B31A-D5369C6C72EE" --Apple-Mail=_5D31F49F-5A56-4ADF-B31A-D5369C6C72EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Nov 2015, at 06:30 , Ryan Tandy <ryan(a)openldap.org> wrote: >=20 > Hello Christian, >=20 > On Thu, Nov 12, 2015 at 12:54:09PM +0000, boesch(a)fhv.at wrote: >> I installed OpenLDAP 2.4.42, enabled these overlays on the mdb = database: >> olcOverlay=3D{0}syncprov.ldif >> olcOverlay=3D{1}dds.ldif >> olcOverlay=3D{2}accesslog.ldif >> olcOverlay=3D{3}unique.ldif >> olcOverlay=3D{4}ppolicy.ldif >> olcOverlay=3D{5}refint.ldif >> olcOverlay=3D{6}memberof.ldif >> olcOverlay=3D{7}dynlist.ldif >> started, everything is fine. >>=20 >> Then I added an empty base tree: >> dn: dc=3Dexample,dc=3Dnet >> objectClass: dcObject >> objectClass: organization >> o: ORG >> dc: example >>=20 >> dn: cn=3Dadmin,dc=3Dexample,dc=3Dnet >> objectClass: organizationalRole >> cn: LDAP Admin >> cn: admin >>=20 >> dn: o=3Dorg,dc=3Dexample,dc=3Dnet >> o: ORG >> objectClass: organization >> objectClass: top >=20 > I tried to reproduce your problem under openldap 2.4.42 on Linux = (Debian), using the attached config and the data LDIF you provided, but = didn't observe any problems. Would you please provide more details about = the configuration that causes the problem, including the options = specified when you built OpenLDAP, and any applicable log messages? It = would also be good to know if you can reproduce the problem using = current sources from git branch OPENLDAP_REL_ENG_2_4, which is the = 2.4.43 release candidate. The last lines of debug.log are: Nov 16 08:39:36 openldap1 slapd[49483]: slapd startup: initiated. Nov 16 08:39:36 openldap1 slapd[49483]: backend_startup_one: starting = "cn=3Dconfig" Nov 16 08:39:36 openldap1 slapd[49483]: config_back_db_open Nov 16 08:39:36 openldap1 slapd[49483]: backend_startup_one: starting = "dc=3Dexample,dc=3Dnet" Nov 16 08:39:36 openldap1 slapd[49483]: mdb_db_open: database = "dc=3Dexample,dc=3Dnet": dbenv_open(/var/db/openldap-data). Nov 16 08:39:36 openldap1 slapd[49483]: =3D> mdb_search Nov 16 08:39:36 openldap1 slapd[49483]: = mdb_dn2entry("dc=3Dexample,dc=3Dnet") Nov 16 08:39:36 openldap1 slapd[49483]: =3D> = mdb_dn2id("dc=3Dexample,dc=3Dnet") Nov 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_dn2id: got id=3D0x1 Nov 16 08:39:36 openldap1 slapd[49483]: =3D> mdb_entry_decode: Nov 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_entry_decode Nov 16 08:39:36 openldap1 slapd[49483]: search_candidates: = base=3D"dc=3Dexample,dc=3Dnet" (0x00000001) scope=3D2 Nov 16 08:39:36 openldap1 slapd[49483]: =3D> mdb_equality_candidates = (objectClass) Nov 16 08:39:36 openldap1 slapd[49483]: =3D> key_read Nov 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_index_read: failed = (-30798) Nov 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_equality_candidates: = id=3D0, first=3D0, last=3D0 Nov 16 08:39:36 openldap1 slapd[49483]: =3D> mdb_equality_candidates = (objectClass) Nov 16 08:39:36 openldap1 slapd[49483]: =3D> key_read Nov 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_index_read: failed = (-30798) Nov 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_equality_candidates: = id=3D0, first=3D0, last=3D0 Nov 16 08:39:36 openldap1 slapd[49483]: mdb_search_candidates: id=3D0 = first=3D0 last=3D0 Nov 16 08:39:36 openldap1 slapd[49483]: mdb_search: no candidates Nov 16 08:39:36 openldap1 slapd[49483]: send_ldap_result: conn=3D-1 op=3D0= p=3D0 Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_required entry = (reqStart=3D20151116073936.000002Z,cn=3Dlog), objectClass "auditSearch" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "objectClass" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "structuralObjectClass" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqStart" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqEnd" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqType" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqSession" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqAuthzID" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqDN" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqResult" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqScope" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqDerefAliases" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqAttrsOnly" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqFilter" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type "reqAttr" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqEntries" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqTimeLimit" Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqSizeLimit" The build config is: # This file is auto-generated by 'make config'. # Options for openldap-server-2.4.42_2 _OPTIONS_READ=3Dopenldap-server-2.4.42_2 _FILE_COMPLETE_OPTIONS_LIST=3DACCESSLOG ACI AUDITLOG BDB COLLECT = CONSTRAINT DDS DEBUG DEREF DNSSRV DYNACL DYNAMIC_BACKENDS DYNGROUP = DYNLIST FETCH GSSAPI LMPASSWD MDB MEMBEROF ODBC OUTLOOK PASSWD PERL = PPOLICY PROXYCACHE REFINT RELAY RETCODE RLOOKUPS RWM SASL SEQMOD SHA2 = SHELL SLAPI SMBPWD SOCK SSSVLV SYNCPROV TCP_WRAPPERS TRANSLUCENT UNIQUE = VALSORT OPTIONS_FILE_SET+=3DACCESSLOG OPTIONS_FILE_UNSET+=3DACI OPTIONS_FILE_SET+=3DAUDITLOG OPTIONS_FILE_UNSET+=3DBDB OPTIONS_FILE_SET+=3DCOLLECT OPTIONS_FILE_SET+=3DCONSTRAINT OPTIONS_FILE_SET+=3DDDS OPTIONS_FILE_SET+=3DDEBUG OPTIONS_FILE_SET+=3DDEREF OPTIONS_FILE_SET+=3DDNSSRV OPTIONS_FILE_UNSET+=3DDYNACL OPTIONS_FILE_SET+=3DDYNAMIC_BACKENDS OPTIONS_FILE_SET+=3DDYNGROUP OPTIONS_FILE_SET+=3DDYNLIST OPTIONS_FILE_SET+=3DFETCH OPTIONS_FILE_UNSET+=3DGSSAPI OPTIONS_FILE_UNSET+=3DLMPASSWD OPTIONS_FILE_SET+=3DMDB OPTIONS_FILE_SET+=3DMEMBEROF OPTIONS_FILE_UNSET+=3DODBC OPTIONS_FILE_SET+=3DOUTLOOK OPTIONS_FILE_SET+=3DPASSWD OPTIONS_FILE_SET+=3DPERL OPTIONS_FILE_SET+=3DPPOLICY OPTIONS_FILE_SET+=3DPROXYCACHE OPTIONS_FILE_SET+=3DREFINT OPTIONS_FILE_SET+=3DRELAY OPTIONS_FILE_SET+=3DRETCODE OPTIONS_FILE_SET+=3DRLOOKUPS OPTIONS_FILE_SET+=3DRWM OPTIONS_FILE_SET+=3DSASL OPTIONS_FILE_SET+=3DSEQMOD OPTIONS_FILE_SET+=3DSHA2 OPTIONS_FILE_UNSET+=3DSHELL OPTIONS_FILE_UNSET+=3DSLAPI OPTIONS_FILE_SET+=3DSMBPWD OPTIONS_FILE_SET+=3DSOCK OPTIONS_FILE_SET+=3DSSSVLV OPTIONS_FILE_SET+=3DSYNCPROV OPTIONS_FILE_SET+=3DTCP_WRAPPERS OPTIONS_FILE_SET+=3DTRANSLUCENT OPTIONS_FILE_SET+=3DUNIQUE OPTIONS_FILE_SET+=3DVALSORT I=E2=80=99ll try the build with your mentioned branch soon and get in = touch again. thanks, Chris >=20 > thanks, > Ryan >=20 > dn: cn=3Dconfig > objectClass: olcGlobal >=20 > dn: cn=3Dschema,cn=3Dconfig > objectClass: olcSchemaConfig >=20 > include: file:servers/slapd/schema/core.ldif >=20 > include: file:servers/slapd/schema/cosine.ldif >=20 > include: file:servers/slapd/schema/inetorgperson.ldif >=20 > include: file:servers/slapd/schema/nis.ldif >=20 > include: file:servers/slapd/schema/dyngroup.ldif >=20 > include: file:servers/slapd/schema/ppolicy.ldif >=20 > dn: olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcMdbConfig > olcSuffix: dc=3Dexample,dc=3Dnet > olcDbDirectory: data.d > olcRootDN: cn=3Droot,dc=3Dexample,dc=3Dnet > olcRootPW: secret >=20 > dn: olcDatabase=3D{2}mdb,cn=3Dconfig > objectClass: olcMdbConfig > olcSuffix: cn=3Daccesslog > olcDbDirectory: accesslog.d >=20 > dn: olcOverlay=3D{0}syncprov,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcSyncProvConfig >=20 > dn: olcOverlay=3D{1}dds,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcDDSConfig >=20 > dn: olcOverlay=3D{2}accesslog,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcAccessLogConfig > olcAccessLogDB: cn=3Daccesslog >=20 > dn: olcOverlay=3D{3}unique,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcUniqueConfig >=20 > dn: olcOverlay=3D{4}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcPPolicyConfig >=20 > dn: olcOverlay=3D{5}refint,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcRefintConfig >=20 > dn: olcOverlay=3D{6}memberof,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcMemberOf >=20 > dn: olcOverlay=3D{7}dynlist,olcDatabase=3D{1}mdb,cn=3Dconfig > objectClass: olcDynamicList --Apple-Mail=_5D31F49F-5A56-4ADF-B31A-D5369C6C72EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 13 Nov 2015, at 06:30 , Ryan Tandy <<a = href=3D"mailto:ryan@openldap.org" class=3D"">ryan(a)openldap.org</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">Hello Christian,<br class=3D""><br class=3D"">On Thu, Nov 12, = 2015 at 12:54:09PM +0000, <a href=3D"mailto:boesch@fhv.at" = class=3D"">boesch(a)fhv.at</a> wrote:<br class=3D""><blockquote = type=3D"cite" class=3D"">I installed OpenLDAP 2.4.42, enabled these = overlays on the mdb database:<br class=3D"">olcOverlay=3D{0}syncprov.ldif<= br class=3D"">olcOverlay=3D{1}dds.ldif<br = class=3D"">olcOverlay=3D{2}accesslog.ldif<br = class=3D"">olcOverlay=3D{3}unique.ldif<br = class=3D"">olcOverlay=3D{4}ppolicy.ldif<br = class=3D"">olcOverlay=3D{5}refint.ldif<br = class=3D"">olcOverlay=3D{6}memberof.ldif<br = class=3D"">olcOverlay=3D{7}dynlist.ldif<br class=3D"">started, = everything is fine.<br class=3D""><br class=3D"">Then I added an empty = base tree:<br class=3D"">dn: dc=3Dexample,dc=3Dnet<br = class=3D"">objectClass: dcObject<br class=3D"">objectClass: = organization<br class=3D"">o: ORG<br class=3D"">dc: example<br = class=3D""><br class=3D"">dn: cn=3Dadmin,dc=3Dexample,dc=3Dnet<br = class=3D"">objectClass: organizationalRole<br class=3D"">cn: LDAP = Admin<br class=3D"">cn: admin<br class=3D""><br class=3D"">dn: = o=3Dorg,dc=3Dexample,dc=3Dnet<br class=3D"">o: ORG<br = class=3D"">objectClass: organization<br class=3D"">objectClass: top<br = class=3D""></blockquote><br class=3D"">I tried to reproduce your problem = under openldap 2.4.42 on Linux (Debian), using the attached config and = the data LDIF you provided, but didn't observe any problems. Would you = please provide more details about the configuration that causes the = problem, including the options specified when you built OpenLDAP, and = any applicable log messages? It would also be good to know if you can = reproduce the problem using current sources from git branch = OPENLDAP_REL_ENG_2_4, which is the 2.4.43 release candidate.<br = class=3D""></div></div></blockquote><div><br class=3D""></div>The last = lines of debug.log are:</div><div><br class=3D""></div><div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: slapd = startup: initiated.</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 = openldap1 slapd[49483]: backend_startup_one: starting = "cn=3Dconfig"</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 = openldap1 slapd[49483]: config_back_db_open</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: backend_startup_one: = starting "dc=3Dexample,dc=3Dnet"</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: mdb_db_open: database = "dc=3Dexample,dc=3Dnet": dbenv_open(/var/db/openldap-data).</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: =3D> = mdb_search</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: mdb_dn2entry("dc=3Dexample,dc=3Dnet")</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: =3D> = mdb_dn2id("dc=3Dexample,dc=3Dnet")</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_dn2id: got = id=3D0x1</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: =3D> mdb_entry_decode:</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_entry_decode</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: = search_candidates: base=3D"dc=3Dexample,dc=3Dnet" (0x00000001) = scope=3D2</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: =3D> mdb_equality_candidates (objectClass)</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: =3D> = key_read</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: <=3D mdb_index_read: failed (-30798)</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: <=3D = mdb_equality_candidates: id=3D0, first=3D0, last=3D0</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: =3D> = mdb_equality_candidates (objectClass)</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: =3D> key_read</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: <=3D = mdb_index_read: failed (-30798)</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: <=3D mdb_equality_candidates: = id=3D0, first=3D0, last=3D0</div><div style=3D"margin: 0px; font-size: = 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov 16 = 08:39:36 openldap1 slapd[49483]: mdb_search_candidates: id=3D0 first=3D0 = last=3D0</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: mdb_search: no candidates</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: send_ldap_result: conn=3D-1 op=3D0 = p=3D0</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: oc_check_required entry = (reqStart=3D20151116073936.000002Z,cn=3Dlog), objectClass = "auditSearch"</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 = openldap1 slapd[49483]: oc_check_allowed type "objectClass"</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: = oc_check_allowed type "structuralObjectClass"</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqStart"</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: oc_check_allowed type "reqEnd"</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqType"</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: oc_check_allowed type "reqSession"</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: = oc_check_allowed type "reqAuthzID"</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqDN"</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: oc_check_allowed type "reqResult"</div><div style=3D"margin:= 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqScope"</div><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 openldap1 = slapd[49483]: oc_check_allowed type "reqDerefAliases"</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: = oc_check_allowed type "reqAttrsOnly"</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqFilter"</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 = openldap1 slapd[49483]: oc_check_allowed type "reqAttr"</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">Nov 16 08:39:36 openldap1 slapd[49483]: = oc_check_allowed type "reqEntries"</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D"">Nov = 16 08:39:36 openldap1 slapd[49483]: oc_check_allowed type = "reqTimeLimit"</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D"">Nov 16 08:39:36 = openldap1 slapd[49483]: oc_check_allowed type "reqSizeLimit"</div><div = class=3D""><br class=3D""></div><div class=3D"">The build config = is:</div><div class=3D""><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" class=3D""># This file is = auto-generated by 'make config'.</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" class=3D""># = Options for openldap-server-2.4.42_2</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">_OPTIONS_READ=3Dopenldap-server-2.4.42_2</div><div = style=3D"margin: 0px; font-size: 11px; line-height: normal; font-family: = Menlo;" class=3D"">_FILE_COMPLETE_OPTIONS_LIST=3DACCESSLOG ACI AUDITLOG = BDB COLLECT CONSTRAINT DDS DEBUG DEREF DNSSRV DYNACL DYNAMIC_BACKENDS = DYNGROUP DYNLIST FETCH GSSAPI LMPASSWD MDB MEMBEROF ODBC OUTLOOK PASSWD = PERL PPOLICY PROXYCACHE REFINT RELAY RETCODE RLOOKUPS RWM SASL SEQMOD = SHA2 SHELL SLAPI SMBPWD SOCK SSSVLV SYNCPROV TCP_WRAPPERS TRANSLUCENT = UNIQUE VALSORT</div><div style=3D"margin: 0px; font-size: 11px; = line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DACCESSLOG</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DACI</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DAUDITLOG</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DBDB</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DCOLLECT</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DCONSTRAINT</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DDDS</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DDEBUG</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DDEREF</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DDNSSRV</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DDYNACL</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DDYNAMIC_BACKENDS</div><div style=3D"margin:= 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DDYNGROUP</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DDYNLIST</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DFETCH</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DGSSAPI</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DLMPASSWD</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DMDB</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DMEMBEROF</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DODBC</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DOUTLOOK</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DPASSWD</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DPERL</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DPPOLICY</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DPROXYCACHE</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DREFINT</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DRELAY</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DRETCODE</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DRLOOKUPS</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DRWM</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DSASL</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DSEQMOD</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DSHA2</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DSHELL</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_UNSET+=3DSLAPI</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DSMBPWD</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DSOCK</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DSSSVLV</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DSYNCPROV</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DTCP_WRAPPERS</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DTRANSLUCENT</div><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DUNIQUE</div><div style=3D"margin: 0px; = font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D"">OPTIONS_FILE_SET+=3DVALSORT</div></div><div class=3D""><br = class=3D""></div><div class=3D"">I=E2=80=99ll try the build with your = mentioned branch soon and get in touch again.</div><div class=3D""><br = class=3D""></div><div class=3D"">thanks,</div><div = class=3D"">Chris</div><div class=3D""><br class=3D""></div><div = class=3D""><br class=3D""></div><blockquote type=3D"cite" class=3D""><div = class=3D""><div class=3D""><br class=3D"">thanks,<br class=3D"">Ryan<br = class=3D""><br class=3D"">dn: cn=3Dconfig<br class=3D"">objectClass: = olcGlobal<br class=3D""><br class=3D"">dn: cn=3Dschema,cn=3Dconfig<br = class=3D"">objectClass: olcSchemaConfig<br class=3D""><br = class=3D"">include: file:servers/slapd/schema/core.ldif<br class=3D""><br = class=3D"">include: file:servers/slapd/schema/cosine.ldif<br = class=3D""><br class=3D"">include: = file:servers/slapd/schema/inetorgperson.ldif<br class=3D""><br = class=3D"">include: file:servers/slapd/schema/nis.ldif<br class=3D""><br = class=3D"">include: file:servers/slapd/schema/dyngroup.ldif<br = class=3D""><br class=3D"">include: = file:servers/slapd/schema/ppolicy.ldif<br class=3D""><br class=3D"">dn: = olcDatabase=3D{1}mdb,cn=3Dconfig<br class=3D"">objectClass: = olcMdbConfig<br class=3D"">olcSuffix: dc=3Dexample,dc=3Dnet<br = class=3D"">olcDbDirectory: data.d<br class=3D"">olcRootDN: = cn=3Droot,dc=3Dexample,dc=3Dnet<br class=3D"">olcRootPW: secret<br = class=3D""><br class=3D"">dn: olcDatabase=3D{2}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcMdbConfig<br class=3D"">olcSuffix: = cn=3Daccesslog<br class=3D"">olcDbDirectory: accesslog.d<br class=3D""><br= class=3D"">dn: olcOverlay=3D{0}syncprov,olcDatabase=3D{1}mdb,cn=3Dconfig<= br class=3D"">objectClass: olcSyncProvConfig<br class=3D""><br = class=3D"">dn: olcOverlay=3D{1}dds,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcDDSConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{2}accesslog,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcAccessLogConfig<br class=3D"">olcAccessLogDB: = cn=3Daccesslog<br class=3D""><br class=3D"">dn: = olcOverlay=3D{3}unique,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcUniqueConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{4}ppolicy,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcPPolicyConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{5}refint,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcRefintConfig<br class=3D""><br class=3D"">dn: = olcOverlay=3D{6}memberof,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcMemberOf<br class=3D""><br class=3D"">dn: = olcOverlay=3D{7}dynlist,olcDatabase=3D{1}mdb,cn=3Dconfig<br = class=3D"">objectClass: olcDynamicList<br = class=3D""></div></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_5D31F49F-5A56-4ADF-B31A-D5369C6C72EE-- --Apple-Mail=_372DE61B-D3BA-4719-A35F-AC49091503C9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKQjCCBQAw ggPooAMCAQICEANL7hcft+EGNy/UckJAvSowDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTE0MTExODEyMDAwMFoXDTI0MTExODEy MDAwMFowaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMalux9VgvSlNHIUcmWbX9XqoGjYm4KJT1Ni nHuMzg7a1DIOrxuMy6br2+DrAzSUwYd+UyCoHvkbF4p9AWYSV2heLZwuKyGoVS9TZwl4zdJpGwuT YGy4KBPOH02xiCatRfrQoc6rt5gpVnFs8VYkXacw4G4xc27aoFdMZIt4tcec28bevtMvMaDWgDm1 4DFAToSjzJJJ4hds/vBkHvq6vCWHnU8huslmOQON1BUQuHs6VM/VY7pP8d/oGwR94VymhrV74xb+ XDRV61M88dDXkdgpg/ZZiiEfHMOIL5BTATtRlUGWn1xcinAe4PNKJtzlEbfPSf+PZJALHQOTkUwB QSsCAwEAAaOCAaYwggGiMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMHkGCCsG AQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUF BzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxo dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMB0GA1UdDgQWBBTwIelJd3Ofha4YO+hScBQG7ULu yjAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEAOsIb K/5j3rthtLlHqPx8BbEmICJRm8g9+fXFWB6wXqOynAJBjzEaf8wbTh34mH3sjwj9d/Hb0kQQWrat CbDg/GI71GINnvGgPE13iutENHuOu04pA/wn6j5qHS9I4/raGcP/M9Ls1Ey0jJVLYbbvsoAvl8hH raeCv3zh+YmCEO/RuyMYCZ67cQ/TGFSwMlPrUigAagoGfEE8B6DdZex1Kbgaftu3K9qR7IW1h5uv YqY4FJrbw9GoZIO6vnppmEmgzZ4zNzqmua8bDC0DNGxzm3Y6wpG4dZXo7dqc/YrbuMZlHZuLVVfU 1BS8hulU1O7COb5dxm2xr8AAkX0oaQSx4DCCBTowggQioAMCAQICEA2YtdiSBlHYQKDqqgqWaMww DQYJKoZIhvcNAQELBQAwaTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQ BgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29u YWwgQ0EgMzAeFw0xNTA1MjkwMDAwMDBaFw0xODA1MjkxMjAwMDBaMHkxCzAJBgNVBAYTAkFUMRMw EQYDVQQIEwpWb3JhcmxiZXJnMREwDwYDVQQHEwhEb3JuYmlybjEnMCUGA1UEChMeRmFjaGhvY2hz Y2h1bGUgVm9yYXJsYmVyZyBHbWJIMRkwFwYDVQQDDBBDaHJpc3RpYW4gQsO2c2NoMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzp4fre091WBIlsq2ZvDkwShPkJuGNnXNBlbXxIeR0/rz 1RHTw9pTHFB0vfSK/eVytrPwdr+jQdMVlZ6CuLjmOkV2Ivy1Af9P2aClsYIteht/LfwkmOJZrl3F mjdJ7fOvvxHstMRj6UCuz1/x1ARMaYVxLYZeBcbisDApA+bKikZ88bTeLNGE0n1mXREYZTFlLCqZ b5+UNyae8iLilr7LDSGIeGbN2OH4ZbfWLT8Xuol+Qpcpcitja84G5iyBEx/v1H9qnrIdID4aLZAN 64UiCgKDUPutx+V3BVRJKBiVt4w5LGvXJPG8djApeVTW+YmBmQTdt4we+xCuYtvOPUxtgQIDAQAB o4IBzDCCAcgwHwYDVR0jBBgwFoAU8CHpSXdzn4WuGDvoUnAUBu1C7sowHQYDVR0OBBYEFJaOo3g6 6TwrK6OMuIrmPweKN1SaMAwGA1UdEwEB/wQCMAAwGAYDVR0RBBEwD4ENYm9lc2NoQGZodi5hdDAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDow OAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25hbENB My5jcmwwcwYIKwYBBQUHAQEEZzBlMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5j b20wPQYIKwYBBQUHMAKGMWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25h bENBMy5jcnQwDQYJKoZIhvcNAQELBQADggEBAH3jDh6ahP08DrzZ4HrSvyCFr/Jnu2s/7F77HZuH jf77zODdRDCpoKj1TfOQE7gTA9nW/dpuOzSVhNauWisD6lF1tSLXnFDlkUaQmg7MzE1laV4anMb2 WGU5sKHawq4FH1SQyS1sjuilmc69Y6gRFRSx2XZ3CiG+3drAiV1DVpYvLc4Yd4Izw1RsayxnMxaw uX+RUngMgtw92b1bmiQM1DlJq+g6sFoz7iUdMEReX+zapXCDtxGb65v2LjB1w35CVu5D6YW38JxF qQ7CeFdFpd3NEIcV6eykiaX5P55E2SX0wY+kpFvm64F5lAPqlc28qtKv560BiN7W9eJUotHyUA0x ggMlMIIDIQIBATB9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYD VQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFs IENBIDMCEA2YtdiSBlHYQKDqqgqWaMwwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTE2MDc0NjQxWjAjBgkqhkiG9w0BCQQxFgQUdDTy iCcmzI7kA8sz0asEI+x91m8wgYwGCSsGAQQBgjcQBDF/MH0waTELMAkGA1UEBhMCTkwxFjAUBgNV BAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0w GwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMwIQDZi12JIGUdhAoOqqCpZozDCBjgYLKoZIhvcN AQkQAgsxf6B9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENB IDMCEA2YtdiSBlHYQKDqqgqWaMwwDQYJKoZIhvcNAQEBBQAEggEAXEMDDJnvbE4qWaB2v8Ij/Fs1 H3Od4FYhgSvEvOf+1Yox/Sv3RVJy7Yr4zA5vfymAqF5bbNrjj6KKdz1+/ssRFiUmaIw/7SyWs8UG 6mM71M0O66jZ6g60UyzqSDNSwBIk5VU2gPACQLkHQ0ikw6SB/UPMMZzQU6HwC1JupxIyPpz2GMmj kSNRCkYy1kwPDTQSDQebSL9Xxl/svBrWhHRREWC9F0qvD/0uzO2tBPxUHOHPEoFFjXnymzKy3rB2 CZ76gGYN7g7blLGPd8HG5s5NPg/mBZVJcg+vTeBClQpkCZXTK/A3hwG1Ouf15gQ98Wr/60fPCOT0 nPzdZtKqHEWLbQAAAAAAAA== --Apple-Mail=_372DE61B-D3BA-4719-A35F-AC49091503C9--

1 0

Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by hyc＠symas.com 13 Nov '15

13 Nov '15

quanah(a)zimbra.com wrote: > --On Friday, November 13, 2015 4:02 AM +0000 Steven Lang > <Steven.Lang(a)hgst.com> wrote: > >> I tested with the latest mdb.master, commit >> c6d908075ee5bdd1270fce6ec8d5d8df9b168021. > > Great, thanks for the confirmation. Fixed now in git, thanks for the report. -- -- 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#8307) startup failed with DDS enabled
by ryan＠openldap.org 13 Nov '15

13 Nov '15

Hello Christian, On Thu, Nov 12, 2015 at 12:54:09PM +0000, boesch(a)fhv.at wrote: >I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: >olcOverlay={0}syncprov.ldif >olcOverlay={1}dds.ldif >olcOverlay={2}accesslog.ldif >olcOverlay={3}unique.ldif >olcOverlay={4}ppolicy.ldif >olcOverlay={5}refint.ldif >olcOverlay={6}memberof.ldif >olcOverlay={7}dynlist.ldif >started, everything is fine. > >Then I added an empty base tree: >dn: dc=example,dc=net >objectClass: dcObject >objectClass: organization >o: ORG >dc: example > >dn: cn=admin,dc=example,dc=net >objectClass: organizationalRole >cn: LDAP Admin >cn: admin > >dn: o=org,dc=example,dc=net >o: ORG >objectClass: organization >objectClass: top I tried to reproduce your problem under openldap 2.4.42 on Linux (Debian), using the attached config and the data LDIF you provided, but didn't observe any problems. Would you please provide more details about the configuration that causes the problem, including the options specified when you built OpenLDAP, and any applicable log messages? It would also be good to know if you can reproduce the problem using current sources from git branch OPENLDAP_REL_ENG_2_4, which is the 2.4.43 release candidate. thanks, Ryan dn: cn=config objectClass: olcGlobal dn: cn=schema,cn=config objectClass: olcSchemaConfig include: file:servers/slapd/schema/core.ldif include: file:servers/slapd/schema/cosine.ldif include: file:servers/slapd/schema/inetorgperson.ldif include: file:servers/slapd/schema/nis.ldif include: file:servers/slapd/schema/dyngroup.ldif include: file:servers/slapd/schema/ppolicy.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcSuffix: dc=example,dc=net olcDbDirectory: data.d olcRootDN: cn=root,dc=example,dc=net olcRootPW: secret dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig olcSuffix: cn=accesslog olcDbDirectory: accesslog.d dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig dn: olcOverlay={1}dds,olcDatabase={1}mdb,cn=config objectClass: olcDDSConfig dn: olcOverlay={2}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig olcAccessLogDB: cn=accesslog dn: olcOverlay={3}unique,olcDatabase={1}mdb,cn=config objectClass: olcUniqueConfig dn: olcOverlay={4}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcPPolicyConfig dn: olcOverlay={5}refint,olcDatabase={1}mdb,cn=config objectClass: olcRefintConfig dn: olcOverlay={6}memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf dn: olcOverlay={7}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcDynamicList

1 0

Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by quanah＠zimbra.com 13 Nov '15

13 Nov '15

--On Friday, November 13, 2015 4:02 AM +0000 Steven Lang <Steven.Lang(a)hgst.com> wrote: > I tested with the latest mdb.master, commit > c6d908075ee5bdd1270fce6ec8d5d8df9b168021. Great, thanks for the confirmation. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by Steven.Lang＠hgst.com 13 Nov '15

13 Nov '15

I tested with the latest mdb.master, commit c6d908075ee5bdd1270fce6ec8d5d8d= f9b168021. HGST E-mail Confidentiality Notice & Disclaimer: This e-mail and any files transmitted with it may contain confidential or l= egally privileged information of HGST and are intended solely for the use o= f the individual or entity to which they are addressed. If you are not the = intended recipient, any disclosure, copying, distribution or any action tak= en or omitted to be taken in reliance on it, is prohibited. If you have re= ceived this e-mail in error, please notify the sender immediately and delet= e the e-mail in its entirety from your system.

1 0

Re: (ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by quanah＠zimbra.com 13 Nov '15

13 Nov '15

--On Friday, November 13, 2015 3:54 AM +0000 steven.lang(a)hgst.com wrote: > Full_Name: Steven Lang > Version: LMDB 0.9.16 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/steven-lang-151112.tar.gz > Submission from: (NULL) (50.76.49.9) > > > This seems to be a variation on ITS#8258 - the base cause is the same; an > mdb_cursor_del causes the tree to grow in depth, the cursor is not > updated with the new depth, and the next cursor op on the cursor asserts. > > I have a DB and short C file which triggers the assert in a simple manner. Hi Steve, Just wanted to confirm you've verified this occurs with the 0.9.17 release candidate? Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8310) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by steven.lang＠hgst.com 13 Nov '15

13 Nov '15

Full_Name: Steven Lang Version: LMDB 0.9.16 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/steven-lang-151112.tar.gz Submission from: (NULL) (50.76.49.9) This seems to be a variation on ITS#8258 - the base cause is the same; an mdb_cursor_del causes the tree to grow in depth, the cursor is not updated with the new depth, and the next cursor op on the cursor asserts. I have a DB and short C file which triggers the assert in a simple manner.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs