- openldap-bugs - openldap.org

(ITS#7591) back-meta modify operation not sending result to client
by jorge.perez.burgos＠ericsson.com 14 May '13

14 May '13

Full_Name: Jorge Perez Burgos Version: 2.4.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) Right now when sending bulk traffic trough back-meta and killing the slapds receiving the proxy traffic, it can be seen that a very few modify operations are not receiving the result of the operations, looking at the code it seems the same for the add and delete operation. Basically when ldap_modify_ext returns an errno it seems that is not properly handle afterwards.

1 0

Re: (ITS#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 13 May '13

13 May '13

I wrote: > OTOH if you add a bunch of slightly smaller nodes, mdb will put > most of them in separate pages anyway without MDB_APPEND. ...because mdb_page_split() has been wasteful since 48ef27b6f5c804eca6a9 "ITS#7385 fix mdb_page_split (again)". When a txn put()s ascending keys with nodes of the same size, the new item goes in the fullest page. E.g. put data size 1010 with 'int' keys 1,2,3... to an MDB_INTEGERKEY DB. As the txn progresses, (page: #key #key...) get distributed thus: Page 2: #1. Page 2: #1 #2. Page 2: #1 #2 #3. Page 2: #1. Page 3: #2 #3 #4. Page 2: #1. Page 3: #2. Page 5: #3 #4 #5. Page 2: #1. Page 3: #2. Page 5: #3. Page 6: #4 #5 #6. 2/3 wasted space. Descending put() work better: Page 2: #6. Page 2: #5 #6. Page 2: #4 #5 #6. Page 2: #3 #4. Page 3: #5 #6. Page 2: #2 #3 #4. Page 3: #5 #6. Page 2: #2 #1. Page 3: #5 #6. Page 5: #3 #4. Ascending put() with datasize 1348, so only 2 nodes fit in a page: Page 2: #1. Page 2: #1 #2. Page 2: #1. Page 3: #2 #3. Page 2: #1. Page 3: #2. Page 5: #3 #4. Half of the space is wasted. Descending order does not help. page_split() cannot know which split is best in this case. But it'll help to guess that the next put() key sometimes will be near this one, and ensure that the node with the new key will be the smallest. That will also avoid touching the old page when the nodes are that large, since the "split" will keep all old nodes in the old page. Trying a simpler patch for this one: > Nodes of size MDB_env.me_nodemax-1 do not go in overflow pages, > but are too big for two of them to fit in the same page. (...) Let mdb_env_open2() round me_nodemax down to an odd number: env->me_nodemax = (((env->me_psize - PAGEHDRSZ) / MDB_MINKEYS) - 1) | 1; Then a leaf page with just 1 node can always get another one, since mdb_node_add() will always put too big items in overflow pages. In a DB newer than this patch, anyway... Maybe mdb_cursor_put() should use the value from before 'offset += offset & 1;' in next line's compare with me_nodemax: @@ -5128,5 +5128,6 @@ } + i = offset; offset += offset & 1; if (NODESIZE + sizeof(indx_t) + NODEKSZ(leaf) + NODEDSZ(leaf) + - offset >= mc->mc_txn->mt_env->me_nodemax) { + i >= mc->mc_txn->mt_env->me_nodemax) { /* yes, convert it */ This passes 'make test', with or without changing cursor_put(). But I still don't quite know what I'm doing - otherwise my LEAFSIZE patch would have worked too. -- Hallvard

1 0

(ITS#7590) admin24 incorrectly says "back-bdb" is recommended
by quanah＠OpenLDAP.org 13 May '13

13 May '13

Full_Name: Quanah Gibson-Mount Version: 2.4.35 OS: linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) H3: Overview The {{bdb}} backend to {{slapd}}(8) is the recommended primary backend for a normal {{slapd}} database. Which stopped being true with OpenLDAP 2.3 IIRC, which is when back-hdb was made the recommended backend.

1 0

Re: (ITS#7588) SSSVLV can cause segmentation fault
by hyc＠symas.com 13 May '13

13 May '13

kevinanties(a)gmail.com wrote: > Full_Name: kevin > Version: 2.4.35 > OS: ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.64.130.126) > > > The problem is due to double free pointers in send_page() and free_sort_op() > function. > > In send_page function, some nodes of so_tree have been free by ch_free and > ber_memfree function. If a client suddenly aborts the connection, free_sort_op > function will be called. In free_sort_op function, tavl_free() will be called > and it try to free the nodes of so_tree. Hoverer, some of nodes had already free > before and segmentation resulted. > > A possible solution is to to check whether it is a paged request in free_sort_op > function. If yes, continuous to free the next node of so_tree but not free > previous node. Thanks for the report. The fix is simpler than that, and now in git 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#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 10 May '13

10 May '13

Full_Name: Hallvard B Furuseth Version: 2.4.35 OS: Linux x86_64 URL: Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard Nodes of size MDB_env.me_nodemax-1 do not go in overflow pages, but are too big for two of them to fit in the same page. Because: - LEAFSIZE() does not round up to a factor of 2. - MDB_env.me_nodemax is described as /** Max size of a node on a page */ (i.e. non-overflow page), but actually it's the minimum node size which mdb_node_add() *will* put in an overflow page. I don't see a reason to treat nodes of size 2k-1 and 2k differently when seen "from the outside", so I think LEAFSIZE should have been #define LEAFSIZE(k, d) ((1 + NODESIZE + (k)->mv_size + (d)->mv_size) & -2) Also mdb_leaf_size(): sz = LEAFSIZE(key, data); if (sz >= env->me_nodemax) sz = (1 + NODESIZE + sizeof(pgno_t) + key->mv_size) & -2; return sz + sizeof(indx_t); and a corresponding fix in mdb_node_add(). Those changes crash test001. I don't know what else would need fixing. Subpage sizes for one thing. OTOH if you add a bunch of slightly smaller nodes, mdb will put most of them in separate pages anyway without MDB_APPEND. To keep down rebalancing when adding nodes in the middle? Or is this another bug? So I don't know if more than the me_nodemax doc a fix. And maybe a rename to something which fits what it does. ...and also the doc of mdb_branch_size(). "Sizes are always rounded up to an even number of bytes, to guarantee 2-byte alignment" happens somewhere, but not in mdb_branch_size() which happily returns uneven sizes. But it works fine since it's only used as SIZELEFT()<mdb_branch_size() where SIZELEFT() does return an even size. Rounding branch_size up would make no difference.

1 0

(ITS#7588) SSSVLV can cause segmentation fault
by kevinanties＠gmail.com 09 May '13

09 May '13

Full_Name: kevin Version: 2.4.35 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.64.130.126) The problem is due to double free pointers in send_page() and free_sort_op() function. In send_page function, some nodes of so_tree have been free by ch_free and ber_memfree function. If a client suddenly aborts the connection, free_sort_op function will be called. In free_sort_op function, tavl_free() will be called and it try to free the nodes of so_tree. Hoverer, some of nodes had already free before and segmentation resulted. A possible solution is to to check whether it is a paged request in free_sort_op function. If yes, continuous to free the next node of so_tree but not free previous node.

1 0

(ITS#7587) slapd crashes when using pcache overlay applied to a translucent proxy
by amoneger＠cisco.com 09 May '13

09 May '13

Full_Name: Alex Version: 2.4.35 OS: Centos 6.3 (2.6.32-279.el6.x86_64 #1 SMP) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.103.25.102) When using the pcache overlay over a translucent proxy, the slapd daemon crashes after the second LDAP request which misses the cache. For example, the following requests will trigger the issue. The important part is to miss the cache. Assuming nothing is cached for the aaaa and bbbb uid, the following request will trigger the issue (172.16.206.156 being the openldap server): ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=aaaa" uid st ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=bbbb" uid st Whether aaaa and bbbb exist or not does not matter. The following config is used: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema moduleload pcache.la moduleload translucent.la database bdb suffix "o=xxxx" #checkpoint 1024 15 rootdn "uid=amoneger,ou=yyyy,o=xxxx" overlay translucent translucent_local uidNumber,gidNumber,homeDirectory,loginShell translucent_strict rootdn "uid=amoneger,ou=yyyy,o=xxxx" uri ldap://zzzz/ #tls ldaps tls_reqcert=demand tls_cacert=/usr/local/etc/openldap/certs/Cisco_ca_chain overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * pcacheTemplate (uid=) 0 3600 pcacheBind (uid=) 0 1800 sub ou=yyyy,o=xxxx pcacheOffline TRUE pcachePersist TRUE pcacheValidate FALSE directory /var/cache/ldap cachesize 1000 index pcacheQueryid eq The crash seems to be caused by a SIGABRT which is raised by libc free() due to a double free. Here is the traceback: Breakpoint 2, 0x000000312aa33f10 in abort () from /lib64/libc.so.6 (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x000000312aa328a5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x000000312aa328a5 in raise () from /lib64/libc.so.6 #1 0x000000312aa34085 in abort () from /lib64/libc.so.6 #2 0x000000312aa707b7 in __libc_message () from /lib64/libc.so.6 #3 0x000000312aa760e6 in malloc_printerr () from /lib64/libc.so.6 #4 0x000000000042391e in do_search (op=0x7f135c000b80, rs=0x7f1366764930) at search.c:263 #5 0x0000000000421449 in connection_operation (ctx=0x7f1366764a90, arg_v=0x7f135c000b80) at connection.c:1155 #6 0x0000000000421c25 in connection_read_thread (ctx=0x7f1366764a90, argv=<value optimized out>) at connection.c:1291 #7 0x00000000005601f0 in ldap_int_thread_pool_wrapper (xpool=0x1f42770) at tpool.c:688 #8 0x000000312b207851 in start_thread () from /lib64/libpthread.so.0 #9 0x000000312aae890d in clone () from /lib64/libc.so.6 I was unable to track back the particular piece of code triggering the double free, but the same pointer p is freed twice by ber_memfree_x() in memory.c: (gdb) delete 3 (gdb) break search.c:263 Breakpoint 4 at 0x5645df: file search.c, line 263. (gdb) c Continuing. Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); (gdb) s slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 493 { (gdb) s 498 if (!ptr) (gdb) s 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s 649 } (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 127 { (gdb) s 128 if( p == NULL ) { (gdb) s 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { (gdb) s 160 } (gdb) s 152 free( p ); (gdb) print p $1 = (void *) 0x1d64a10 (gdb) x/10x p 0x1d64a10: 0x00000001 0x00000000 0x005ffd31 0x00000000 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 0x1d64a30: 0x00000000 0x00000000 (gdb) c Continuing. [New Thread 0x7fa561994700 (LWP 5823)] Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); (gdb) s slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 493 { (gdb) s 498 if (!ptr) (gdb) s 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s 649 } (gdb) s 502 ber_memfree_x(ptr, NULL); (gdb) s ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 127 { (gdb) s 128 if( p == NULL ) { (gdb) s 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { (gdb) s 160 } (gdb) s 152 free( p ); (gdb) print P No symbol "P" in current context. (gdb) print p $2 = (void *) 0x1d64a10 (gdb) x/10x p 0x1d64a10: 0x00000000 0x00000000 0x005ffd31 0x00000000 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 0x1d64a30: 0x00000000 0x00000000 So the same pointer is being freed twice by the 2 connections which miss the cache. I'm unable to figure out who is responsible for that call though, but the same op->ors_attrs is freed by do_search(): if ( op->ors_attrs != NULL ) { op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); Parameters seem correct in both cases: (gdb) print op->o_hdr->oh_tmpmfuncs->bmf_free $12 = (BER_MEMFREE_FN *) 0x4733f0 <slap_sl_free> (gdb) print op->o_request.oq_search.rs_attrs $15 = (AttributeName *) 0x1f85a10 The call is done via connection_operation(), but that code part is a bit above my head, so I'm unable to track this further. I thought this could be due to a threading problem, but building slapd with --with-threads=no does not make a difference. I tried uploading the core dump to your ftp server, but seems like there is an issue with ftp.openldap.org [root@centos63 tmp]# ftp ftp.openldap.org Trying 204.152.186.57... Connected to ftp.openldap.org (204.152.186.57). 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:cisco): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> binary 200 Type set to I. ftp> put core-slapd-6-55-55-26548-1368063267 local: core-slapd-6-55-55-26548-1368063267 remote: core-slapd-6-55-55-26548-1368063267 227 Entering Passive Mode (204,152,186,57,242,33) 553 core-slapd-6-55-55-26548-1368063267: No space left on device. Let me know if you need anything. I can provide further debugs or cores. I'm also happy to try things out. Cheers, Alex

1 0

Re: (ITS#7586) MDB tests crash
by hyc＠symas.com 08 May '13

08 May '13

josephg(a)gmail.com wrote: > Full_Name: Joseph Gentle > Version: Gitorius master 2d6aed7 > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.1.123.217) > > > Using the latest version of lmdb in https://gitorious.org/mdb/mdb (2d6aed7), I > went into the liblmdb directory, ran make then ran the tests. > > All tests crash with Segmentation Fault. Problem can be reproduced compiling > with gcc or clang, and gcc on linux. This is normal behavior. The tests do no error checking. The tests are not meant to be run blindly, you are expected to read their source code. Ordinarily I only "run" them by single-stepping under gdb so I can examine the library state at each point. Closing this ITS. > env->me_txns is NULL in mdb.c line 1840. > > > Process 63426 stopped > * thread #1: tid = 0x1c03, 0x0000000100001a2d > mtest`mdb_txn_renew0(txn=0x0000000100103de0) + 125 at mdb.c:1840, stop reason = > EXC_BAD_ACCESS (code=1, address=0x28) > frame #0: 0x0000000100001a2d mtest`mdb_txn_renew0(txn=0x0000000100103de0) + > 125 at mdb.c:1840 > 1837 } else { > 1838 LOCK_MUTEX_W(env); > 1839 > -> 1840 txn->mt_txnid = env->me_txns->mti_txnid; > 1841 txn->mt_toggle = txn->mt_txnid & 1; > 1842 txn->mt_next_pgno = env->me_metas[txn->mt_toggle]->mm_last_pg+1; > 1843 txn->mt_txnid++; > (lldb) p env > (MDB_env *) $0 = 0x0000000100103c70 > (lldb) p env->me_txns > (MDB_txninfo *) $1 = 0x0000000000000000 > > -- -- 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#7586) MDB tests crash
by josephg＠gmail.com 08 May '13

08 May '13

Full_Name: Joseph Gentle Version: Gitorius master 2d6aed7 OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.1.123.217) Using the latest version of lmdb in https://gitorious.org/mdb/mdb (2d6aed7), I went into the liblmdb directory, ran make then ran the tests. All tests crash with Segmentation Fault. Problem can be reproduced compiling with gcc or clang, and gcc on linux. env->me_txns is NULL in mdb.c line 1840. Process 63426 stopped * thread #1: tid = 0x1c03, 0x0000000100001a2d mtest`mdb_txn_renew0(txn=0x0000000100103de0) + 125 at mdb.c:1840, stop reason = EXC_BAD_ACCESS (code=1, address=0x28) frame #0: 0x0000000100001a2d mtest`mdb_txn_renew0(txn=0x0000000100103de0) + 125 at mdb.c:1840 1837 } else { 1838 LOCK_MUTEX_W(env); 1839 -> 1840 txn->mt_txnid = env->me_txns->mti_txnid; 1841 txn->mt_toggle = txn->mt_txnid & 1; 1842 txn->mt_next_pgno = env->me_metas[txn->mt_toggle]->mm_last_pg+1; 1843 txn->mt_txnid++; (lldb) p env (MDB_env *) $0 = 0x0000000100103c70 (lldb) p env->me_txns (MDB_txninfo *) $1 = 0x0000000000000000

1 0

(ITS#7585) LDAPI with GSSAPI does not work if SASL_NOCANON=on
by sbose＠redhat.com 07 May '13

07 May '13

Full_Name: Sumit Bose Version: 2.4.34 OS: Fedora 18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.72.5.29) When using LDAPI with GSSAPI and SASL_NOCANON=on I get the following error: # LDAPSASL_NOCANON=on ldapsearch -H 'ldapi://%2fvar%2frun%2fslapd-IPA18-DEVEL.socket' -Y GSSAPI -s base dn SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/SOCKET(a)IPA18.DEVEL not found in Kerberos database) This happens because if SASL_NOCANON=on the "host" part from the LDAP URI is used as SASL host, which just contains a local path in the LDAPI case. The related Fedora issue is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=960222 which also contains a patch for the issue https://bugzilla.redhat.com/attachment.cgi?id=744866 .

1 0

Re: (ITS#7584) slapd ignores loglevel packets, ber and parse.
by fumiyas＠osstech.jp 07 May '13

07 May '13

At Tue, 7 May 2013 10:39:47 GMT, hyc(a)symas.com wrote: > > "slapd -s 'packets,ber,parse'" does not send specified log to syslog. > > slapd ignores "loglevel packets ber parse" in slapd.conf too. > > > > "slapd -d 'packets,ber,parse'" sends specified log to stderr as expected. > > > This works as intended. syslog is too slow to keep up with this output so it's > only provided for debug. Some syslog implementation have "no sync" option (e.g. rsyslog version 3.12.4+ has $ActionFileEnableSync global option and defaults to "off") and is reasonably fast in some situation. Anyway, if this issue is a specification (limitation) of slapd, slapd(8) and slapd.conf(5) manpages should be fixed to describe it. Thanks. -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0

Re: (ITS#7584) slapd ignores loglevel packets, ber and parse.
by hyc＠symas.com 07 May '13

07 May '13

fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (240b:10:2640:bf0:222:5fff:fe95:3cda) > > > "slapd -s 'packets,ber,parse'" does not send specified log to syslog. > slapd ignores "loglevel packets ber parse" in slapd.conf too. > > "slapd -d 'packets,ber,parse'" sends specified log to stderr as expected. > This works as intended. syslog is too slow to keep up with this output so it's only provided for debug. -- -- 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#7584) slapd ignores loglevel packets, ber and parse.
by fumiyas＠osstech.co.jp 07 May '13

07 May '13

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (240b:10:2640:bf0:222:5fff:fe95:3cda) "slapd -s 'packets,ber,parse'" does not send specified log to syslog. slapd ignores "loglevel packets ber parse" in slapd.conf too. "slapd -d 'packets,ber,parse'" sends specified log to stderr as expected.

1 0

(ITS#7583) ldap_init_fd() does not work with LDAP_PROTO_UDP
by stefw＠redhat.com 03 May '13

03 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Submission from: (NULL) (77.3.95.123) The ldap_init_fd() function does not work with UDP sockets (ie: LDAP_PROTO_UDP passed in as the proto argument). Later uses of the LDAP connection returned fail unceremoniously. This patch fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Some test code to exercise and demonstrate the problem. The code does not actually wait for a UDP response, but should exit with a zero return code when successful. http://fedorapeople.org/~stefw/patches/openldap-02/frob-cldap-initfd.c $ gcc -o frob-cldap-initfd -Wall -lldap -llber frob-cldap-initfd.c $ ./frob-cldap-initfd frob-cldap-initfd: ldap_search_ext: -1 The above result occurs before the patch is applied.

1 0

(ITS#7582) Access to uninitialized memory when sending cldap packet
by stefw＠redhat.com 02 May '13

02 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Submission from: (NULL) (77.3.95.123) When sending a cldap (UDP) packet, like a search request, uninitialized memory is accessed. This shows up in valgrind like this: ==31445== Conditional jump or move depends on uninitialised value(s) ==31445== at 0x36632244E6: ldap_send_server_request (request.c:377) ==31445== by 0x36632247C2: ldap_send_initial_request (request.c:166) ==31445== by 0x36632142F8: ldap_pvt_search (search.c:128) ==31445== by 0x366321454F: ldap_search_ext (search.c:69) ==31445== by 0x400838: main (in /data/projects/openldap/frob-cldap-search) ==31445== This is due to parsing the resulting packet to pull out a requestDN. UDP packets have different BER layout, and therefore the assumptions made when parsing the outgoing request are invalid. It does not seem necessary to track the request DN for UDP packets. The linked patch disables this code path for UDP packets. Patch which fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Test code for the issue: http://fedorapeople.org/~stefw/patches/openldap-01/frob-cldap-search.c Note that the test code doesn't detect the issue on its own (or do anything useful). Use valgrind to detect the issue: $ gcc -o frob-cldap-search -Wall -lldap -llber frob-cldap-search.c $ valgrind ./frob-cldap-search

1 0

(ITS#7581) adding meta backend in cn=config with ldapadd / ldapmodify
by dcoutadeur＠linagora.com 02 May '13

02 May '13

Full_Name: dcoutadeur Version: 2.4.35 / git OS: openSuse 11.3 x86_64 URL: Submission from: (NULL) (80.67.162.201) I apologize in advance if this is not considered as a bug, but I thought this ticket should help the community anyway... The problem is that it seems impossible to add meta backend in cn=config thanks to ldapadd / ldapmodify clients. I thought the major interest for cn=config was precisely to let administrators change the configuration in a remote way, but maybe new database configuration is an exception ? Here are the technical elements : Content of meta.ldif : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com debug information in slapd, after the command : ldapadd -H "ldap://localhost:389" -D "cn=config" -W -f meta.ldif 518220f1 conn=1002 op=1 ADD dn="olcDatabase={2}meta,cn=config" 518220f1 meta_back_db_open: no targets defined 518220f1 backend_startup_one (type=meta, suffix="dc=foo,dc=com"): bi_db_open failed! (1) 518220f1 olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=com)! However, I can add this entry via slapadd : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbOnErr: continue olcDbPseudoRootBindDefer: TRUE olcDbSingleConn: FALSE olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbBindTimeout: 100000 olcDbCancel: abandon olcDbChaseReferrals: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbNretries: 10 olcDbProtocolVersion: 3 olcDbRebindAsUser: FALSE olcDbSessionTrackingRequest: FALSE olcDbTFSupport: no structuralObjectClass: olcMetaConfig entryUUID: cf8afa3a-a284-4ac8-b60e-9431b0807ed4 creatorsName: cn=config createTimestamp: 20130430162302Z entryCSN: 20130430162302.509672Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130430162302Z The fact is I don't have a metatarget configuration, because this is a subentry of olcDatabase={2}meta,cn=config, thus I must add the latter entry first. Also notice that I can't do a slapadd with just the meta configuration. (the ldif above). If I do this, I have an error : slapadd: could not add entry dn="olcDatabase={2}meta,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed I had to make a backup of the full configuration, and then add the meta configuration and import the resulting file.

1 0

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 30 Apr '13

30 Apr '13

Re, and here are more details w/ backtrace after installing slapd-dbg : 517f9323 bdb_modify_internal: 0x000002fd: cn=g1,ou=groups,dc=example,dc=org Breakpoint 1, modify_add_values (e=e@entry=0x7ffff0f507e0, mod=mod@entry=0x7ffff87da880, permissive=1, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41 41 in ../../../../servers/slapd/mods.c (gdb) p *mod $10 = {sm_desc = 0x7ffff832bb20, sm_values = 0x7ffff8765760, sm_nvalues = 0x7ffff87da8c0, sm_numvals = 1, sm_op = 0, sm_flags = 1, sm_type = {bv_len = 6, bv_val = 0x7ffff82ee5c0 "member"}} (gdb) p *(mod->sm_values) $11 = {bv_len = 0, bv_val = 0x0} (gdb) bt #0 modify_add_values (e=e@entry=0x7ffff0f507e0, mod=mod@entry=0x7ffff87da880, permissive=1, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41 #1 0x00007ffff32110fb in hdb_modify_internal (op=op@entry=0x7ffff0f50ca0, tid=0x7ffff82db2d0, modlist=<optimized out>, e=e@entry=0x7ffff0f507e0, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at modify.c:137 #2 0x00007ffff3211df3 in hdb_modify (op=0x7ffff0f50ca0, rs=0x7ffff0f50c30) at modify.c:638 #3 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50ca0, rs=0x7ffff0f50c30, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #4 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50ca0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #5 0x00007ffff2be53e7 in autogroup_add_members_from_filter (op=op@entry=0x7ffff82da400, e=<optimized out>, age=0x7ffff82f8ef0, agf=agf@entry=0x7ffff87daea0, modify=modify@entry=1) at autogroup.c:519 #6 0x00007ffff2be5b00 in autogroup_add_group (op=op@entry=0x7ffff82da400, agi=agi@entry=0x7ffff832b8c0, agd=agd@entry=0x7ffff832b910, e=0x7ffff8503b98, e@entry=0x0, ndn=ndn@entry=0x7ffff82da438, scan=scan@entry=1, modify=modify@entry=1) at autogroup.c:667 #7 0x00007ffff2be6c91 in autogroup_response (op=0x7ffff82da400, rs=<optimized out>) at autogroup.c:1213 #8 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237 #9 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:507 #10 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:582 #11 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860 #12 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at modify.c:749 #13 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82da400, rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #14 0x00007ffff7f8031b in over_op_func (op=0x7ffff82da400, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #15 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303 #16 0x00007ffff7f2c42d in do_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177 #17 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82da400) at ../../../../servers/slapd/connection.c:1150 #18 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 So sm_values looks empty at that point... Note that i've also tried with the default groupOfNames/member objects, instead of posixGroup/memberOf. Same symptoms. -- Landry Breuil

1 0

(ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 30 Apr '13

30 Apr '13

Full_Name: Landry Breuil Version: 2.4.31 OS: Debian sid URL: Submission from: (NULL) (194.214.164.50) using slapd 2.4.31 on debian sid (with cn=config), i have an abort triggered by the following configuration : I'm using autogroup module/overlay to automatically generate posixGroup objects from various filters on my ou=people branch : dn: cn=SV_REVIEWER,ou=groups,dc=example,dc=org objectClass: labeledURIObject objectClass: posixGroup gidNumber: 10 labeledURI: ldap:///ou=people,dc=example,dc=org?uid?one?(&(objectClass=inetOrgPerson)(o=myorg)) So far, that works fine. Problem is, with that configuration i'm getting memberUid values containing only uid attributes. Now that i want to use memberOf overlay to get the reverse membership, i realize that i need my posixGroup to have DN-valued memberUid attrs. I tried using a labeledURI specifying that i want a DN returned : labeledURI: ldap:///ou=people,dc=example,dc=org?dn?one?(&(objectClass=inetOrgPerson)(o=myorg)) This errors out in autogroup_add_group after parsing the filter with : 517e6bc0 autogroup_add_group: unable to find AttributeDescription "dn". That, i can understand - a dn is not an attribute per se. Tried using a labeledURI without attr specification (as, from what i understand unless mistaken, should return the object, or its dn ?) labeledURI: ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg)) But this results in the following assertion (w/ debug trace) : 517e70d5 ==> autogroup_add_group <cn=SV_REVIEWER,ou=groups,dc=example,dc=org> ldap_url_parse_ext(ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg))) 517e70d5 >>> dnPrettyNormal: <ou=people,dc=example,dc=org> 517e70d5 <<< dnPrettyNormal: <ou=people,dc=example,dc=org>, <ou=people,dc=example,dc=org> put_filter: "(&(objectClass=inetOrgPerson)(o=myorg))" put_filter: AND put_filter_list "(objectClass=inetOrgPerson)(o=myorg)" put_filter: "(objectClass=inetOrgPerson)" put_filter: simple put_simple_filter: "objectClass=inetOrgPerson" put_filter: "(o=myorg)" put_filter: simple put_simple_filter: "o=myorg" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: 517e70d5 ==> autogroup_add_members_from_filter <cn=SV_REVIEWER,ou=groups,dc=example,dc=org> 517e70d5 => hdb_search 517e70d5 bdb_dn2entry("ou=people,dc=example,dc=org") 517e70d5 search_candidates: base="ou=people,dc=example,dc=org" (0x00000005) scope=1 517e70d5 => hdb_dn2idl("ou=people,dc=example,dc=org") 517e70d5 => bdb_equality_candidates (objectClass) 517e70d5 => key_read 517e70d5 <= bdb_index_read: failed (-30987) 517e70d5 <= bdb_equality_candidates: id=0, first=0, last=0 517e70d5 => bdb_equality_candidates (objectClass) 517e70d5 => key_read 517e70d5 <= bdb_index_read 738 candidates 517e70d5 <= bdb_equality_candidates: id=738, first=6, last=763 517e70d5 => bdb_equality_candidates (o) 517e70d5 <= bdb_equality_candidates: (o) not indexed 517e70d5 bdb_search_candidates: id=437 first=6 last=763 517e70d5 ==> autogroup_member_search_modify_cb <uid=user1,ou=people,dc=example,dc=org> 517e70d5 ==> autogroup_member_search_modify_cb <uid=user2,ou=people,dc=example,dc=org> 517e70d5 hdb_search: 288 does not match filter .... 517e70d5 hdb_search: 762 does not match filter 517e70d5 hdb_search: 763 does not match filter 517e70d5 send_ldap_result: conn=1000 op=8 p=3 517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org") 517e70d5 bdb_entry_get: rc=0 517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org") 517e70d5 bdb_modify_internal: 0x000002e0: cn=SV_REVIEWER,ou=groups,dc=example,dc=org slapd: ../../../../servers/slapd/mods.c:64: modify_add_values: Assertion `mod->sm_numvals == i' failed. How can i achieve the desired setup ? Fix autogroup to allow asking for a dn, or try to see why slapd blows in modify_add_values when not asking for a specific attribute ?

1 0

Re: (ITS#7579) back-sql does not update DIT when DB is updated
by masarati＠aero.polimi.it 29 Apr '13

29 Apr '13

On 04/29/2013 02:33 PM, mail(a)benjamin-behringer.de wrote: > Full_Name: Benjamin Behringer > Version: 2.4.35 > OS: Ubuntu 12.04 64bit > URL: > Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867) > > > Hi, > > I'm using OpenLDAP and back-sql to make the information, stored in a MySQL > Database, available over LDAP (for Authentication purposes). Unfortunately, when > I insert or update an entry in the Database, the DIT is not updated. In > contrast, a delete on the ldap_entries table will cause slapd to reflect the DB > change in the DIT. The issue only occurs, when the DIT has already been loaded, > and the subtree you will make the change to has already been read at least once. > If you restart slapd, the changes are reflected. > > Software Versions: > > Distribution: Ubuntu 12.04 64bit > MySQL: 5.5.31-0ubuntu0.12.04.1 > OpenLDAP: 2.4.35 > libmyodbc: 5.2.4 > unixodbc: 2.3.0-2ubuntu1 > > Here are > > a sample configuration file: > http://pastebin.de/34104 > > odbc config files: > http://pastebin.de/34103 > > sample db script: > http://pastebin.de/34101 > > and insert script: > http://pastebin.de/34102 > > Is there a patch, workaround, anything? There is no caching of the contents of ldap_entries in back-sql; maybe some caching at the odbc level? p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7579) back-sql does not update DIT when DB is updated
by mail＠benjamin-behringer.de 29 Apr '13

29 Apr '13

Full_Name: Benjamin Behringer Version: 2.4.35 OS: Ubuntu 12.04 64bit URL: Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867) Hi, I'm using OpenLDAP and back-sql to make the information, stored in a MySQL Database, available over LDAP (for Authentication purposes). Unfortunately, when I insert or update an entry in the Database, the DIT is not updated. In contrast, a delete on the ldap_entries table will cause slapd to reflect the DB change in the DIT. The issue only occurs, when the DIT has already been loaded, and the subtree you will make the change to has already been read at least once. If you restart slapd, the changes are reflected. Software Versions: Distribution: Ubuntu 12.04 64bit MySQL: 5.5.31-0ubuntu0.12.04.1 OpenLDAP: 2.4.35 libmyodbc: 5.2.4 unixodbc: 2.3.0-2ubuntu1 Here are a sample configuration file: http://pastebin.de/34104 odbc config files: http://pastebin.de/34103 sample db script: http://pastebin.de/34101 and insert script: http://pastebin.de/34102 Is there a patch, workaround, anything? Regards

1 0

Re: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 28 Apr '13

28 Apr '13

juergen.sprenger(a)swisscom.com wrote: > Full_Name: Juergen Sprenger > Version: 2.4.35 > OS: Gentoo Base System release 2.1, Kernel 3.7.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.5.238.18) > > > mdb dereference aliases problem. A fix for this is now in git master, please test, thanks. commit fb537d747c6fd43e08986e99b1fe7781660feaf3 > > I use aliases to keep information about a person who has multiple accounts > consistent over all accounts and avoid redundancy, example: > > dn: uid=joe,ou=Account,dc=its,dc=scom > objectClass: alias > objectClass: extensibleObject > uid: joe > aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom > structuralObjectClass: alias > > When using hdb as backend for slapd everything works fine, and user are > authenticated properly: > # running 'getent passwd' with hdb backend: > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 > text= > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH > base="ou=account,dc=its,dc=scom" scope=1 deref=3 > filter="(objectClass=posixAccount)" > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos > description objectClass > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 > err=0 nentries=656 text= > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection > lost) > > When using mdb as backend with same directory content, users are no longer > authenticated, search returns nentries=0: > > # running 'getent passwd' with mdb backend: > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 > text= > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH > base="ou=account,dc=its,dc=scom" scope=1 deref=3 > filter="(objectClass=posixAccount)" > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos > description objectClass > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 > err=0 text= > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection > lost) > > Both setups have identical md5sum of slapcat output, so directory content can be > assumed identical in my opinion. > > > -- -- 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#7567) Alias dereferencing slowness
by hyc＠symas.com 28 Apr '13

28 Apr '13

luca.scamoni(a)gruppopa.it wrote: > Full_Name: Luca Scamoni > Version: 2.4.35 > OS: Linux > URL: ftp://www.sys-net.it/alias-deref-ITS2.tar.gz > Submission from: (NULL) (78.134.117.13) > > > Investigating alias dereferencing slowness on a customer production system I > came upon a suspect behaviour with back-hdb/bdb. > It seems that slapd, when dereferencing, instead of looking for the exact > aliased DN, starts scanning more entries than needed (at least this is what I > can tell looking to the logs set to log anything) > On the customer system, with over 700,000 entries, the time taken to perform a > simple search with alias dereferencing for a single entry, takes as much as > performing a full ldapsearch of the entire ldap tree. > To reproduce I created a small testcase (that I can't upload because there's no > space left on ftp.openldap.org/incoming). The test case contains also the log > and the operations performed on test data to show the issue. > I tested with openldap 2.4.23, 2.4.31 and 2.4.35. The issue is present in all > versions but seems to manifest itself only with back-bdb/hdb. Back-mdb seems not > to show the issue (even looking at the logs) but right now, moving to back-mdb > is not something the customer is ready to take. I would not recommend switching to back-mdb at this time, see ITS#7577. Alias dereferencing is broken in a few cases in back-mdb. Meanwhile, in back-bdb/hdb, it also depends on whether you're searching with Deref set to Finding, Searching or Always. Deref/Finding works in all 3 backends (bdb/hdb/mdb). (Deref/Searching in back-mdb was mainly broken by the patches in ITS#7473.) When Deref is set to Searching/Always, the backend must find every alias within the target search scope and dereference them. This deref can potentially expand the scope of the search, e.g. if the alias points to a completely different subtree. If you have a lot of aliases in the tree, this is likely going to be very slow. -- -- 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#7578) delta-sync multimaster replication issue
by afrunning＠gmail.com 26 Apr '13

26 Apr '13

Full_Name: Al F Version: 2.4.35 OS: Redhat 6.4 - x64 URL: https://dl.dropboxusercontent.com/u/982376/its/al-f-130426.zip Submission from: (NULL) (74.123.146.10) Hi, I have a multimaster system utilizing delta-sync for replication. The system is utilizing mdb for both the user and the accesslog data. I have ppolicy & memberof overlays enabled as well. all of my writes are directed at a single server using a load balancer. I have found that when a user has a pwdFailureTime attribute set on their entry, if an administrator resets the password, "null_callback : error code 0x10" is produced in the log on the secondary system and the secondary system goes into refresh mode. The mentioned zip file contains most of my configuration as well a portion of the log when the issue occurred. The log was generated during a failure with -d-1 to slapd. I have a lot more log from before and after the issue however it is littered with sensitive data, so I didn't want to redact it unless necessary. Please let me know what else I can do to help. Regards, Al

1 0

Re: ITS#7552
by Matthew.Monaco＠colorado.edu 24 Apr '13

24 Apr '13

This is a multi-part message in MIME format. --------------010002070300090900000609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Caching queries with * attributes broken (compiled from 260fd69, RE24 HEAD). This works: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' This does not: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' uid I also have a problem where the attribute set is set to (nssov_passwd_byname): uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass For this, nssov does not work (I see cacheable, but the query never gets cached). However, this does work: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' uid (Also, test020 passes) --------------010002070300090900000609 Content-Type: text/plain; charset=UTF-8; name="slapd-master.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-master.conf" ######## ## ## CSEL ## ## # Modules #modulepath /usr/lib/ldap moduleload back_mdb.so moduleload nssov.so ## # Schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/ldapns.schema ## # System pidfile /run/slapd/slapd.pid argsfile /run/slapd/slapd.args loglevel 256 sizelimit 5000 TLSCACertificateFile /etc/openldap/ldap-csel-ca.crt TLSCertificateFile /etc/openldap/ldap-csel.crt TLSCertificateKeyFile /etc/openldap/ldap-csel.key ## # ACLs access to attrs=userPassword by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage by self =xw by anonymous auth by * none #access to dn.children="ou=users,dc=cs,dc=colorado,dc=edu" # by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage # by self read # by * none #access to dn.children="ou=groups,dc=cs,dc=colorado,dc=edu" attrs=memberUid # by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage # by users search # by * none access to * by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage by users read by * read ## # Backend (mdb) database mdb directory /var/lib/openldap/csel.mdb maxsize 1073741824 suffix dc=cs,dc=colorado,dc=edu index default eq index objectClass index cn index uid index uidNumber index gidNumber index memberUid index uniqueMember index entryCSN ## # Overlay (nssov) overlay nssov nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one --------------010002070300090900000609 Content-Type: text/plain; charset=UTF-8; name="slapd-client.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-client.conf" ####### ## ## CSEL ## ## # Modules moduleload back_ldap.so moduleload back_mdb.so moduleload pcache.so moduleload nssov.so ## # Schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/ldapns.schema ## # System pidfile /run/slapd/slapd.pid argsfile /run/slapd/slapd.args sizelimit 10000 ## # Backend (ldap) database ldap uri ldaps://xxx.colorado.edu/ tls ldaps tls_reqcert=allow suffix dc=cs,dc=colorado,dc=edu rootdn cn=pcache,ou=sys,dc=cs,dc=colorado,dc=edu ## # Overlay (proxy cache) overlay pcache pcache mdb 10000 1 256 120 pcacheOffline TRUE directory /var/lib/openldap/pcache.mdb maxsize 67108864 index default eq index objectClass index cn index uid index uidNumber index gidNumber index memberUid index uniqueMember pcacheAttrset 0 * pcacheTemplate (&(objectClass=)(uid=)) 0 3600 ## # Overlay (nssov) overlay nssov nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one --------------010002070300090900000609--

1 0

(ITS#7577) hdb and mdb derefere aliases differently
by juergen.sprenger＠swisscom.com 24 Apr '13

24 Apr '13

Full_Name: Juergen Sprenger Version: 2.4.35 OS: Gentoo Base System release 2.1, Kernel 3.7.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.5.238.18) mdb dereference aliases problem. I use aliases to keep information about a person who has multiple accounts consistent over all accounts and avoid redundancy, example: dn: uid=joe,ou=Account,dc=its,dc=scom objectClass: alias objectClass: extensibleObject uid: joe aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom structuralObjectClass: alias When using hdb as backend for slapd everything works fine, and user are authenticated properly: # running 'getent passwd' with hdb backend: Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=656 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection lost) When using mdb as backend with same directory content, users are no longer authenticated, search returns nentries=0: # running 'getent passwd' with mdb backend: Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection lost) Both setups have identical md5sum of slapcat output, so directory content can be assumed identical in my opinion.

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 23 Apr '13

23 Apr '13

--Apple-Mail-2--242372278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth wrote: >=20 > You can instead look for a mechanism with built-in credential passing, > apparently like Solaris "doors". =20 The sample client-server programs, see link below, show an experiment on = Solaris 8 that server creates and listens to door calls, while client = invokes them. When client invokes a door_call, server gets the euid and = egid, among others, of the client: https://dl.dropboxusercontent.com/u/94235048/door_call.tgz http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.html # ./server successfully created a door euid (101) egid (1) ruid (101) rgid (1) pid (8947) $ id uid=3D101(tedcheng) gid=3D1(other) $ ./client pid (8947): door_call succeeded There is the situation in which we are sending/getting client = credentials from a door call through say /tmp/door, while service = requests, such as nssov/nslcd (nss-pam-ldapd), through a separate Unix = domain socket. There is therefore the need to tie client credentials = with their respective (name) service requests; "doors" implements its = own threading support. The work to integrate doors for client credential = support into a server with threading support, such as slapd, may get = complicated fast. "Doors" does not seem to be a feasible solution for sending client = credentials in a context such as nssov/slapd. > Or look at what some other well-tested > and portable package does and suggest we steal its code.=20 >=20 This may be the only option, if there exists one, for older-system = support (Solaris 8). Ted C. Cheng Symas Corporation --Apple-Mail-2--242372278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div><div>On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth = wrote:</div><blockquote type=3D"cite"><div><font = class=3D"Apple-style-span" color=3D"#000000"><br></font>You can instead = look for a mechanism with built-in credential passing,<br>apparently = like Solaris "doors". =  </div></blockquote><div><br></div><div><div>The = sample client-server programs, see link below, show an experiment = on Solaris 8 that server creates and listens to door calls, while client = invokes them. When client invokes a door_call, server gets the euid and = egid, among others, of the client:</div><div><br></div><div><a = href=3D"https://dl.dropboxusercontent.com/u/94235048/door_call.tgz">https:= //dl.dropboxusercontent.com/u/94235048/door_call.tgz</a></div><div><br></d= iv><div><a = href=3D"http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.= html">http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.ht= ml</a></div><div><br></div><div># ./server<br>successfully created a = door<br>euid (101) egid (1) ruid (101) rgid (1) pid (8947)<br><br>$ = id<br>uid=3D101(tedcheng) gid=3D1(other)<br>$ ./client<br>pid (8947): = door_call succeeded</div><div><br></div><div>There is the situation = in which we are sending/getting client credentials from a door call = through say /tmp/door, while service requests, such as nssov/nslcd = (nss-pam-ldapd), through a separate Unix domain socket. There is = therefore the need to tie client credentials with their respective = (name) service requests; "doors" implements its own threading = support. The work to integrate doors for client credential support into = a server with threading support, such as slapd, may get complicated = fast.</div><div><br></div><div>"Doors" does not seem to be a feasible = solution for sending client credentials in a context such as = nssov/slapd.</div></div><br><blockquote type=3D"cite"><div>Or look at = what some other well-tested<br>and portable package does and suggest we = steal its code. <font class=3D"Apple-style-span" = color=3D"#006312"><br></font></div></blockquote><blockquote = type=3D"cite"><div><br></div></blockquote><br></div><div>This may be the = only option, if there exists one, for older-system support (Solaris = 8).</div><div><br></div><div><br></div><div><div>Ted C. = Cheng</div><div>Symas = Corporation</div></div><div><br></div><div><br></div></body></html>= --Apple-Mail-2--242372278--

1 0

Re: ITS#7518
by hyc＠symas.com 23 Apr '13

23 Apr '13

Matthew.Monaco(a)colorado.edu wrote: > commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build > > were updated files omitted from the nss-pam-ldapd directory? Yes, it looks like it. Updated files now pushed to git master, 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#7518
by Matthew.Monaco＠colorado.edu 23 Apr '13

23 Apr '13

commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build were updated files omitted from the nss-pam-ldapd directory?

1 0

Re: (ITS#7576) olcLogFile does not work on Ubuntu 12.04
by quanah＠zimbra.com 18 Apr '13

18 Apr '13

--On Tuesday, April 16, 2013 5:06 PM +0000 hvnsweeting(a)gmail.com wrote: > Full_Name: Nguyen Viet Hung > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.16.114.114) > > > I tried this directive on Ubuntu but it does not work. > Someone on openldap IRC said that > "olclogfile is only used on windows, because it lacks syslog" > > If he is right, please do change OpenLDAP document to make this less > confusing. Thanks Incorrect. Please read the slapd-config(5) man page. There is no issue using the logfile on linux. If you have questions on how to create one, please follow up with the openldap-technical list. This ITS will be closed. I would generally note that on linux setting the olcLogfile is not necessary, but if you must catch the stderr messages, you may which to do so. I would also note the version of OpenLDAP you are using is quite ancient. You'd be better served to upgrade to a current release. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7576) olcLogFile does not work on Ubuntu 12.04
by hvnsweeting＠gmail.com 16 Apr '13

16 Apr '13

Full_Name: Nguyen Viet Hung Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.16.114.114) I tried this directive on Ubuntu but it does not work. Someone on openldap IRC said that "olclogfile is only used on windows, because it lacks syslog" If he is right, please do change OpenLDAP document to make this less confusing. Thanks

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 16 Apr '13

16 Apr '13

Ok, I understand, now. I totally overlooked the definition of MDB_NEXT_MULTIPLE, which I believed was here to return all the duplicate of the next key. Really sorry about all that noise. You may be interested in keeping the following little change from my patch, though: @@ -4377,6 +4377,8 @@ mdb_cursor_next(MDB_cursor *mc, MDB_val *key, MDB_val *data, MDB_cursor_op op) rc = mdb_cursor_first(&mc->mc_xcursor->mx_cursor, data, NULL); if (rc != MDB_SUCCESS) return rc; + } else if (mc->mc_db->md_flags & MDB_DUPSORT) { + mc->mc_xcursor->mx_cursor.mc_flags &= ~C_INITIALIZED; } } mdb_cursor_next should invalidate mx_cursor when there is no duplicate data for the current key. It's maybe useless if we are sure that we won't ever rely on this flag thereafter, but it's certainly safer. Regards, Claude On Mon, 15 Apr 2013 13:42:40 -0700 Howard Chu <hyc(a)symas.com> wrote: > claude.brisson(a)gmail.com wrote: > > On Mon, 15 Apr 2013 20:01:01 GMT > > hyc(a)symas.com wrote: > > > >> Your patch changes the meaning of these operations. > >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already > >> documented as such. > > > > The documentation in the header never states that MULTIPLE > > operations should *fail* on singletons. One could expect that the > > sentence "Return all the duplicate data items at the current cursor > > position" means that singletons will *also* be returned, without > > having to resort to a second call in case of failure. > > > >> Your patch makes them return non-duplicate data. This is a > >> fundamental change in an established behavior. A complete break, > >> actually; it will return data that doesn't match the key that the > >> client requested. It is completely wrong. > > > > I'm sorry if it broke something and made you loose your time, I was > > trying to help here. But the only change is to return singletons > > instead of MDB_NOTFOUND - the data will always match the key. > > No. This is in your patch: > > @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, > MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) > rc = mdb_cursor_first(mc, key, data); > else > - rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_DUP); > + rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { > if (mc->mc_xcursor->mx_cursor.mc_flags & > C_INITIALIZED) { MDB_cursor *mx; > > So you've made it return non-matching data. > > > Maybe I missed something, here. But I wonder why the client code > > should at any point *expect* truly duplicate data. > > That is the sole purpose of these options. > > Re-read the description: > > MDB_GET_MULTIPLE, /**< Return all the duplicate data items > at the current > cursor position. Only for > #MDB_DUPFIXED */ > > If the current cursor position is a singleton, then you already have > its data if you positioned the cursor using (&key, &data) so there is > no need to make any further calls anyway. >

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

claude.brisson(a)gmail.com wrote: > On Mon, 15 Apr 2013 20:01:01 GMT > hyc(a)symas.com wrote: > >> Your patch changes the meaning of these operations. >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already >> documented as such. > > The documentation in the header never states that MULTIPLE operations > should *fail* on singletons. One could expect that the sentence "Return > all the duplicate data items at the current cursor position" means > that singletons will *also* be returned, without having to resort to a > second call in case of failure. > >> Your patch makes them return non-duplicate data. This is a >> fundamental change in an established behavior. A complete break, >> actually; it will return data that doesn't match the key that the >> client requested. It is completely wrong. > > I'm sorry if it broke something and made you loose your time, I was > trying to help here. But the only change is to return singletons > instead of MDB_NOTFOUND - the data will always match the key. No. This is in your patch: @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) rc = mdb_cursor_first(mc, key, data); else - rc = mdb_cursor_next(mc, key, data, MDB_NEXT_DUP); + rc = mdb_cursor_next(mc, key, data, MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { if (mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) { MDB_cursor *mx; So you've made it return non-matching data. > Maybe I missed something, here. But I wonder why the client code should > at any point *expect* truly duplicate data. That is the sole purpose of these options. Re-read the description: MDB_GET_MULTIPLE, /**< Return all the duplicate data items at the current cursor position. Only for #MDB_DUPFIXED */ If the current cursor position is a singleton, then you already have its data if you positioned the cursor using (&key, &data) so there is no need to make any further calls anyway. -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 15 Apr '13

15 Apr '13

On Mon, 15 Apr 2013 20:01:01 GMT hyc(a)symas.com wrote: > Your patch changes the meaning of these operations. > GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already > documented as such. The documentation in the header never states that MULTIPLE operations should *fail* on singletons. One could expect that the sentence "Return all the duplicate data items at the current cursor position" means that singletons will *also* be returned, without having to resort to a second call in case of failure. > Your patch makes them return non-duplicate data. This is a > fundamental change in an established behavior. A complete break, > actually; it will return data that doesn't match the key that the > client requested. It is completely wrong. I'm sorry if it broke something and made you loose your time, I was trying to help here. But the only change is to return singletons instead of MDB_NOTFOUND - the data will always match the key. Maybe I missed something, here. But I wonder why the client code should at any point *expect* truly duplicate data. Regards, Claude

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

Claude Brisson wrote: > So it means the following: with the current code, when the client code > wants to optimize transfers with GET_MULTIPLE/NEXT_MULTIPLE, it has to > fall back to standard GET/NEXT whenever it encounters MDB_NOTFOUND. > Whereas the patch assumes that GET_MULTIPLE/NEXT_MULTIPLE will not > depend on the number of records. > > IMHO, the current behavior is a bit cumbersome. Would it be that > complex to update the client code? Your patch changes the meaning of these operations. GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already documented as such. Your patch makes them return non-duplicate data. This is a fundamental change in an established behavior. A complete break, actually; it will return data that doesn't match the key that the client requested. It is completely wrong. > > Claude > > On Sun, 14 Apr 2013 23:56:41 GMT > hyc(a)symas.com wrote: > >> hyc(a)symas.com wrote: >>> claude.brisson(a)gmail.com wrote: >>>> Full_Name: Claude Brisson >>>> Version: HEAD >>>> OS: linux 64 >>>> URL: >>>> ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… >>>> Submission from: (NULL) (84.103.74.130) >>>> >>>> >>>> In a db with MDB_DUPSORT flag, when there is only one DUP data for >>>> a key, F_DUPDATA is not set for this key, and there is no >>>> sub-cursor. >>>> >>>> In this case, the current behaviour of MDB_GET_MULTIPLE and >>>> MDB_NEXT_MULTIPLE is broken because they make the assumption that >>>> there is always a sub-cursor for DUP data, which is only true for >>>> keys with more than one DUP data. >>>> >>>> This patch address this specific issue. >>> >>> Something's wrong with this patch, it breaks >>> MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate >>> further. >>> >> The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only >> valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is >> essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If >> there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return >> MDB_NOTFOUND. >> >> This patch was in mdb.master but has now been reverted. 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 15 Apr '13

15 Apr '13

So it means the following: with the current code, when the client code wants to optimize transfers with GET_MULTIPLE/NEXT_MULTIPLE, it has to fall back to standard GET/NEXT whenever it encounters MDB_NOTFOUND. Whereas the patch assumes that GET_MULTIPLE/NEXT_MULTIPLE will not depend on the number of records. IMHO, the current behavior is a bit cumbersome. Would it be that complex to update the client code? Claude On Sun, 14 Apr 2013 23:56:41 GMT hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > > claude.brisson(a)gmail.com wrote: > >> Full_Name: Claude Brisson > >> Version: HEAD > >> OS: linux 64 > >> URL: > >> ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… > >> Submission from: (NULL) (84.103.74.130) > >> > >> > >> In a db with MDB_DUPSORT flag, when there is only one DUP data for > >> a key, F_DUPDATA is not set for this key, and there is no > >> sub-cursor. > >> > >> In this case, the current behaviour of MDB_GET_MULTIPLE and > >> MDB_NEXT_MULTIPLE is broken because they make the assumption that > >> there is always a sub-cursor for DUP data, which is only true for > >> keys with more than one DUP data. > >> > >> This patch address this specific issue. > > > > Something's wrong with this patch, it breaks > > MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate > > further. > > > The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only > valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is > essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If > there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return > MDB_NOTFOUND. > > This patch was in mdb.master but has now been reverted. Closing this > ITS. >

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 14 Apr '13

14 Apr '13

hyc(a)symas.com wrote: > claude.brisson(a)gmail.com wrote: >> Full_Name: Claude Brisson >> Version: HEAD >> OS: linux 64 >> URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… >> Submission from: (NULL) (84.103.74.130) >> >> >> In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, >> F_DUPDATA is not set for this key, and there is no sub-cursor. >> >> In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is >> broken because they make the assumption that there is always a sub-cursor for >> DUP data, which is only true for keys with more than one DUP data. >> >> This patch address this specific issue. > > Something's wrong with this patch, it breaks MDB_GET_MULTIPLE/NEXT_MULTIPLE > usage in slapd. Need to investigate further. > The original code is correct. GET_MULTIPLE/NEXT_MULTIPLE are only valid when there actually are duplicate records. MDB_NEXT_MULTIPLE is essentially just a shortcut for calling MDB_NEXT_DUP in a loop. If there are no dups, then MDB_NEXT_DUP (and MDB_NEXT_MULTIPLE) return MDB_NOTFOUND. This patch was in mdb.master but has now been reverted. 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 14 Apr '13

14 Apr '13

claude.brisson(a)gmail.com wrote: > Full_Name: Claude Brisson > Version: HEAD > OS: linux 64 > URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… > Submission from: (NULL) (84.103.74.130) > > > In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, > F_DUPDATA is not set for this key, and there is no sub-cursor. > > In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is > broken because they make the assumption that there is always a sub-cursor for > DUP data, which is only true for keys with more than one DUP data. > > This patch address this specific issue. Something's wrong with this patch, it breaks MDB_GET_MULTIPLE/NEXT_MULTIPLE usage in slapd. Need to investigate further. -- -- 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#7575) Fixed send_cli_cred on platforms that do not support such functions
by h.b.furuseth＠usit.uio.no 14 Apr '13

14 Apr '13

Ted C. Cheng writes: > I have revised the patch to (1) initialize rname buffer, (2) ignore > the comparison "llen == rlen", Might be OK, but... > (3) compare st.st_mode only against S_IFIFO, but not S_ISUID|S_IRWXU. No. You're getting proper use to work on Solaris, but that's the easy part. That fchmod and corresponding mode test is there for a reason: The code must also reject attempts to impersonate other users or groups. A user could find and open a named socket/pipe owned by some other user, or start someone's setuid program which opens a Unix domain socket and then runs his program as his own user, or something like that. I don't remember exactly. But OSes and OS releases differ about which of these impersonation attempts might work if this code were insufficiently paranoid, so you have quite some exporation work ahead of you if you want to tweak this FD passing safely. You can instead look for a mechanism with built-in credential passing, apparently like Solaris "doors". Or look at what some other well-tested and portable package does and suggest we steal its code. Or live with the fact that SASL/EXTERNAL over ldapi:// is supported on your platform. > The socket path comparison demands full-path match, e.g., > "/var/suum/run/socket" won't match against "/var/suum/run//socket". -- Hallvard

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by hyc＠symas.com 14 Apr '13

14 Apr '13

tedcheng(a)symas.com wrote: > On Apr 13, 2013, at 12:24 AM, Hallvard Breien Furuseth wrote: > >> Looking again at the st_mode compare: I'm pretty sure the old >> code worked somewhere, at some time. Maybe somewhere it still >> does, and expecting a different fstat():st_mode will break that. >> Unless something changed in OpenLDAP itself? >> >> Anyway, after re-reading ITS#4893 I'd be very wary about tweaking >> this code. Looks like at least I just gave up at the end, but >> followup#9 suggests using Solaris "doors". IIRC I did look at at >> the supposedly more general STREAMS pipes and found myself wading >> into portability issues or kernel tuning params or whateveer. >> >> -- >> Hallvard > > > There are several issues on Solaris 8: > > 1. getsockname(s, (struct sockaddr *)&lname, &llen) > > The llen parameter does not return the actual size of the socket address, > but the original buffer size. As a result, the comparison > !memcmp(&lname, &rname, llen) compares the whole buffer. > Since rname is not initialized to 0 for the entire buffer, the garbage > characters following the socket path name always fail the comparison. > > + if( err == 0 && st.st_mode == mode && llen == rlen > + && !memcmp(&lname, &rname, llen)) > > 2. The checking "llen == rlen" always fails as well. > > 3. The fchmod( fds[0], S_ISUID|S_IRWXU) on the client side does not change > the mode to include S_ISUID|S_IRWXU. The mode stays as only > S_IFIFO: > > (gdb) next > 81 if (rc = fchmod( fds[0], S_ISUID|S_IRWXU ) < 0) { > (gdb) print st > $2 = {...st_mode = 4096, ...} > (gdb) next > 85 (void) fstat(fds[0], &st); > (gdb) next > 86 write( fds[1], sa, salen ); > (gdb) print st > $3 = {...st_mode = 4096, ...} > > Trying to compare (st.st_mode == S_IFIFO|S_ISUID|S_IRWXU) > always fails. As Hallvard points out, all of this code was known to work at one time. Apparently a subsequent Solaris patchlevel has broken it. I don't see a portable way to conditionalize this behavior now. > I have revised the patch to (1) initialize rname buffer, (2) ignore > the comparison "llen == rlen", (3) compare st.st_mode only against > S_IFIFO, but not S_ISUID|S_IRWXU. > > The socket path comparison demands full-path match, e.g., "/var/suum/run/socket" > won't match against "/var/suum/run//socket". Nor should it. In this case whoever is using "//" in the path is misconfigured, as I already said before in private email. > > The revised patch is at: > https://dl.dropboxusercontent.com/u/94235048/ITS7575.patch > > Ted C. Cheng > Symas Corporation -- -- 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#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 13 Apr '13

13 Apr '13

On Apr 13, 2013, at 12:24 AM, Hallvard Breien Furuseth wrote: > Looking again at the st_mode compare: I'm pretty sure the old > code worked somewhere, at some time. Maybe somewhere it still > does, and expecting a different fstat():st_mode will break that. > Unless something changed in OpenLDAP itself? > > Anyway, after re-reading ITS#4893 I'd be very wary about tweaking > this code. Looks like at least I just gave up at the end, but > followup#9 suggests using Solaris "doors". IIRC I did look at at > the supposedly more general STREAMS pipes and found myself wading > into portability issues or kernel tuning params or whateveer. > > -- > Hallvard There are several issues on Solaris 8: 1. getsockname(s, (struct sockaddr *)&lname, &llen) The llen parameter does not return the actual size of the socket address, but the original buffer size. As a result, the comparison !memcmp(&lname, &rname, llen) compares the whole buffer. Since rname is not initialized to 0 for the entire buffer, the garbage characters following the socket path name always fail the comparison. + if( err == 0 && st.st_mode == mode && llen == rlen + && !memcmp(&lname, &rname, llen)) 2. The checking "llen == rlen" always fails as well. 3. The fchmod( fds[0], S_ISUID|S_IRWXU) on the client side does not change the mode to include S_ISUID|S_IRWXU. The mode stays as only S_IFIFO: (gdb) next 81 if (rc = fchmod( fds[0], S_ISUID|S_IRWXU ) < 0) { (gdb) print st $2 = {...st_mode = 4096, ...} (gdb) next 85 (void) fstat(fds[0], &st); (gdb) next 86 write( fds[1], sa, salen ); (gdb) print st $3 = {...st_mode = 4096, ...} Trying to compare (st.st_mode == S_IFIFO|S_ISUID|S_IRWXU) always fails. I have revised the patch to (1) initialize rname buffer, (2) ignore the comparison "llen == rlen", (3) compare st.st_mode only against S_IFIFO, but not S_ISUID|S_IRWXU. The socket path comparison demands full-path match, e.g., "/var/suum/run/socket" won't match against "/var/suum/run//socket". The revised patch is at: https://dl.dropboxusercontent.com/u/94235048/ITS7575.patch Ted C. Cheng Symas Corporation

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by h.b.furuseth＠usit.uio.no 13 Apr '13

13 Apr '13

Looking again at the st_mode compare: I'm pretty sure the old code worked somewhere, at some time. Maybe somewhere it still does, and expecting a different fstat():st_mode will break that. Unless something changed in OpenLDAP itself? Anyway, after re-reading ITS#4893 I'd be very wary about tweaking this code. Looks like at least I just gave up at the end, but followup#9 suggests using Solaris "doors". IIRC I did look at at the supposedly more general STREAMS pipes and found myself wading into portability issues or kernel tuning params or whateveer. -- Hallvard

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by h.b.furuseth＠usit.uio.no 12 Apr '13

12 Apr '13

tedcheng(a)symas.com writes: > URL: https://dl.dropboxusercontent.com/u/94235048/fix_send_cli_cred.patch > > Importing fix from Symas #2230: > > On platforms, such as Solaris 8, that do not support functions for getting > client credential, client sends a message and fd for server to derive euid/egid. > The server-side logic for deriving client credential was buggy. > > This patch introduces sockaddr_un_cmp() to compare the socket path names, > ignoring redundant "/" in the path, and only checks S_IFIFO mode. This patch has > been tested on Solaris 8 and regression-tested fine on Solaris 10. This patch is wrong: - You cannot trust the path which the client wrote to the socket *by hand* (label sendcred: in libldap/os-local.c:ldap_pvt_connect()), if someone else than the owner and root has write access to the socket. Could comment that in getpeereid.c, to prevent such a future patch. - An initial "//" is significant on some systems and must not match "/". Posix does not guarantee that sun_path[] is \0-terminated. What problem is the complicated compare solving? Why not require that the user spells the path like the server does, similar to how TLS hostnames must be spelled the same way? You are not catching all possible spellings of the path anyway: YOu do not reduce "/./" to "/" and must not reduce "foo/../ to "" since foo can be a symlink. -- Hallvard

1 0

(ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 12 Apr '13

12 Apr '13

Full_Name: Ted C. Cheng Version: HEAD OS: Solaris 8 URL: https://dl.dropboxusercontent.com/u/94235048/fix_send_cli_cred.patch Submission from: (NULL) (76.174.250.179) Importing fix from Symas #2230: On platforms, such as Solaris 8, that do not support functions for getting client credential, client sends a message and fd for server to derive euid/egid. The server-side logic for deriving client credential was buggy. This patch introduces sockaddr_un_cmp() to compare the socket path names, ignoring redundant "/" in the path, and only checks S_IFIFO mode. This patch has been tested on Solaris 8 and regression-tested fine on Solaris 10.

1 0

Re: (ITS#7574) slapo-unique not enforcing uniqueness
by quanah＠zimbra.com 12 Apr '13

12 Apr '13

--On Friday, April 12, 2013 5:48 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, April 12, 2013 5:43 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: RE24 4/12/2013 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.39.181) > > Also the following modify succeeds when it should fail: > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=test zimbraID > dn: dc=test,dc=com > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=example zimbraId > dn: dc=example,dc=com > zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9 > > zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra > dn: dc=example,dc=com > changetype: modify > replace: zimbraId > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > modifying entry "dc=example,dc=com" I found it has entirely to do with brand new entries since slapd was last started. unique simply won't enforce on any data added after slapd was started. Restarting slapd results in the correct behavior. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7574) slapo-unique not enforcing uniqueness
by quanah＠zimbra.com 12 Apr '13

12 Apr '13

--On Friday, April 12, 2013 5:43 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 4/12/2013 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.39.181) Also the following modify succeeds when it should fail: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=test zimbraID dn: dc=test,dc=com zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=example zimbraId dn: dc=example,dc=com zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9 zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra dn: dc=example,dc=com changetype: modify replace: zimbraId zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc modifying entry "dc=example,dc=com" zimbra@zre-ldap002:~$ --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7574) slapo-unique not enforcing uniqueness
by quanah＠OpenLDAP.org 12 Apr '13

12 Apr '13

Full_Name: Quanah Gibson-Mount Version: RE24 4/12/2013 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.39.181) In current RE24, when using the back-mdb backend, uniqueness is no longer enforced. This worked correctly up until at least 2.4.33. dn: olcOverlay={1}unique objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {1}unique olcUniqueURI: ldap:///?mail?sub olcUniqueURI: ldap:///?zimbraId?sub olcUniqueURI: ldap:///?DKIMSelector?sub so I force uniqueness on "DKIMSelector" It is indexed eq: olcDbIndex: DKIMSelector eq However, adding data for it succeeds when it should be rejected: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra DKIMSelector=ABCD DKIMSelector dn: dc=test,dc=com DKIMSelector: ABCD dn: dc=example,dc=com DKIMSelector: ABCD

1 0

Re: (ITS#7573) back-perl not working with cn=config
by quanah＠zimbra.com 11 Apr '13

11 Apr '13

--On Thursday, April 11, 2013 6:20 PM +0000 benintechnologies(a)yahoo.fr wrote: > Like I said, if I set back-perl up in slapd.conf mode and then convert it > to cn=config, everything works fine. So how does the ldif generated by slaptest differ from what you are loading? If you slapcat your config that doesn't work, and compare it to the slapcat of what was generated from slaptest, what are the differences? Can you provide a gdb backtrace of the segmentation fault? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7573) back-perl not working with cn=config
by benintechnologies＠yahoo.fr 11 Apr '13

11 Apr '13

Full_Name: Ben Version: 2.4.34 OS: Debian 6.0.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.79.217.116) Hi, I'm unable to set up a back-perl backend directly in cn=config mode. However, if I set it up in slapd.conf mode, and then convert it to cn=config mode, it works fine. It's not convenient, because I have to set all my perl backends up before converting to cn=config. Here's the ldif file I'm using to set up a back-perl backend in cn=config mode (it's inspired from the files I get by converting slapd.conf into cn=config with slaptest) # Load dynamic backend modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/local/libexec/openldap olcModuleload: back_perl.la # Database settings dn: olcDatabase=perl,cn=config objectClass: olcDatabaseConfig objectClass: olcDbPerlConfig olcDatabase: perl olcSuffix: dc=mydomain,dc=org olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=mydomain,dc=org olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcPerlModulePath: /usr/local/etc/openldap/perl olcPerlModule: SampleLDAP olcPerlFilterSearchResults: FALSE And here's what I get when I try to load the file: ldapadd -Y EXTERNAL -H ldapi:/// -f perl-backend.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" adding new entry "olcDatabase=perl,cn=config" ldap_result: Can't contact LDAP server (-1) After that, if I start OpenLDAP I get a segmentation fault: root@ldap:/tmp# /usr/local/libexec/slapd -u openldap -g openldap -h "ldap:/// ldapi:///" -d 16383 . 51585496 perl backend db init Segmentation fault Like I said, if I set back-perl up in slapd.conf mode and then convert it to cn=config, everything works fine. Ben

1 0

ITS#6365 Fwd: RE: truncated slapcat output
by hyc＠symas.com 11 Apr '13

11 Apr '13

Fix verified. -------- Original Message -------- Subject: RE: truncated slapcat output Date: Thu, 11 Apr 2013 07:15:17 +0000 From: Hummel, Wolfgang <wolfgang.hummel(a)hp.com> To: Howard Chu <hyc(a)symas.com> Hello Howard, we tested your fix for truncated slapcat and it works fine. Please see test report below. As I am not familiar with your processes in commenting on bugfixes could you use the attached test report and commit the fix so it will become part of next release ? Thanks a lot for your support Regards Wolfgang Hummel Test execution timeframe: April 9th and 10th 2013 Test platform: Hardware HP DL380 G5, 32 GB Memory, 2 Quadcore CPUs OS RedHat 5.1 OpenLDAP 2.4.32 without / with slapcat truncate bugfix bdb backend Test setup: - Subscriber profile DB with 1 Mio. entries, each with 10 attributes Test execution: - ldapbenchmark.pl executing ~ 5 ldapmodifies and ~ 2 ldapsearches / second - slapcat_vfhu_vm_profiles.sh running slapcat in a cycle and counting entries Test result without slapcat truncate bugfix: - 1826 measurements of entry number - 23 events with truncated slapcat output - slapcat return code was always 0 ! Test result with slapcat truncate bugfix: - 1647 measurements of entry number - 0 events with truncated slapcat output script to measure it: #!/bin/bash # run slapcat forever and always count number of entries # they should always be the same while : do slapcat -b ou=vm,ou=profiles,ou=xxxx,c=hu,o=yyyy|grep "^dn:"|wc -l >>vfhu_vm_entries.txt echo "Slapcat Return Code: $?; `date`">>vfhu_vm_entries.txt sleep 1 done log snippet with bug fix: Slapcat Return Code: 0; Wed Apr 10 22:12:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:05 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:28 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:52 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:14:16 CEST 2013 1000001 log snippet without bugfix: 1000001 Slapcat Return Code: 0; Wed Apr 10 01:01:45 CEST 2013 319284 Slapcat Return Code: 0; Wed Apr 10 01:02:07 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:15 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:09 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:37 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:04 CEST 2013 437990 Slapcat Return Code: 0; Wed Apr 10 01:05:16 CEST 2013 146790 Slapcat Return Code: 0; Wed Apr 10 01:05:21 CEST 2013 72688 Slapcat Return Code: 0; Wed Apr 10 01:05:25 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:50 CEST 2013 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Dienstag, 26. März 2013 18:09 To: Hummel, Wolfgang Subject: Re: truncated slapcat output Hummel, Wolfgang wrote: > Hello Howard, > > we are facing in production of our major customer VF the same problems as > described in > > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html > > We are using back-bdb and slapcat to create nightly ldif backups of all DBs > > where 2 of them each contains ~ 40 Mio. entries. > > Even though write traffic is low when the slapcat job runs, every 1 - 2 weeks > > output is truncated without error msg or error return code which creates problems > > for subsequent batch jobs. > > Therefore a slapcat that retries like slapd if a page is locked would be > > really important for us. > > 2 Questions: > > - Is the slapcat retry mechanism the fix you described in > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html ? The patch for ITS#6365 was committed to master commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 Author: Howard Chu <hyc(a)openldap.org> Date: Thu Feb 7 18:23:25 2013 +0000 ITS#6365 wait for read locks in tool mode > - When will it be available in OpenLDAP ? When somebody follows up to the ITS and confirms that the patch fixes the issue. So far nobody has followed up. You're welcome to test and followup. > > Regards > > Wolfgang Hummel > > ---------------------------------------------------------- > > Postal Address: Hewlett-Packard GmbH > > Wolfgang Hummel > > Enterprise Services > > _/ Communication & Media Solutions > > _/ Herrenberger Str. 140 > > _/_/_/ _/_/_/ 71034 Böblingen > > _/ _/ _/ _/ Phone: +49 7031 14-7375 > > _/ _/ _/_/_/ Fax: +49 711 18562024 > > _/ mobile: +49 151 14751791 > > _/ E-Mail: wolfgang.hummel(a)hp.com > <mailto:wolfgang.hummel@hp.com> > > ---------------------------------------------------------- > > http://www.hp.com/de > > Hewlett-Packard GmbH, Herrenberger Str. 140, 71034 Böblingen > > Geschäftsführer: Volker Smid (Vorsitzender), Martin Kinne, Heiko Meyer, Ernst > Reichart, Rainer Sterk Vorsitzender des Aufsichtsrates: Jörg Menno Harms Sitz > der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 244081, WEEE-Reg.-Nr. > DE 30409072 > -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 11 Apr '13

11 Apr '13

Full_Name: Claude Brisson Version: HEAD OS: linux 64 URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… Submission from: (NULL) (84.103.74.130) In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, F_DUPDATA is not set for this key, and there is no sub-cursor. In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is broken because they make the assumption that there is always a sub-cursor for DUP data, which is only true for keys with more than one DUP data. This patch address this specific issue. Notice: I, Claude Brisson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs