- openldap-bugs - openldap.org

(ITS#6855) Suggested improvements to OpenLDAP Admin Guide preface
by gerv＠mozilla.org 04 Mar '11

04 Mar '11

Full_Name: Gervase Markham Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.45.122.200) Following a discussion on the mailing list, I submit the following as a suggestion for improvement to the Preface of the Admin Guide, to make it clear that there are other documentation resources which should be read. <snip> This document is not a complete guide to its subject matter; the man pages are the definitive documentation for OpenLDAP software. For best results, you should use those installed on your system, which will match your version of OpenLDAP. But they are also available on the web from the following links: OpenLDAP API: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> </ul> OpenLDAP configuration: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.conf">slapd.conf(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd-config">slapd-config(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.access">slapd.access(5)</a> </ul> OpenLDAP command line tools: <ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapacl">slapacl(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapadd">slapadd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapauth">slapauth(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapcat">slapcat(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapdn">slapdn(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapindex">slapindex(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slappasswd">slappasswd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapschema">slapschema(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slaptest">slaptest(8) </ul> Gerv

1 0

(ITS#6854) When login from one application, "error=49" error show up, but other application's login are all right.
by mahaoboy＠gmail.com 04 Mar '11

04 Mar '11

Full_Name: hao ma Version: 2.3.43 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.161.106.50) We have configured Openldap as our user info repository for all our applications.(include Atlassian JIRA,Confluence,Fisheye,Crowd). Then we met an very strange user. This user can logged in confluence successfully, but when could not log in fisheye. And in a little chance, he could log in fisheye correctly. Firstly , we try to find problem from these applications. And all clue point to Openldap server. So we configure Openldap Loglever as -1. And we recorded two different log of logging in confluence and logging in fisheye. Log of confluence logging: daemon: activity on 1 descriptor daemon: activity on: 17r daemon: read active on 17 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(17) connection_get(17): got connid=5 connection_read(17): checking for input on id=5 do_search daemon: activity on 1 descriptor >>> dnPrettyNormal: <ou=eejira,o=nsn> daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL <<< dnPrettyNormal: <ou=eejira,o=nsn>, <ou=eejira,o=nsn> SRCH "ou=eejira,o=nsn" 2 3 0 0 0 begin get_filter daemon: epoll: listen=8 active_threads=0 tvp=NULL AND begin get_filter_list begin get_filter EQUALITY end get_filter 0 begin get_filter EQUALITY end get_filter 0 end get_filter_list end get_filter 0 filter: (&(objectClass=person)(uid=jirasupport)) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: conn=5 op=8052 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))" slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 => bdb_search bdb_dn2entry("ou=eejira,o=nsn") search_candidates: base="ou=eejira,o=nsn" (0x00000001) scope=2 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [01872a84] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_dn2idl("ou=eejira,o=nsn") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [8c70ccf9] <= bdb_index_read 12658 candidates <= bdb_equality_candidates: id=12658, first=244, last=12912 <= bdb_filter_candidates: id=12658 first=244 last=12912 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (uid) => key_read bdb_idl_fetch_key: [66ddc068] <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=3763, last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 bdb_search_candidates: id=1 first=3763 last=3763 => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted <= test_filter 6 <= test_filter_and 6 <= test_filter 6 => send_search_entry: conn 5 dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "entry" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "cn" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "mail" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "givenName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "displayName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "sn" requested <= root access granted conn=5 op=8052 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" <= send_search_entry: conn 5 exit. send_ldap_result: conn=5 op=8052 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=8053 tag=101 err=0 conn=5 op=8052 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: listen=8, new connection on 20 daemon: added 20r (active) listener=(nil) conn=8 fd=20 ACCEPT from IP=87.254.208.143:42569 (IP=0.0.0.0:389) daemon: activity on 2 descriptors daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=8 connection_read(20): checking for input on id=8 do_bind >>> dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn> <<< dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn>, <cn=jirasupport,ou=people,ou=eejira,o=nsn> do_bind: version=3 dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=8 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 ==> bdb_bind: dn: cn=jirasupport,ou=people,ou=eejira,o=nsn bdb_dn2entry("cn=jirasupport,ou=people,ou=eejira,o=nsn") => access_allowed: auth access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested => acl_get: [1] attr userPassword access_allowed: no res from state (userPassword) => acl_mask: access to entry "cn=jirasupport,ou=People,ou=eejira,o=nsn", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=manager,ou=eejira,o=nsn <= check a_dn_pat: * <= acl_mask: [2] applying read(=rscxd) (stop) <= acl_mask: [2] mask: read(=rscxd) => access_allowed: auth access granted by read(=rscxd) conn=8 op=0 BIND dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=jirasupport,ou=people,ou=eejira,o=nsn" to "cn=jirasupport,ou=People,ou=eejira,o=nsn" send_ldap_result: conn=8 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 conn=8 op=0 RESULT tag=97 err=0 text= daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL Log of fisheye logging: daemon: activity on 1 descriptor daemon: activity on: 17r daemon: read active on 17 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(17) connection_get(17): got connid=5 connection_read(17): checking for input on id=5 do_search >>> dnPrettyNormal: <ou=eejira,o=nsn> <<< dnPrettyNormal: <ou=eejira,o=nsn>, <ou=eejira,o=nsn> SRCH "ou=eejira,o=nsn" 2 3 0 0 0 begin get_filter AND begin get_filter_list begin get_filter EQUALITY end get_filter 0 begin get_filter EQUALITY end get_filter 0 end get_filter_list end get_filter 0 filter: (&(objectClass=person)(uid=jirasupport)) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: conn=5 op=8051 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))" slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 => bdb_search bdb_dn2entry("ou=eejira,o=nsn") search_candidates: base="ou=eejira,o=nsn" (0x00000001) scope=2 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [01872a84] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_dn2idl("ou=eejira,o=nsn") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [8c70ccf9] daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL <= bdb_index_read 12658 candidates <= bdb_equality_candidates: id=12658, first=244, last=12912 <= bdb_filter_candidates: id=12658 first=244 last=12912 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (uid) => key_read bdb_idl_fetch_key: [66ddc068] <= bdb_index_read 1 candidates <= bdb_equality_candidates: id=1, first=3763, last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 <= bdb_list_candidates: id=1 first=3763 last=3763 <= bdb_filter_candidates: id=1 first=3763 last=3763 bdb_search_candidates: id=1 first=3763 last=3763 entry_decode: "cn=jirasupport,ou=People,ou=eejira,o=nsn" <= entry_decode(cn=jirasupport,ou=People,ou=eejira,o=nsn) => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted <= test_filter 6 <= test_filter_and 6 <= test_filter 6 => send_search_entry: conn 5 dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "entry" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "objectClass" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "cn" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "uid" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "mail" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "givenName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "displayName" requested <= root access granted => access_allowed: read access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "sn" requested <= root access granted conn=5 op=8051 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" <= send_search_entry: conn 5 exit. send_ldap_result: conn=5 op=8051 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=8052 tag=101 err=0 conn=5 op=8051 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(8): daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 busy >>> slap_listener(ldap:///) daemon: listen=8, new connection on 20 daemon: added 20r (active) listener=(nil) conn=7 fd=20 ACCEPT from IP=87.254.208.143:39622 (IP=0.0.0.0:389) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=7 connection_read(20): checking for input on id=7 do_bind daemon: activity on 1 descriptor daemon: activity on: >>> dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn> <<< dnPrettyNormal: <cn=jirasupport,ou=people,ou=eejira,o=nsn>, <cn=jirasupport,ou=people,ou=eejira,o=nsn> do_bind: version=3 dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=7 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 ==> bdb_bind: dn: cn=jirasupport,ou=people,ou=eejira,o=nsn bdb_dn2entry("cn=jirasupport,ou=people,ou=eejira,o=nsn") daemon: epoll: listen=7 active_threads=0 tvp=NULL => access_allowed: auth access to "cn=jirasupport,ou=People,ou=eejira,o=nsn" "userPassword" requested daemon: epoll: listen=8 active_threads=0 tvp=NULL => acl_get: [1] attr userPassword access_allowed: no res from state (userPassword) => acl_mask: access to entry "cn=jirasupport,ou=People,ou=eejira,o=nsn", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: cn=manager,ou=eejira,o=nsn <= check a_dn_pat: * <= acl_mask: [2] applying read(=rscxd) (stop) <= acl_mask: [2] mask: read(=rscxd) => access_allowed: auth access granted by read(=rscxd) send_ldap_result: conn=7 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 conn=7 op=0 RESULT tag=97 err=49 text= daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=7 connection_read(20): checking for input on id=7 ber_get_next on fd 20 failed errno=0 (Success) connection_read(20): input error=-2 id=7, closing. connection_closing: readying conn=7 sd=20 for close connection_close: conn=7 sd=-1 daemon: removing 20 conn=7 fd=20 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL And other users are all right for logging in all applications. Do you have any advice for this problem? Thanks a lot.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 03 Mar '11

03 Mar '11

--On Thursday, March 03, 2011 8:50 PM +0000 dhawes(a)vt.edu wrote: > Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu > packages or code is used. > > Backtraces (I may need to recompile without optimization): My personal experience with gcc & openldap is that building an optimized version of OpenLDAP is an extremely bad idea, as gcc makes very bad choices. --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#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 03 Mar '11

03 Mar '11

On 03/03/2011 02:38 PM, Quanah Gibson-Mount wrote: > --On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: > >> Full_Name: David Hawes >> Version: 2.4.24 >> OS: Ubuntu 10.04 >> URL: >> Submission from: (NULL) (128.173.39.26) >> >> >> When using slapadd or slapindex with the -q option, the message "Closing >> DB..." is printed and then the application hangs indefinitely. Removing >> the -q option allows the application to complete without issue. >> >> This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. > > I would ask you provide a full backtrace of the slapadd process after it > has hung. Otherwise, this report isn't of much use. > > Also, if you are using the Ubuntu patches for OpenLDAP with your > OpenLDAP build, you are including a known database-corrupting patch. > Since you don't say how you built OpenLDAP, it is impossible for us to > know if you did this or not. Both OpenLDAP and Berkeley DB are compiled from source. No Ubuntu packages or code is used. Backtraces (I may need to recompile without optimization): (gdb) thread apply all bt Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1253 #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at tpool.c:685 #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 #4 0x00007ffff677970d in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy (tpool=0x7ffffffed658, run_pending=<value optimized out>) at tpool.c:582 #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 #4 0x0000000000466059 in slap_destroy () at init.c:273 #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) at slapadd.c:606 #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 (gdb) thread apply all bt full Thread 2 (Thread 0x7ffee9003700 (LWP 29225)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00000000004b4150 in bdb_tool_trickle_task (ctx=<value optimized out>, ptr=<value optimized out>) at tools.c:1253 env = 0x886270 wrote = 0 #2 0x00000000005066b0 in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at tpool.c:685 pool = 0x844f00 task = 0x89dc30 work_list = <value optimized out> ctx = {ltu_id = 140732807526144, ltu_key = {{ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffee9002c60}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdbc08, ltk_free = 0x7ffee9002dd8}, { ltk_key = 0x0, ltk_data = 0xa8428197, ltk_free = 0x7ffff7de7457}, {ltk_key = 0x0, ltk_data = 0x2a10a06, ltk_free = 0x17}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffee9002c60}, {ltk_key = 0x0, ltk_data = 0x7ffff669c5b0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffff7fdd510}, {ltk_key = 0x0, ltk_data = 0x7ffff7fda0f0, ltk_free = 0x7ffff7fdb4c0}, { ltk_key = 0x0, ltk_data = 0x7ffff66a3660, ltk_free = 0x7ffff7631f50}, {ltk_key = 0x0, ltk_data = 0x1000003bb, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdd868, ltk_free = 0x7ffee9002e10}, { ltk_key = 0x0, ltk_data = 0x7ffee9002e38, ltk_free = 0x7ffff7fdd510}, {ltk_key = 0x0, ltk_data = 0x7ffff7de7722, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x5, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7fdd510, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffee9002dc0, ltk_free = 0x7ffee9002dd8}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x7ffff7633cef}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff669c5b0, ltk_free = 0x7ffff7fdb4c0}, {ltk_key = 0x0, ltk_data = 0xffffffff, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x218050, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffee9003700, ltk_free = 0x7ffff7631000}, { ltk_key = 0x0, ltk_data = 0x5, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x7ffff7638ca9, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x800000 <hbuf+48096>}, { ltk_key = 0x0, ltk_data = 0x7ffff7df2325, ltk_free = 0x7ffee9003700}}} kctx = <value optimized out> keyslot = 285 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007ffff76379ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007ffff677970d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7ffff7fd9700 (LWP 29220)): #0 0x00007ffff763c85c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x0000000000506223 in ldap_pvt_thread_pool_destroy (tpool=0x7ffffffed658, run_pending=<value optimized out>) at tpool.c:582 pool = 0x844f00 pptr = 0x844f00 task = <value optimized out> #2 0x0000000000506a0a in ldap_int_thread_pool_shutdown () at tpool.c:181 pool = 0x844f00 #3 0x00000000005050a9 in ldap_pvt_thread_destroy () at threads.c:70 No locals. #4 0x0000000000466059 in slap_destroy () at init.c:273 rc = 0 #5 0x00000000004a5ade in slap_tool_destroy () at slapcommon.c:932 rc = 0 #6 0x00000000004a46e7 in slapadd (argc=0, argv=<value optimized out>) at slapadd.c:606 buf = 0x89de00 "\240Љ" text = 0x0 textbuf = '\000' <repeats 255 times> maxcsn = {{bv_len = 0, bv_val = 0x0} <repeats 3928 times>, { bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6c5e499 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a17d51 "libresolv.so.2"}, {bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdb4c0 ""}, {bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 140737488343600, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7fffffffddc0 ""}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6a0fb40 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdb4c0 ""}, {bv_len = 0, bv_val = 0x7ffff66a8bcc "ld-linux-x86-64.so.2"}, { bv_len = 140737488343600, bv_val = 0xffffffffa2000000 <Address 0xffffffffa2000000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x7ffff7dec74d "\205\300u\347H\203\304\b\270\001"}, { bv_len = 0, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 0, bv_val = 0x7ffff7de5212 "\205\300t\312H\201\304\370\003"}, { bv_len = 0, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdb000 ""}, { bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, { bv_len = 140737488343856, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 140737488346672, bv_val = 0x7 <Address 0x7 out of bounds>}, { bv_len = 140737353992808, bv_val = 0x7ffff7dea64d "H\213\205p\377\377\377\213\215\370\376\377\377L\213\205"}, {bv_len = 140737354127792, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7ffff6c2be00 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdb000 ""}, {bv_len = 0, bv_val = 0x7ffff6a17d47 "libc.so.6"}, {bv_len = 140737488343856, bv_val = 0xffffffffa4000000 <Address 0xffffffffa4000000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x7ffff7de3dae "H\203\370\377\017\205a\373\377\377L\215\r\360>\001"}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdca68 ""}, {bv_len = 1, bv_val = 0x7ffff6c5e499 "libc.so.6"}, {bv_len = 140737488344096, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7ffff6c2bf70 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353987264, bv_val = 0x0}, { bv_len = 18446744072574992384, bv_val = 0x7ffff7fdca68 ""}, { bv_len = 1, bv_val = 0x7ffff6c5e499 "libc.so.6"}, { bv_len = 140737488344096, bv_val = 0xffffffffa5e00000 <Address 0xffffffffa5e00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x218a88 <Address 0x218a88 out of bounds>}, { bv_len = 86016, bv_val = 0x3 <Address 0x3 out of bounds>}, { bv_len = 0, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdc508 ""}, { bv_len = 2, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, { bv_len = 140737488344336, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7fffffffddff ""}, { bv_len = 140737351948784, bv_val = 0x7ffff6fa2738 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353990144, bv_val = 0x7ffff7fdb4c0 ""}, { bv_len = 0, bv_val = 0x7ffff7fdc508 ""}, {bv_len = 2, bv_val = 0x7ffff6fc90f8 "libc.so.6"}, {bv_len = 140737488344336, bv_val = 0xffffffffa7c00000 <Address 0xffffffffa7c00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x1 <Address 0x1 out of bounds>}, {bv_len = 0, bv_val = 0x7ffff7de3bf5 "\366E\020\bu\016H\203\273\300"}, { bv_len = 8030813564919442479, bv_val = 0x7fffff00362e <Address 0x7fffff00362e out of bounds>}, { bv_len = 140737354129704, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 1, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 140737488344592, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7fffffffdde8 ""}, { bv_len = 140737488346608, bv_val = 0x7ffff720cee0 ""}, { bv_len = 140737353988792, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353992808, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 140737353987264, bv_val = 0x0}, { bv_len = 18446744072574992384, bv_val = 0x7ffff7fdc000 ""}, { bv_len = 1, bv_val = 0x7ffff7213869 "ld-linux-x86-64.so.2"}, { bv_len = 140737488344592, bv_val = 0xffffffffa9c00000 <Address 0xffffffffa9c00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x4d6fb0ac <Address 0x4d6fb0ac out of bounds>}, { bv_len = 331622242, bv_val = 0x4d3a077c <Address 0x4d3a077c out of bounds>}, { bv_len = 0, bv_val = 0x4d488e48 <Address 0x4d488e48 out of bounds>}, { bv_len = 530906511, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7fffffffddc0 ""}, {bv_len = 140737488346672, bv_val = 0x7ffff7fdda20 ""}, {bv_len = 2, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 140737488344864, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff7deb986 "H\213\204$\030\001"}, { bv_len = 140737354129336, bv_val = 0x7ffff7415f40 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7dea202 "I\211\234$\270\003"}, { bv_len = 140737353987264, bv_val = 0x7ffff7ffd9b0 ""}, { bv_len = 0, bv_val = 0x0}, {bv_len = 4294967296, bv_val = 0x7ffff762fc90 "\001"}, {bv_len = 18446744072574992384, bv_val = 0x7ffff7fdda20 ""}, {bv_len = 2, bv_val = 0x7ffff7419dc1 "libc.so.6"}, {bv_len = 140737488344864, bv_val = 0xffffffffabe00000 <Address 0xffffffffabe00000 out of bounds>}, {bv_len = 18446726195687325696, bv_val = 0x0}, {bv_len = 832, bv_val = 0x10102464c457f <Address 0x10102464c457f out of bounds>}, {bv_len = 0, bv_val = 0x1003e0003 <Address 0x1003e0003 out of bounds>}, { bv_len = 126304, bv_val = 0x40 <Address 0x40 out of bounds>}, { bv_len = 1567688, bv_val = 0x38004000000000 <Address 0x38004000000000 out of bounds>}, {bv_len = 19703553316618250, bv_val = 0x7fffffffddc0 ""}, { bv_len = 140737488346672, bv_val = 0x7ffff7fdd510 ""}, { bv_len = 1, bv_val = 0x7ffff7634dce "ld-linux-x86-64.so.2"}, { bv_len = 140737488345152, bv_val = 0x7ffff7de9a22 "H\211C [\303\017\037\204"}, {bv_len = 0, bv_val = 0x7ffff762fde0 ""}} sid = <value optimized out> bvtext = {bv_len = 256, bv_val = 0x7fffffffdd30 ""} attr = 0x0 ctxcsn_e = 0x0 ctxcsn_id = <value optimized out> id = <value optimized out> opbuf = {ob_op = {o_hdr = 0x7fffffffd9e0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x86ff40, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = { rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = { bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = { rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = { rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = { slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = { oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>}, ob_controls = { 0x0 <repeats 32 times>}} match = 32767 checkvals = 0 lineno = 7 nextline = 7 ldifrc = <value optimized out> lmax = 4115 rc = 0 enable_meter = 1 meter = {display = 0x589b80, display_data = 0x0, estimator = 0x589ba0, estimator_data = 0x0, start_time = 1299184379.2546861, last_update = 1299184379.2546861, goal_value = 88, last_position = 0} stat_buf = {st_dev = 21, st_ino = 6956686, st_nlink = 1, st_mode = 33188, st_uid = 1000, st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 88, st_blksize = 4096, st_blocks = 24, st_atim = {tv_sec = 1299166918, tv_nsec = 420393930}, st_mtim = { tv_sec = 1299166819, tv_nsec = 830383674}, st_ctim = { tv_sec = 1299166819, tv_nsec = 870399305}, __unused = {0, 0, 0}} __PRETTY_FUNCTION__ = "slapadd" #7 0x000000000041edc0 in main (argc=4, argv=0x7fffffffe048) at main.c:407 i = <value optimized out> no_detach = 32767 rc = 1 urls = <value optimized out> username = 0x374208 <Address 0x374208 out of bounds> groupname = 0x1 <Address 0x1 out of bounds> sandbox = 0x7fffffffdf1f "" syslogUser = 160 configfile = 0x4131e9 "__libc_start_main" configdir = 0xbf <Address 0xbf out of bounds> serverName = 0x7fffffffe380 "slapadd" scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = 0x0 syslog_unknowns = 0x0 slapd_pid_file_unlink = <value optimized out> slapd_args_file_unlink = <value optimized out> firstopt = <value optimized out> __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 03 Mar '11

03 Mar '11

--On Thursday, March 03, 2011 7:34 PM +0000 dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.24 > OS: Ubuntu 10.04 > URL: > Submission from: (NULL) (128.173.39.26) > > > When using slapadd or slapindex with the -q option, the message "Closing > DB..." is printed and then the application hangs indefinitely. Removing > the -q option allows the application to complete without issue. > > This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. I would ask you provide a full backtrace of the slapadd process after it has hung. Otherwise, this report isn't of much use. Also, if you are using the Ubuntu patches for OpenLDAP with your OpenLDAP build, you are including a known database-corrupting patch. Since you don't say how you built OpenLDAP, it is impossible for us to know if you did this or not. --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#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu 03 Mar '11

03 Mar '11

Full_Name: David Hawes Version: 2.4.24 OS: Ubuntu 10.04 URL: Submission from: (NULL) (128.173.39.26) When using slapadd or slapindex with the -q option, the message "Closing DB..." is printed and then the application hangs indefinitely. Removing the -q option allows the application to complete without issue. This occurs with Berkeley DB 4.7.25 (with patches) and 5.1.25. slapd.conf: ===== include /usr/local/openldap-2.4.24/etc/openldap/schema/core.schema pidfile /usr/local/openldap-2.4.24/var/run/slapd.pid argsfile /usr/local/openldap-2.4.24/var/run/slapd.args database bdb suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" directory /usr/local/openldap-2.4.24/var/openldap-data dbconfig set_lg_dir /usr/local/openldap-2.4.24/var/openldap-data/bdb-logs dbconfig set_lg_max 104857600 dbconfig set_lg_bsize 26214400 dbconfig set_cachesize 4 0 1 dbconfig set_flags DB_LOG_AUTOREMOVE ===== ldif: dn: dc=test,dc=com objectClass: dcObject objectClass: organization o: testorg dc: test

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 03 Mar '11

03 Mar '11

Le Mer 2 mars 2011 17:52, masarati(a)aero.polimi.it a écrit : > >> The following patch > > Please upload patches according to > <http://www.openldap.org/devel/contributing.html#submitting>. Sorry, it seems to be my fault. Here it is: ftp://ftp.openldap.org/incoming/raphael-ouazana-110302-sssvlv-fix-free_sort…

1 0

Re: (ITS#6852) Define uidNumber and gidNumber with ORDERING matching rule
by michael＠stroeder.com 03 Mar '11

03 Mar '11

Patch against current HEAD for this: Index: ./servers/slapd/schema_prep.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/schema_prep.c,v retrieving revision 1.189 diff -u -r1.189 schema_prep.c --- ./servers/slapd/schema_prep.c 4 Jan 2011 23:43:16 -0000 1.189 +++ ./servers/slapd/schema_prep.c 3 Mar 2011 11:25:59 -0000 @@ -934,6 +934,7 @@ "DESC 'RFC2307: An integer uniquely identifying a user " "in an administrative domain' " "EQUALITY integerMatch " + "ORDERING integerOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )", NULL, 0, NULL, NULL, @@ -944,6 +945,7 @@ "DESC 'RFC2307: An integer uniquely identifying a group " "in an administrative domain' " "EQUALITY integerMatch " + "ORDERING integerOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )", NULL, 0, NULL, NULL,

1 0

(ITS#6852) Define uidNumber and gidNumber with ORDERING matching rule
by michael＠stroeder.com 03 Mar '11

03 Mar '11

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.153.202.193) Please add ORDERING integerOrderingMatch to the declarations of attribute types uidNumber and gidNumber in schema_prep.c.

1 0

(ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by tedcheng＠symas.com 02 Mar '11

02 Mar '11

Full_Name: Ted C. Cheng Version: HEAD OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.80.56.88) We encountered a back-ldap assertion failure with the back-ldap as a proxy to a remote Active Directory on Windows 2003 R2. The assertion failure occurred when the slapd server was checking ACLs via the rwm overlay. Snippet of the stack trace: Thread 1 (Thread 32267): .... #2 0x0000003c354296e6 in __assert_fail () from /lib64/libc.so.6 #3 0x00002ac57daaf6c1 in ldap_back_dobind_int (lcp=0x42f70170, op=0x42f702f0, rs=0x42f700a0, sendok=LDAP_BACK_GETCONN, retries=0, dolock=1) at /home/build/sol-2.4.23.101221/sol24x/ldap24/servers/slapd/back-ldap/bind.c:1389 #4 0x00002ac57daafda0 in ldap_back_dobind (lcp=0x42f70170, op=0x42f702f0, rs=0x42f700a0, sendok=LDAP_BACK_DONTSEND) at /home/build/sol-2.4.23.101221/sol24x/ldap24/servers/slapd/back-ldap/bind.c:1572 #5 0x00002ac57daac7a7 in ldap_back_entry_get (op=0x42f702f0, ndn=0x42f701d0, oc=0x0, at=0x135ad370, rw=0, ent=0x42f70a58) Analysis of the assertion failure: The ldap_back_entry_get() function, back-ldap/search.c, is called for ACL entries, via rwm overlay. The function sets op->o_do_not_cache to 1 before calling into ldap_back_dobind(): /* Tell getconn this is a privileged op */ do_not_cache = op->o_do_not_cache; tag = op->o_tag; /* do not cache */ op->o_do_not_cache = 1; /* ldap_back_entry_get() is an entry lookup, so it does not need * to know what the entry is being looked up for */ op->o_tag = LDAP_REQ_SEARCH; rc = ldap_back_dobind( &lc, op, &rs, LDAP_BACK_DONTSEND ); The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for assertion failure, if op->o_do_not_cache flag is set and there is no valid binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI for the remote AD Windows box is such a case. ldap_back_dobind_int() { ... if (sendok & LDAP_BACK_GETCONN) { lc = ldap_back_getconn(op, rs, sendoff, &binddn, &bindcred); ... } if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred ); /* ldap_back_is_proxy_authz always returns 0 when op->o_do_not_cache is set, see below */ assert( rc == 1 );------> assertion failure } rc = ldap_back_proxy_authz_bind( lc, op, rs, sendok, &binddn, &bindcred ); } } When the op->o_do_not_cache flag is set, the ldap_back_is_proxy_authz() function always returns 0. ldap_back_is_proxy_authz( ... ) { ... int dobind = 0; if ( op->o_conn == NULL || op->o_do_not_cache ) { goto done; } ... done:; return dobind; <--- always returns 0 } Ted C. Cheng Symas Corporation

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Hi, Le Mer 2 mars 2011 17:51, masarati(a)aero.polimi.it a écrit : > >> The following patch > > Please upload patches according to > <http://www.openldap.org/devel/contributing.html#submitting>. As said in the post, no success: $ ftp ftp> open ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:raphael): ftp 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> ascii 200 Type set to A. ftp> cd incoming 250 CWD command successful. ftp> put raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch local: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch remote: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> Regards, Raphael Ouazana.

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> The following patch Please upload patches according to <http://www.openldap.org/devel/contributing.html#submitting>. p.

1 0

(ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, sssvlv support for multiple requests by conn (see ITS#6686) can segfault while releasing some connections. Indeed, the request to release can be searched by the ps_cookie. But as the ps_cookie is NULL at the end of the request (it points to so_tree), the same request can be freed multiple times. The following patch fix this issue and reinforce the rest of the code by using so to search for the matching request where it is possible. Sorry, no FTP upload, I get an error 425. It fixes a little error in the man page too. Index: doc/man/man5/slapo-sssvlv.5 =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/doc/man/man5/slapo-sssvlv.5,v retrieving revision 1.4 diff -u -r1.4 slapo-sssvlv.5 --- doc/man/man5/slapo-sssvlv.5 4 Jan 2011 23:42:55 -0000 1.4 +++ doc/man/man5/slapo-sssvlv.5 2 Mar 2011 16:40:57 -0000 @@ -17,8 +17,8 @@ Since a complete result set must be generated in memory before sorting can be performed, processing sort requests can have a large impact on the server's memory use. As such, any connection is limited to having only -one sort request active at a time. Additional limits may be configured -as described below. +a limited number of sorts requests active at a time. Additional limits may +be configured as described below. .SH CONFIGURATION These Index: servers/slapd/overlays/sssvlv.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/sssvlv.c,v retrieving revision 1.29 diff -u -r1.29 sssvlv.c --- servers/slapd/overlays/sssvlv.c 4 Jan 2011 23:43:32 -0000 1.29 +++ servers/slapd/overlays/sssvlv.c 2 Mar 2011 16:40:58 -0000 @@ -342,6 +342,23 @@ } /* Return the session id or -1 if unknown */ +static int find_session_by_so( + int svi_max_percon, + int conn_id, + sort_op *so ) +{ + int sess_id; + if (so == NULL) { + return -1; + } + for (sess_id = 0; sess_id < svi_max_percon; sess_id++) { + if ( sort_conns[conn_id] && sort_conns[conn_id][sess_id] == so ) + return sess_id; + } + return -1; +} + +/* Return the session id or -1 if unknown */ static int find_session_by_context( int svi_max_percon, int conn_id, @@ -379,14 +396,13 @@ static void free_sort_op( Connection *conn, sort_op *so ) { int sess_id; - PagedResultsCookie ps_cookie = (PagedResultsCookie) so->so_tree; if ( so->so_tree ) { tavl_free( so->so_tree, ch_free ); so->so_tree = NULL; } ldap_pvt_thread_mutex_lock( &sort_conns_mutex ); - sess_id = find_session_by_context( so->so_info->svi_max_percon, conn->c_conn_idx, so->so_vcontext, ps_cookie ); + sess_id = find_session_by_so( so->so_info->svi_max_percon, conn->c_conn_idx, so ); sort_conns[conn->c_conn_idx][sess_id] = NULL; so->so_info->svi_num--; ldap_pvt_thread_mutex_unlock( &sort_conns_mutex ); @@ -492,7 +508,7 @@ sc->sc_nkeys * sizeof(struct berval), op->o_tmpmemctx ); sn->sn_vals = (struct berval *)(sn+1); sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, vc->vc_context, NO_PS_COOKIE ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); sn->sn_vals[0] = bv; for (i=1; i<sc->sc_nkeys; i++) { BER_BVZERO( &sn->sn_vals[i] ); @@ -731,7 +747,7 @@ op->o_tmpfree( sn, op->o_tmpmemctx ); sn = sn2; sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so->so_vcontext, (PagedResultsCookie) so->so_tree ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); /* Insert into the AVL tree */ tavl_insert(&(so->so_tree), sn, node_insert, avl_dup_error); Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2011 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Lib is not relocatable although --with-pic was used. Bug?
by Kristof Van Damme 02 Mar '11

02 Mar '11

Hi all, Platform is Sun Solaris x64 10 u8. Compiler used is Sun Studio 12u1. Version is openldap-2.4.23-stable-20100719. Configure was done with CFLAGS='-xO3 -KPIC -m64 -xtarget=generic' and CC="/usr/bin/cc" $ ./configure --prefix=/opt/app/damp64 --with-pic --with-tls=openssl Compilation in 64-bit (-m64) of libldap was succesfull and installed in /opt/app/damp64/lib. If I create a simple main.c file: int main(){ return 0; } I compile (also 64-bit) and link this main.c file with libldap as a test. $ /usr/bin/cc -o conftest -xO4 -m64 -KPIC -xtarget=generic -s -I/opt/app/damp64/include -L/opt/app/damp64/lib -R/opt/app/damp64/lib main.c -lldap When I try to run this exec linked to the newly build library libldap.so I get the following error: # ./conftest ld.so.1: conftest: fatal: relocation error: R_AMD64_32: file /opt/app/damp64/lib/libldap-2.4.so.2: symbol (unknown): value 0xfffffd7fff2542f0 does not fit This is a relocation error from the linker on the libldap. But I compiled everything with -KPIC (position independent code) and gave the --with-pic option to configure. This is a serious issue, as I cannot link the library to anything else and thus it is unusable. Can I file a bug report? If I have a look in the libldap shared object, I can see .text relocations... # elfdump -d /opt/app/damp64/lib/libldap-2.4.so.2 | fgrep TEXTREL [18] TEXTREL 0 [27] FLAGS 0x4 [ TEXTREL ] Kind regards, Kristof Van Damme.

1 1

Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> Full_Name: plop > Version: > OS: ubuntu last release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.206.236.129) > > > This is what I got on a CLI: > > ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b > "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin > ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: > tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' > failed. > Abandon > > > > $ ldapsearch -V > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ > buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools > (LDAP library: OpenLDAP 20423) > ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Fixed in HEAD. Tools will refuse to start if incompatible password options are passed. I chose this solution since handling of credentials is security-related, and one would not want credentials to be handled incorrectly by a misused client. Please test. p.

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. I understand the fix I'm suggesting can sound counter-intuitive. The documentation should clearly indicate that the binddn in case of SASL is for *local* and *internal* issues, and will not be part of the authentication process. As an alternative, lc_bound_ndn could receive a dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive the actual identity from the remote server using the authid control along with the bind or performing a whoami extop later, as already implemented). p. > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. > >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- 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#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. > > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. At the time I looked at this issue, there were places in the code where after an idassert-bind the lc_bound_ndn would receive a copy of idassert's authcDN. In case of SASL, this is empty/null; then back-ldap (and meta) would fail from recognizing the connection as successfully bound. I understand there are better solutions; for example, ldapconn_t could have a "bound" flag, or so. I understand that code may need some reworking, but I can't work at that now, sorry. p. >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- 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#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> Full_Name: plop > Version: > OS: ubuntu last release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.206.236.129) > > > This is what I got on a CLI: > > ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b > "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin > ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: > tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' > failed. > Abandon You're passing both -W and -w, which are mutually exclusive. p.

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by ghenry＠OpenLDAP.org 01 Mar '11

01 Mar '11

----- Original Message ----- > --GRPZ8SYKNexpdSJ7 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > > > re: TLS Authentication Identity Format > > > > Strictly speaking, the order of components is not changed at all. > > The sequence of RDNs in the DN is what it is; just that the > > convention for *displaying* it is ass-backwards in LDAP. I'm afraid > > the wording here will confuse people into thinking that the > > *semantics* of the DN are changed, when it's only a display issue. > > Good point. Updated wording attached. > > Andrew Thanks for all this Andrew, much appreciated! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6849) ldapsearch assertion failed
by gnuround＠gmail.com 01 Mar '11

01 Mar '11

Full_Name: plop Version: OS: ubuntu last release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.206.236.129) This is what I got on a CLI: ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' failed. Abandon $ ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools (LDAP library: OpenLDAP 20423) ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ apt-cache show ldap-utils Package: ldap-utils Priority: optional Section: net Installed-Size: 768 Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Architecture: amd64 Source: openldap Version: 2.4.23-0ubuntu3 Replaces: openldap-utils, openldapd, slapd (<< 2.2.23-0.pre6) Provides: ldap-client, openldap-utils Depends: libc6 (>= 2.4), libgnutls26 (>= 2.7.14-0), libgssapi-krb5-2 (>= 1.6.dfsg.2), libldap-2.4-2 (= 2.4.23-0ubuntu3), libsasl2-2 Recommends: libsasl2-modules Conflicts: ldap-client, openldap-utils, umich-ldap-utils Filename: pool/main/o/openldap/ldap-utils_2.4.23-0ubuntu3_amd64.deb Size: 343860 MD5sum: 5c7834714c933288181d660e34c0b3d6 SHA1: a18afe09abd61bcf6a722135bb82c308104fa15c SHA256: 1b2d43b4dc82843047d6930f8e1f4145a8cf40f9435d9d58389c7acd1a4d4b04 Description-fr: Utilitaires OpenLDAP

1 0

Re: (ITS#6848) wait timeout for slapd startup
by hyc＠symas.com 01 Mar '11

01 Mar '11

andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > >> When LDAP is used as a dependency for other software during the init process (as >> a kerberos backend, for example), the fact that slapd exits with success prior >> to it being ready to accept connections can cause problems for the later >> services that depend on it. It would be useful to have an (optional) flag "-w >> <seconds>" that if provided, would have slapd wait up until<seconds> amount of >> time has passed for the daemon to fully initialize. > > Some distros already deal with this in other ways - e.g. OpenSuSE waits > until an ldapsearch on the null DN succeeds. This is done in the init.d > script. This is still by far the best solution. The current patch simply shifts the slapd parent process' exit a little later, to after the databases are started up. The listener thread still has not yet been created by this time. On a lightly loaded system the time till that is running should be trivial, but on a heavily loaded system who knows. > One advantage of putting explicit support into OpenLDAP for this is > that it may be possible to have an option to delay starting the > listners on a replication consumer until a full refresh has been done > from the master (this would need a timeout option too). There are > obvious deadlock issues in multi-master configs, but admins would at > least have the option of using this on pure consumers. We've discussed this option many times in the past but it generally seems to come out being more bad than good. Also it implies an expectation for consistency that simply isn't offered by the syncrepl spec. Best to leave this alone for now. When we get to LDAP Transactions, and figuring out how to represent them in a syncrepl exchange, then it would be meaningful. -- -- 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#6848) wait timeout for slapd startup
by andrew.findlay＠skills-1st.co.uk 01 Mar '11

01 Mar '11

On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > When LDAP is used as a dependency for other software during the init process (as > a kerberos backend, for example), the fact that slapd exits with success prior > to it being ready to accept connections can cause problems for the later > services that depend on it. It would be useful to have an (optional) flag "-w > <seconds>" that if provided, would have slapd wait up until <seconds> amount of > time has passed for the daemon to fully initialize. Some distros already deal with this in other ways - e.g. OpenSuSE waits until an ldapsearch on the null DN succeeds. This is done in the init.d script. One advantage of putting explicit support into OpenLDAP for this is that it may be possible to have an option to delay starting the listners on a replication consumer until a full refresh has been done from the master (this would need a timeout option too). There are obvious deadlock issues in multi-master configs, but admins would at least have the option of using this on pure consumers. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#6845) sortvals oddities - with more information
by hyc＠symas.com 28 Feb '11

28 Feb '11

Andrew Elble wrote: > Howard Chu<hyc(a)symas.com> writes: > >>> It would seem that attr_merge() (in attr.c) should have something like this: >>> >>> if ( *a == NULL ) { >>> *a = attr_alloc( desc ); >>> if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { >>> (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; >>> } >>> } else { >> >> This is now fixed in HEAD in value.c. > > Tested, bad behavior still persists. The call path I've observed > is as follows: > > T@5 : | | | | |>bdb_modify_internal > T@5 : | | | | | |>modify_add_values > T@5 : | | | | | | |>attr_merge > T@5 : | | | | | | | |>attr_alloc > > ordered_value_add() doesn't seem to be involved (I can provide the > entire trace if necessary) Thanks, my mistake. Fixed now in HEAD attr.c (redundant code removed from add.c) -- -- 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#6848) wait timeout for slapd startup
by quanah＠OpenLDAP.org 28 Feb '11

28 Feb '11

Full_Name: Quanah Gibson-Mount Version: 2.4.24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When LDAP is used as a dependency for other software during the init process (as a kerberos backend, for example), the fact that slapd exits with success prior to it being ready to accept connections can cause problems for the later services that depend on it. It would be useful to have an (optional) flag "-w <seconds>" that if provided, would have slapd wait up until <seconds> amount of time has passed for the daemon to fully initialize. If it fails to initialize and be ready to accept connections by the end of the time period (when specified), slapd should exit with a new unique error code. This would allow for avoiding the startup problem. An example of this (and a terrible solution) can be found in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589915 Debian implemented a broken solution for this, but it is a general issue for anyone who has dependencies on slapd being ready.

1 0

Re: (ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 28 Feb '11

28 Feb '11

> On 02/28/2011 04:57 AM, Howard Chu wrote: >> Right, no problem. I've run your updated script against HEAD and see no >> errors, nor is there a duplicate result sent for the Bind operation. > > That's a good datapoint. I'll look into building HEAD on my system and > validate that the duplicate result messages are gone. I was able to build HEAD pretty quickly (much quicker than I've been able to in the past :-) ), and was able to validate that the test succeeds. -Kartik

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs