- openldap-bugs - openldap.org

(ITS#6385) Shutdown of broken syncrepl stanza cores
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando The test for SLAP_SYNC_SUBENTRY() is done on a NULL BackendDB *. A fix is coming. p.

1 0

Re: (ITS#6383) Very Slow Query Response
by rra＠stanford.edu 17 Nov '09

17 Nov '09

quanah(a)zimbra.com writes: > For historical note this was caused by Cyrus-sasl being built > incorrectly by the debian packagers when heimdal is used. Well, rather, that's a theory which currently looks good. It definitely hasn't been proven yet. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#6383) Very Slow Query Response
by quanah＠zimbra.com 17 Nov '09

17 Nov '09

On Nov 16, 2009, at 9:03 PM, Bill MacAllister <whm(a)stanford.edu> wrote: > > > --On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > >> >> >> --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: >> >>> Full_Name: Bill MacAllister >>> Version: 2.4.19+ >>> OS: Debian 5 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (171.64.19.165) >>> >>> >>> On a system where slapd is the top CPU process and is consuming 4% >>> of the >>> CPU simple queries are taking ten of seconds to complete. Here is >>> an >>> example query: >> >> Last time we saw this it appeared that it might be related to DNS. >> How long does a netstat -a take on the affected systems when the >> LDAP queries are slow? > > I don't have that number. I have only see it once in the test > environment I am not sure how long it will take me to get it. Since > this plastered the production service today, I will have to reproduce > it though before we attempt another production upgrade. > > Not clear to me why a DNS issue would appear only under load and not > at other times. And it seems strange that it appears in > lenny/openldap-2.4 and not in etch/openldap-2.3. > > Bill > > -- > Bill MacAllister, System Software Programmer > Unix Systems Group, Stanford University For historical note this was caused by Cyrus-sasl being built incorrectly by the debian packagers when heimdal is used. --Quanah

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by masarati＠aero.polimi.it 17 Nov '09

17 Nov '09

> sorry for two consecutive mails but I hit send before finishing to > think... where does is this bit about comments in the manual page? It > seems I'm not able to find it (nor the search facility in man too). I'm > doing man 5 ldap.conf, the man has all the configuration variables > explained well but not a word about where to put comments. Hash marks as line-long comment indicators is documented in slapd.conf(5). It is also documented in recent 2.4 ldap.conf(5). p.

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

sorry for two consecutive mails but I hit send before finishing to think... where does is this bit about comments in the manual page? It seems I'm not able to find it (nor the search facility in man too). I'm doing man 5 ldap.conf, the man has all the configuration variables explained well but not a word about where to put comments.

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

> Not a bug. Only lines beginning with "#" are comments as documented in > ldap.conf(5). yes, it might be a cool new feature... :)

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by rein＠OpenLDAP.org 17 Nov '09

17 Nov '09

luca.pasquali(a)dada.net wrote: > in ldap.conf if i configure like this: > > dorius01 ~ # cat /etc/ldap.conf | head -2 > base dc=dada,dc=net > uri ldaps://ldap.us.backplane/ > dorius01 ~ # > > all works, but if I put a comment like this: > > dorius01 ~ # cat /etc/ldap.conf | head -2 > base dc=dada,dc=net > uri ldaps://ldap.us.backplane/ # foobar comment blah blah... > dorius01 ~ # > > this does not work at all and I'm not able to login via ldap+ssh, for istance. Not a bug. Only lines beginning with "#" are comments as documented in ldap.conf(5). Rein

1 0

(ITS#6384) ldap.conf - problem with comments
by luca.pasquali＠dada.net 17 Nov '09

17 Nov '09

Full_Name: luca pasquali Version: 2.4.19 OS: gentoo GNU/Linux URL: Submission from: (NULL) (195.110.97.5) in ldap.conf if i configure like this: dorius01 ~ # cat /etc/ldap.conf | head -2 base dc=dada,dc=net uri ldaps://ldap.us.backplane/ dorius01 ~ # all works, but if I put a comment like this: dorius01 ~ # cat /etc/ldap.conf | head -2 base dc=dada,dc=net uri ldaps://ldap.us.backplane/ # foobar comment blah blah... dorius01 ~ # this does not work at all and I'm not able to login via ldap+ssh, for istance.

1 0

Re: (ITS#6383) Very Slow Query Response
by whm＠stanford.edu 16 Nov '09

16 Nov '09

--On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: > >> Full_Name: Bill MacAllister >> Version: 2.4.19+ >> OS: Debian 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> >> On a system where slapd is the top CPU process and is consuming 4% of the >> CPU simple queries are taking ten of seconds to complete. Here is an >> example query: > > Last time we saw this it appeared that it might be related to DNS. > How long does a netstat -a take on the affected systems when the > LDAP queries are slow? I don't have that number. I have only see it once in the test environment I am not sure how long it will take me to get it. Since this plastered the production service today, I will have to reproduce it though before we attempt another production upgrade. Not clear to me why a DNS issue would appear only under load and not at other times. And it seems strange that it appears in lenny/openldap-2.4 and not in etch/openldap-2.3. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6383) Very Slow Query Response
by quanah＠zimbra.com 16 Nov '09

16 Nov '09

--On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: 2.4.19+ > OS: Debian 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.165) > > > On a system where slapd is the top CPU process and is consuming 4% of the > CPU simple queries are taking ten of seconds to complete. Here is an > example query: Last time we saw this it appeared that it might be related to DNS. How long does a netstat -a take on the affected systems when the LDAP queries are slow? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6383) Very Slow Query Response
by whm＠stanford.edu 16 Nov '09

16 Nov '09

Full_Name: Bill MacAllister Version: 2.4.19+ OS: Debian 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) On a system where slapd is the top CPU process and is consuming 4% of the CPU simple queries are taking ten of seconds to complete. Here is an example query: % time ldapsearch -x -h ldap1.stanford.edu -b dc=stanford,dc=edu uid=whm # extended LDIF # # LDAPv3 # base <dc=stanford,dc=edu> with scope subtree # filter: uid=whm # requesting: ALL # ...data... # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 0.001u 0.000s 0:18.13 0.0% 0+0k 0+0io 0pf+0w Here is a backtrace: ldap1:/var/log# gdb slapd 24029 GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Attaching to program: /usr/sbin/slapd, process 24029 Reading symbols from /usr/lib/libtcmalloc_minimal.so.0...done. Loaded symbols for /usr/lib/libtcmalloc_minimal.so.0 Reading symbols from /usr/lib/libldap_r-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/libldap_r-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/libldap_r-2.4.so.2 Reading symbols from /usr/lib/liblber-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/liblber-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/liblber-2.4.so.2 Reading symbols from /usr/lib/libdb-4.8.so...Reading symbols from /usr/lib/debug/usr/lib/libdb-4.8.so.debug...done. done. Loaded symbols for /usr/lib/libdb-4.8.so Reading symbols from /usr/lib/libodbc.so.1...done. Loaded symbols for /usr/lib/libodbc.so.1 Reading symbols from /usr/lib/libslp.so.1...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/libssl.so.0.9.8 Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f89261b86f0 (LWP 24029)] [New Thread 0x44bef950 (LWP 24047)] [New Thread 0x443ee950 (LWP 24046)] [New Thread 0x40a74950 (LWP 24045)] [New Thread 0x43bed950 (LWP 24044)] [New Thread 0x433ec950 (LWP 24043)] [New Thread 0x42beb950 (LWP 24042)] [New Thread 0x423ea950 (LWP 24041)] [New Thread 0x41be9950 (LWP 24040)] [New Thread 0x413e8950 (LWP 24039)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/libdb-4.6.so...done. Loaded symbols for /usr/lib/libdb-4.6.so Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 Reading symbols from /usr/lib/libgssapi.so.2...done. Loaded symbols for /usr/lib/libgssapi.so.2 Reading symbols from /usr/lib/libkrb5.so.25...done. Loaded symbols for /usr/lib/libkrb5.so.25 Reading symbols from /usr/lib/libasn1.so.8...done. Loaded symbols for /usr/lib/libasn1.so.8 Reading symbols from /usr/lib/libroken.so.18...done. Loaded symbols for /usr/lib/libroken.so.18 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libheimntlm.so.0...done. Loaded symbols for /usr/lib/libheimntlm.so.0 Reading symbols from /usr/lib/libhx509.so.3...done. Loaded symbols for /usr/lib/libhx509.so.3 Reading symbols from /usr/lib/libwind.so.0...done. Loaded symbols for /usr/lib/libwind.so.0 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/lib/ldap/back_hdb-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/back_hdb-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/back_hdb-2.4.so.2 Reading symbols from /usr/lib/ldap/back_monitor-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/back_monitor-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/back_monitor-2.4.so.2 Reading symbols from /usr/lib/ldap/valsort-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/valsort-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/valsort-2.4.so.2 Reading symbols from /usr/lib/ldap/dynlist-2.4.so.2...Reading symbols from /usr/lib/debug/usr/lib/ldap/dynlist-2.4.so.2.5.2...done. done. Loaded symbols for /usr/lib/ldap/dynlist-2.4.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 (gdb) thr apply all bt Thread 10 (Thread 0x413e8950 (LWP 24039)): #0 0x00007f8923e15b78 in epoll_wait () from /lib/libc.so.6 #1 0x0000000000438fdf in slapd_daemon_task (ptr=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/daemon.c:2460 #2 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f8923e155ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 0x41be9950 (LWP 24040)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x3c2e2be0, buf=0x39a3740 "0\202\001�002\001\004d\202\001�\004*uid=carimer,cn=accounts,dc=stanford,dc=edu0\202\001\2170>\004\tsuService11\004\006dialin\004\003afs\004\006leland\004\005email\004\003pts\004\004seas\004\bkerberos0\020\004\003uid1\t\004\acarimer0\034\004\020suKerberosStatus1\b\004\006active0\031\004\rsuEmailStatus1\b\004\006active0\201"..., len=458, dst=0x3c2e2c50) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x37a3f420, buf=0x39a3740, len=458) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x3c2feb10, buf=0x39a3740, len=458) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x3ca3d300, buf=0x39a3740, len=458) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x3ca3d300, ber=0x41a674e0, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x3a875800, ber=0x41a674e0) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x0000000000455857 in slap_send_search_entry (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:1260 #16 0x00007f8920597320 in hdb_search (op=0x3a875800, rs=0x41be8c90) at search.c:961 #17 0x00000000004c70be in overlay_op_walk (op=0x3a875800, rs=0x41be8c90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #18 0x00000000004c72e5 in over_op_func (op=0x3a875800, rs=0x41be8c90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #19 0x00000000004c73b3 in over_op_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #20 0x0000000000440844 in fe_op_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #21 0x00000000004401af in do_search (op=0x3a875800, rs=0x41be8c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #22 0x000000000043cbd6 in connection_operation (ctx=0x41be8de0, arg_v=0x3a875800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #23 0x000000000043d162 in connection_read_thread (ctx=0x41be8de0, argv=0x91) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #24 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #25 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #26 0x00007f8923e155ad in clone () from /lib/libc.so.6 #27 0x0000000000000000 in ?? () Thread 8 (Thread 0x423ea950 (LWP 24041)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df18a4 in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00000000004a85d0 in slap_sasl_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1528 #8 0x0000000000464126 in fe_op_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #9 0x0000000000463d2b in do_bind (op=0x3bb9b800, rs=0x423e9c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #10 0x000000000043cbd6 in connection_operation (ctx=0x423e9de0, arg_v=0x3bb9b800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #11 0x000000000043d162 in connection_read_thread (ctx=0x423e9de0, argv=0x94) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #12 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #13 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f8923e155ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 7 (Thread 0x42beb950 (LWP 24042)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df16f0 in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f0510e in sasl_server_start () from /usr/lib/libsasl2.so.2 #8 0x00000000004a8599 in slap_sasl_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1522 #9 0x0000000000464126 in fe_op_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #10 0x0000000000463d2b in do_bind (op=0x340cd800, rs=0x42beac90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #11 0x000000000043cbd6 in connection_operation (ctx=0x42beade0, arg_v=0x340cd800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #12 0x000000000043d162 in connection_read_thread (ctx=0x42beade0, argv=0x29) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #13 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #14 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #15 0x00007f8923e155ad in clone () from /lib/libc.so.6 #16 0x0000000000000000 in ?? () Thread 6 (Thread 0x433ec950 (LWP 24043)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x2e29e000, buf=0xe58cc10 "0\r\002\002\004He\a\n\001", len=15, dst=0x2e29e070) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x2e3f50f0, buf=0xe58cc10, len=15) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x2e389b70, buf=0xe58cc10, len=15) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x2e3b88d0, buf=0xe58cc10, len=15) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x2e3b88d0, ber=0x4326a480, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x33ce9400, ber=0x4326a480) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x00000000004528a1 in send_ldap_response (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:548 #16 0x00000000004531ee in slap_send_ldap_result (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:706 #17 0x00007f892059765d in hdb_search (op=0x33ce9400, rs=0x433ebc90) at search.c:1028 #18 0x00000000004c70be in overlay_op_walk (op=0x33ce9400, rs=0x433ebc90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #19 0x00000000004c72e5 in over_op_func (op=0x33ce9400, rs=0x433ebc90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #20 0x00000000004c73b3 in over_op_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #21 0x0000000000440844 in fe_op_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #22 0x00000000004401af in do_search (op=0x33ce9400, rs=0x433ebc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #23 0x000000000043cbd6 in connection_operation (ctx=0x433ebde0, arg_v=0x33ce9400) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #24 0x000000000043d162 in connection_read_thread (ctx=0x433ebde0, argv=0x17) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #25 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #26 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #27 0x00007f8923e155ad in clone () from /lib/libc.so.6 #28 0x0000000000000000 in ?? () Thread 5 (Thread 0x43bed950 (LWP 24044)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2ebbed8) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x000000000043c414 in connection_next (c=0x2ebbec0, index=0x43beb96c) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:893 #5 0x00007f892036adfa in monitor_subsys_conn_create (op=0x32d96c00, rs=0x43becc90, ndn=0x0, e_parent=0x3b680f8, ep=0x43beba48) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/conn.c:500 #6 0x00007f8920365077 in monitor_entry_create (op=0x32d96c00, rs=0x43becc90, ndn=0x0, e_parent=0x3b680f8, ep=0x43beba48) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/entry.c:90 #7 0x00007f8920363420 in monitor_send_children (op=0x32d96c00, rs=0x43becc90, e_parent=0x3b680f8, sub=1) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:53 #8 0x00007f89203635c7 in monitor_send_children (op=0x32d96c00, rs=0x43becc90, e_parent=0x3b68058, sub=1) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:123 #9 0x00007f8920363a13 in monitor_back_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/back-monitor/search.c:245 #10 0x0000000000440844 in fe_op_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #11 0x00000000004401af in do_search (op=0x32d96c00, rs=0x43becc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #12 0x000000000043cbd6 in connection_operation (ctx=0x43becde0, arg_v=0x32d96c00) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #13 0x000000000043d162 in connection_read_thread (ctx=0x43becde0, argv=0x69) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #14 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #15 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #16 0x00007f8923e155ad in clone () from /lib/libc.so.6 #17 0x0000000000000000 in ?? () Thread 4 (Thread 0x40a74950 (LWP 24045)): #0 0x00007f8923e0ece2 in select () from /lib/libc.so.6 #1 0x00007f892193e729 in ?? () from /usr/lib/libkrb5.so.25 #2 0x00007f892193edce in krb5_sendto () from /usr/lib/libkrb5.so.25 #3 0x00007f892193f06f in krb5_sendto_context () from /usr/lib/libkrb5.so.25 #4 0x00007f892191eb34 in ?? () from /usr/lib/libkrb5.so.25 #5 0x00007f892191efbf in ?? () from /usr/lib/libkrb5.so.25 #6 0x00007f892191f89b in ?? () from /usr/lib/libkrb5.so.25 #7 0x00007f892191f94e in ?? () from /usr/lib/libkrb5.so.25 #8 0x00007f8921920054 in krb5_get_credentials_with_flags () from /usr/lib/libkrb5.so.25 #9 0x00007f89219300c2 in krb5_mk_req_exact () from /usr/lib/libkrb5.so.25 #10 0x00007f8921919a9c in ?? () from /usr/lib/libkrb5.so.25 #11 0x00007f8921919eb8 in krb5_digest_probe () from /usr/lib/libkrb5.so.25 #12 0x00007f8921bddf1b in ?? () from /usr/lib/libgssapi.so.2 #13 0x00007f8921bdbcd9 in ?? () from /usr/lib/libgssapi.so.2 #14 0x00007f8921bd60cc in gss_acquire_cred () from /usr/lib/libgssapi.so.2 #15 0x00007f8921be13f1 in ?? () from /usr/lib/libgssapi.so.2 #16 0x00007f8921bd60cc in gss_acquire_cred () from /usr/lib/libgssapi.so.2 #17 0x00007f8921df17ef in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #18 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #19 0x00007f8924f0510e in sasl_server_start () from /usr/lib/libsasl2.so.2 #20 0x00000000004a8599 in slap_sasl_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1522 #21 0x0000000000464126 in fe_op_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #22 0x0000000000463d2b in do_bind (op=0x3c185800, rs=0x40a73c90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #23 0x000000000043cbd6 in connection_operation (ctx=0x40a73de0, arg_v=0x3c185800) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #24 0x000000000043d162 in connection_read_thread (ctx=0x40a73de0, argv=0x93) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #25 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #26 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #27 0x00007f8923e155ad in clone () from /lib/libc.so.6 #28 0x0000000000000000 in ?? () Thread 3 (Thread 0x443ee950 (LWP 24046)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df1c8e in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f03dbf in sasl_server_step () from /usr/lib/libsasl2.so.2 #7 0x00000000004a85d0 in slap_sasl_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/sasl.c:1528 #8 0x0000000000464126 in fe_op_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:280 #9 0x0000000000463d2b in do_bind (op=0x354b8c00, rs=0x443edc90) at /tmp/buildd/openldap-2.4.19/servers/slapd/bind.c:205 #10 0x000000000043cbd6 in connection_operation (ctx=0x443edde0, arg_v=0x354b8c00) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #11 0x000000000043d162 in connection_read_thread (ctx=0x443edde0, argv=0x96) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #12 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #13 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f8923e155ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 2 (Thread 0x44bef950 (LWP 24047)): #0 0x00007f89240a6384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f89240a1bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f89240a14fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f8925b1c6e5 in ldap_pvt_thread_mutex_lock (mutex=0x2aad8d0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:296 #4 0x00007f8925b264e9 in ldap_pvt_sasl_mutex_lock (mutex=0x2aad8d0) at cyrus.c:1160 #5 0x00007f8921df100d in ?? () from /usr/lib/sasl2/libgssapiv2.so.2 #6 0x00007f8924f00500 in ?? () from /usr/lib/libsasl2.so.2 #7 0x00007f8924f00aca in sasl_encodev () from /usr/lib/libsasl2.so.2 #8 0x00007f8924f00b72 in sasl_encode () from /usr/lib/libsasl2.so.2 #9 0x00007f8925b24585 in sb_sasl_cyrus_encode (p=0x3c934960, buf=0xfdea740 "0\202\001�002\001\004d\202\001�\004(uid=tayah,cn=accounts,dc=stanford,dc=edu0\202\001\2150>\004\tsuService11\004\006dialin\004\003afs\004\006leland\004\005email\004\004seas\004\003pts\004\bkerberos0\016\004\003uid1\a\004\005tayah0\034\004\020suKerberosStatus1\b\004\006active0\031\004\rsuEmailStatus1\b\004\006active0\201�\004\vo"..., len=454, dst=0x3c9349d0) at cyrus.c:165 #10 0x00007f8925b298a1 in sb_sasl_generic_write (sbiod=0x3cb61690, buf=0xfdea740, len=454) at sasl.c:716 #11 0x00007f8925905b70 in sb_debug_write (sbiod=0x3ca07cc0, buf=0xfdea740, len=454) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:852 #12 0x00007f8925904f61 in ber_int_sb_write (sb=0x3caca750, buf=0xfdea740, len=454) at /tmp/buildd/openldap-2.4.19/libraries/liblber/sockbuf.c:445 #13 0x00007f892590112e in ber_flush2 (sb=0x3caca750, ber=0x44a6d4e0, freeit=0) at /tmp/buildd/openldap-2.4.19/libraries/liblber/io.c:246 #14 0x0000000000451c56 in send_ldap_ber (op=0x3c185000, ber=0x44a6d4e0) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:191 #15 0x0000000000455857 in slap_send_search_entry (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/result.c:1260 #16 0x00007f8920597320 in hdb_search (op=0x3c185000, rs=0x44beec90) at search.c:961 #17 0x00000000004c70be in overlay_op_walk (op=0x3c185000, rs=0x44beec90, which=op_search, oi=0x2e0fa00, on=0x0) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:669 #18 0x00000000004c72e5 in over_op_func (op=0x3c185000, rs=0x44beec90, which=op_search) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:721 #19 0x00000000004c73b3 in over_op_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/backover.c:748 #20 0x0000000000440844 in fe_op_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:366 #21 0x00000000004401af in do_search (op=0x3c185000, rs=0x44beec90) at /tmp/buildd/openldap-2.4.19/servers/slapd/search.c:217 #22 0x000000000043cbd6 in connection_operation (ctx=0x44beede0, arg_v=0x3c185000) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1123 #23 0x000000000043d162 in connection_read_thread (ctx=0x44beede0, argv=0x82) at /tmp/buildd/openldap-2.4.19/servers/slapd/connection.c:1259 #24 0x00007f8925b1b19d in ldap_int_thread_pool_wrapper (xpool=0x2d48000) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/tpool.c:685 #25 0x00007f892409ffc7 in start_thread () from /lib/libpthread.so.0 #26 0x00007f8923e155ad in clone () from /lib/libc.so.6 #27 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f89261b86f0 (LWP 24029)): #0 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 #1 0x00007f8925b1c5f3 in ldap_pvt_thread_join (thread=1094617424, thread_return=0x0) at /tmp/buildd/openldap-2.4.19/libraries/libldap_r/thr_posix.c:197 #2 0x0000000000439d2e in slapd_daemon () at /tmp/buildd/openldap-2.4.19/servers/slapd/daemon.c:2835 #3 0x000000000041afdd in main (argc=3, argv=0x7fff0941e0b8) at /tmp/buildd/openldap-2.4.19/servers/slapd/main.c:950 #0 0x00007f89240a0715 in pthread_join () from /lib/libpthread.so.0 (gdb)

1 0

(ITS#6382) Error in set example (groups of groups)
by andreas＠canonical.com 16 Nov '09

16 Nov '09

Full_Name: Andreas Hasenack Version: head OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-hasenack-091116.tar.gz Submission from: (NULL) (63.133.153.66) The picture set-recursivegroup.png has a typo in the reference to accountadm. It should be under ou=group, not ou=people, in the upper left box. For reference, it's published here: http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… The andreas-hasenack-091116.tar.gz tarball I'm uploading has a fixed .svg file (the source) as well as an exported png one. I wrongly uploaded that file as openldap-guide-fix.tar.gz: you can delete that one.

1 0

RE : RE : (ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 16 Nov '09

16 Nov '09

i made the test look's good thank's Regard's=20 Olivier ________________________________________ De : Howard Chu [hyc(a)symas.com] Date d'envoi : dimanche 15 novembre 2009 19:16 =C0 : CHIROSSEL Olivier Cc : openldap-its(a)openldap.org Objet : Re: RE : (ITS#6367) syncprov ... changed by peer, ignored CHIROSSEL Olivier wrote: > sorry for this > > the url is ok now Thanks. This is now fixed in HEAD. > > Cdt, > > Olivier > ________________________________________ > De : Howard Chu [hyc(a)symas.com] > Date d'envoi : vendredi 13 novembre 2009 23:33 > =C0 : CHIROSSEL Olivier > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored > > olivier.chirossel(a)sfr.com wrote: >> Full_Name: olivier chirossel >> Version: 2.4.17 and 2.4.19 >> OS: linux >> URL: http://86.64.145.174:8080/ >> Submission from: (NULL) (62.39.9.251) >> >> >> in refreshend persist mode, the replication is incorrect for an entry wh= ich be >> delete/add after master restart and before the reconnection of the slave= . > >> 2) master set up >> >> on /etc/openldap tar xvf slapd_master.tar (get on the url ) > > The URL you provided always times out for me, so I've been unable to set = up > this test. > -- -- 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#6290 dynamic group documentation
by jonathan＠phillipoux.net 16 Nov '09

16 Nov '09

This is a multi-part message in MIME format. --------------060504090007030105050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 16/11/2009 03:30, hyc(a)symas.com wrote: > Yeah, the example should have used groupOfURLs instead of groupOfNames. Notice > that "member" is not a valid attribute in the groupOfURLs class: it can not be > used to store static members, only dynamic references. Quick patch to fix this attached. Note that the PNG image in admin/allusersgroup-en.png needs to be regenerated from source SVG - the PNG is also attached. -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------060504090007030105050009 Content-Type: text/x-diff; name="admin-guide-its-6290.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="admin-guide-its-6290.patch" Index: images/src/allusersgroup-en.svg =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/images/src/allusersgroup-en.svg,v retrieving revision 1.1 diff -u -p -u -r1.1 allusersgroup-en.svg --- images/src/allusersgroup-en.svg 7 Nov 2007 22:52:55 -0000 1.1 +++ images/src/allusersgroup-en.svg 16 Nov 2009 10:15:30 -0000 @@ -106,7 +106,7 @@ y="78.033184" id="tspan5379">objectClass: <tspan style="font-weight:bold" - id="tspan5396">groupOfNames</tspan></tspan><tspan + id="tspan5396">groupOfURLs</tspan></tspan><tspan sodipodi:role="line" x="116.88309" y="92.036435" Index: admin/overlays.sdf =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/overlays.sdf,v retrieving revision 1.46 diff -u -p -u -r1.46 overlays.sdf --- admin/overlays.sdf 19 Aug 2009 17:23:43 -0000 1.46 +++ admin/overlays.sdf 16 Nov 2009 10:15:31 -0000 @@ -551,18 +551,23 @@ directory. In {{F:slapd.conf}}(5): +> include /path/to/dyngroup.schema +> ... > overlay dynlist -> dynlist-attrset groupOfNames labeledURI member +> dynlist-attrset groupOfURLs labeledURI member + +Note that we must include the {{F:dyngroup.schema}} file that defines the +{{F:groupOfURLs}} objectClass used in this example. Let's apply it to the following entry: > cn=allusers,ou=group,dc=example,dc=com > cn: all -> objectClass: groupOfNames +> objectClass: groupOfURLs > labeledURI: ldap:///ou=people,dc=example,dc=com??one?(objectClass=inetOrgPerson) The behavior is similar to the dynamic list configuration we had before: -whenever an entry with the {{F:groupOfNames}} object class is retrieved, the +whenever an entry with the {{F:groupOfURLs}} object class is retrieved, the search specified in the {{F:labeledURI}} attribute is performed. But this time, only the distinguished names of the results are added, and as values of the {{F:member}} attribute. Index: admin/allusersgroup-en.png =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/allusersgroup-en.png,v retrieving revision 1.1 diff -u -p -u -r1.1 allusersgroup-en.png Binary files /tmp/cvsEkGNLJ and allusersgroup-en.png differ --------------060504090007030105050009 Content-Type: image/png; name="allusersgroup-en.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="allusersgroup-en.png" iVBORw0KGgoAAAANSUhEUgAAAaMAAABsCAYAAADHXN0hAAAABHNCSVQICAgIfAhkiAAAIABJ REFUeJztnXecFEX2wL87s5HdZZe4JIkCKmIigyhggMPjlKAIKEbEAKbzPL3g6ZnwZzgVFRUV 9cSAopJEPZKCZMlIhiUvcQPLApvm98frdnp6e7p7dnd2dqG+n898dru7pqr6dU29rqpX70Wh KE98ka6AQqFQVEWiI12B05CmQE6kK6FQKBRViHeVMip/soDsSFdCoVAoqhD5nkjXQHFakQ60 t/hfUfl5CRgT6UpEgHTKp52eqfIrN5QyqhjWIetJxcioaTFwP+A1pckBahnO3Qgsr6A6KhQK RcRQyqjiuAWIBZoBzwKjgc9MaQqAv1ZwvU4Hqvp0c1Wvv0JRZpQyqjiKgULgKDAN+CMwEOhg SPMf4G6gXpA8BgJDbMpoouWdA2QCHxmuZSCK7hdgG/A5EBPqTQDPAXuA48BvQG8X3ykk8J5e BZ4xHL8AHELW27YBnbTzjZD7ydbq/3fDdzKAx4FlwGqHfMycDywAcpFpmttCqKtb2gNrkecw HXiPwGkcq/qXpV4ZwD+B+cAG4GMg3qZ+lwBrDPVLNV23a0tuCfb8WiC/g0u04wbIc+uhHdu1 sQzgXmATIqeXgbOAn4A8YBaQbErvVi527c1MRcjPLg+7thKqjBSnIT4gxeL8OuAmi/OrgYcN aQYhDe517Zx5mu5t4JMgZXuB9cArQAKiaLoYrmcgIzGv9llCYAN2y0CgJhAFDEc6/mratXSs 14zsOtIuWto62nEjoCHyorQK6cBjkQ5rIyIj/X6+1u4zyiYfMzHADqSj8SAvAzlANxd1dUsM sBsYpR13RToFszIy1r+s9coAvkGerUfL+zmb+u0EHtLKvhzppPT6ObUlNzg9vxGIoqkG/ICs uejYtbEMLX0q0Bw4AiwEWgNJiNJ51JCXk1zSkXbqVF8jFSE/uzyc2kqoMqoMTIx0BU43QlVG s4CnDWkGIY3nGPImE8qaUVek0QWb8snA31hBpgpfMxxP0tJYfWbYlLsV/wgkndCV0YXAQaAX gSO1TsgbqnFdbTQyotPvp6fhWrB8zHRH3sKNswLjgDdc1BXcyekyYK+p3C8pqYyM9S9rvTKA qwzHvZDRoRXdgQNIR6rzraF+Tm3JjQycnh/AVGT0uAaIC1IWBLaxDOBKU72NcniQwI7NSS7p SDt1U1+dipCfXR5ObSVUGVUGJqq56shSB5muMLId+BR4ApgdQl71gV1IpxUMo8n5CQKNJUYS vEPIN6W7B6itldUAedsqLauBfwAvAi2BmUgn0Eirz3pD2lj8U1ogP0infA6ayktDpoCKDed2 Au1c1teNnOoC+0zX9likN9a/rPUC6SCN/6cFSZem5W3cpL3D8L9TW3IjAzfPbzyikO4CTpny t2tjGYb/T1ocm+vmRi5u6qtTEfKzy8NNWwlVRhFHKaPI0RKZ951vce0ZZH47PYT89iGjKS9Q VIr6vIdMN1ixHOgDtAGeR97aNmrXNhP4hmhFPoGNPwWZttJ5V/vUAiYg0w+TgMPAubj3bGGV zwOmNAeQjseD/8fcGH+H5VRXN3I6iHSgRhoRfKRSHvUC2XC9xvD/Aaw5gChMI3WRqUVwbktu ZJCB/fNLQkZ37wNPApORF7PStjE7muIsF6f6GqkI+dnl4dRWqiTKgKHi8CDKvwZwDbLoORnr abjdwAf415N07AwYliCN8XlkgTbUeeqRwEVBPjdraZKREVW6dnwVolSdWI1/2qAx0M9w7Txk ztuDTE8e1/5fhHROTyFz5gCtCL4nJFg+ELjWthiZ339Uu94OGIZ/OsauruBOTouQDu0+7bgL 0sHYUdZ6ATyCrBOkAH9DFLqOWQYeoK923BQxqNFxaktuZWD3/F5D2v6dyNTU29r50rYxO+zk ouNU34qWn10eTm1FobBdM/JpnxxgKfLGHm1KY1wsrYd0qG4NGEB+FDOQzjgT+NBwLQMZien8 A38H4JYoZF56KzAHMbRYh7+TTMd6zagTMtJbjiwmT8Q/h90JeWvNQRaqp+A3QmiIKOws7br+ 1mh1P3b5zECsi3QuQBZ0c5GpkDtN+QSrayh0RKZ8dGurD5B1Oh1z/ctarwykTW1CZPAJ/k4V SsqgPbASsa6chkwNG9e0mhK8Lbkl2PO7FllTq6mlS0La1DCc25hZbp/jNxQBsUb9ynDsJJd0 /O3Urr1FQn52edi1lVBlVBmobGtYVZ5gykgRObxIJx7pOfLJyBpWuLBSbjqVRQaRwE4ubjmT 5VdRKGVUzihlpNDpjN9ApBfyBnt2GMsrj073dETJpWqgrOkUijBxATJVGIuY6I5App4UCoUi 7KiRkUKhUITORGVNp1AoFIqIo5TR6U06KqSDQqGoAihlpFAoFIqIo5SRQqFQKCKOUkYVQ1lC OziFjShNSAeFQqGoVChlFH68wHfAFsTBYV1Kej64CPH03AoJvmf08H0V4j4oGL8iZsRJyA7w L/C721coFArFGYiVaXdZQzuEipuQDgqFQlGZUKbdFUBpQjuE4nZkJBIUbA+icBpTtpAOCoVC UeEoDwzhp6yhHewIh7t9hUKhqHDUyCj8lDW0g50BQzjc7SsUCkWFo5RR+ClGDBDaIJE9DyJT a26xM2BYgoQTWIe42+9HYKRKhUKhUJyBKN90CoVCETrKgEGhUCgUkUcpI4VCoVBEHKWMFAqF QhFxlDJSKBQKRcRRyijyOIVFTicynhMiVe7pRGNgAVCAGLcMimx1FIrKi1JGlZ8ngJ1lzGMP 1oplILAYyANygf8BPcpY1pnCtcB84Biy12s1MJrADcd/R1w9LQIewu8pw0eg/8H3tHOfGM7p 6XzI9oAjwGSgkUUaY14KRZVEeWCo/HwcpnzvAv4PGAXMQDq1K4EbgXlhKjNcxCCjj4rifvz+ A1ciHtO7AK8jTm/v0K410/5O0D6lYRVwGLgUGADEIvvJFAqFIijB9hmdj0zX5CLTX7cZrmUA DwCbEB91HyOeGnTS8Y9qGiGhKLK17/3dkC5YmIq3EL94+7S8hgMJWpphFnXV3+yN5dqFqXgB 2cybhYTA6ORw3ikkRjetjBPIht63Ebm+YUhTqJ0bpdVzh3a+JTAFkc9JZNSn1zUV/0gjUTv3 qnY8xiLvR7W8TwCf4veEXkOTgw940vC9fob8OyLP22f6nEPoIyM93SPa8TabNEY8wEvAfu2e jiIjuTSLtApFpJkY6Qqcblgpoxiks/w70kF0QBSG7qk7AxmJpGrfnY90/jrpiFLwIG/JY5C3 4waIP7pBiN+79cAriKIxuxwyT9NdinRQRqVnRi8XRIHURBTVcETBVNPKSAfqaOkaAQ1tzoMo F2OnayQFGQX4EJl8ifjzC6aMjiPxn/6LuEbSO+c5iAIpRkZMHQhURrpisVNG64G/aH99yKgH ZHpOnzozP+vN2rV/IqOnXdrxj1pZdSmdMooDxmvHk4OkMdNHu7YGeBwZBS8FWlikVSgijVJG 5YyVMuqOjBCM63Pj8HeuGQS6++lD4NtvOqIUOiFv/F7DtdFIZ+wUpsKsjK5FRkZ26OVaoYep uBBxb9SLwICAwc47cSMiwz347/N7giujEYZzN2nn0vHLeqJ2bjyBykhXwnbKqKd23Es7Pqod 36EdH7Oo/zwCFdcs7fhWQ5rSrBnpnzmIQrPLS2eAdm0B8sJyHsqBrqLyojwwVABpSKdRbDi3 k8Dpkj2m/62mUhohb8jrkRHRRmRRPA53YSqMHEFGEnYjIyPBwlSsBv4BvKjl+QXSWQY770Q9 7e9m/B7ON9ikn2v4Xx95bcYv699M18x4g5wHv9GI/rcGIuvD2nEiUN30nfra38MER39GxrL1 lwirda/5iBICGeE1tsnbyExgOvKi8iXSbrYhU4UKRaVDKaPwcwBRJEZZN9bO6xg7y0amazoZ SCd3LtKhnAM0B/oTGKbCCp/p+FfkzX6ARVrz27MepuJGrW5NEYWkp3sXaIcs1ifgX8cKdt6O fdrflvjvpY1N+pOG//cavqvL+lzDtXxDWn30amdS39aUJhM4hSiHE8j9P2BI3xeJ1Avwg02+ unLrqP2NRuRkvGbkXeAKZNoxCVkDdMNJZB2rNjI6n4I8i1tdfl+hUFRhgq0Z7QQeQzrJdsh0 26Xa9QzkzTcFedP+Cen8ddLxrxmtAf6NdO4gnZ9+bT2yLmAVpmI1cL2pXiORDnYoMoWViqwN jTOV2xnpzPVR1FX4Le/OQ97WPcg61mfAWJvzYG/AUB3/mtFiYCr+aTOraTqjmXMyosx8wM/I aKxYS6t3/Fu061OBD/BPf1lN0+1Dps8OWJT/kOG7v2rl6d/70JDOapruVsN3lyJTnj5EwRnD f5in4FoYyuhtSrMVkZf+uQy4Gpk2fBZpe6vwG2YoFJUNtWZUzgSzprsAWIhY0+0C7jRc063p NiKGDZ/gVzYQuHbTEFnAztLSLkfWmEBGLDOQEU8mgZ3iUK2cLALXWQYhYSis9hnp5UYhHfFW RGm+joSsuBJZN1qj1SULefuuY3Me7A0YQAw7NiBv9t8gIwMfsr6jY6WMAFrjtyg8hXT2fQ3X eyHGJCcRhfQpwZXRndo9n0DW5RIJZCB+C8mT2v0+SOAI2EoZAdyLvDzkI0YYP1Nyf5fVepC+ BvazKY35cx0yoluIyL8IWbccj994Q6GoTChlVM6EI4TETuDics6zMpNsOp6NyPXhCio/mKJT KBThY6La9Fq5qY2MKPY4JTyNeBNZR1mDTPX1QkZ6n0ayUgqFQlGVKM+RUQdkCmiMU8LTjEcQ 5VuIKKFp+I0JKgI1MlIoKh41TVfOqEivCoVCETpqn5FCoVAoIo9SRgqFQqGIOEoZhZ/ayPTd xnJOW57fBVkryTUd+7R8Ac7Wjg9bpPEh3gM2EGiKbM7DDjf1N9exvBmE7EVyexxujPItQszt K2KfUFnbkplwP7fKhJKdbLHQt4wcR7yB1Lc5DyhlpCgf/oVsED0H2d9UzzZ15aU/8G0IxxXF v5DNq6mIN3Q7r+cKRaSph/imfATZu9gH8cAS7LwiDFgZMFi9Ka1AvDAUIZtRX0Hc3+hptyCb S48hm2T/ZPhuX2Sz6ynE79t7yN4cq3KCpQW4G2kYRxGvzmUZGelpdC/V7YNc18MqWLnhsaq/ Ux2d5JiOKMfjlJSjuS4xiPVeV5fH/bTy87X6/RfxbA5+WS3TjqO14wxD+V7tvNVHxyw/3bHr m9qx3fO1q5+TfEJtS2acnttVSMDBE1rZH4Qol2B1GarV+3Mt3Wva8SPacbD2Ug//7+5d5M19 OeLFZK5WzlzEP2FVl53d9+3aTCgyMroUG6F9722b86Cs6codt8ror4hLlyuAr7XrNxvS+hC3 PI8hD/k44mj0fGQ6bIn2/b/id0FjLscu7UWIq5wsxPuDXofSKqPzEM8JJ5EfUmKQPEJRRm7q 6EaOjyLTa8fwy9GqLlcjHZTHxfEF2r0dRtwq6a6FvjPJaol2bKWM1hnqaP4kaWl0+V2slblS O34c++frVD8n+YTSlsw4Pbc2SGeXB/wNCUlifDt2kotTXSbgV9jFiFcSvRMM1l7qGcr4APgK /9ToS0gnq8uqKsvO7vtObSYUGen00up+CPlN2J1XyqiccaOMEpE3i52I25qT2vWXDGkP4P8B 6Q1yINKA9AZQiL+z2mtRjl1aPVCbHq20BiU7+gKsldEhQxrjmoYP+UF2tbiu56G/uVlhrr9T Hd3IUXe8CjAJvxyt6vIW8I7LY122/6cdxyAvDUWIDz9dVou161bK6GLEP6HVR1eAZvnqeaZg /3yd6uckn1Dakhmn5/Y303UzTnJxqkuiVm/j70I/H6y96B3tIeR31107Xql9d4h2/Banh+ys vu/UZkKREYjbqWyt7rrDYrvzygNDBBihfSYjQdiuB54ieCdtFYNmAoG+2oot0til1f216V6v T1l87yjyplcPeVvS14GswiMMQUZGo5A30o5Yh0PwIj8KPWCeG4LV0Y0cYxD5+ZDwD8HqAhLj SfcZGOVw7IT+PHTP47Us0vyX4B7Jkwl8MdADGu7B7/BUx+r5XueynnbysSKUdmfXtiB4bCUn uTjVpZohXRJ+57tu2ssRRBZ629W95+vyNq6xV2XZlSWulVsZRQH3If2IMQxMsPNBO8BIcTbi HLMxMnx8wz55lSRW+5uDPMB+FmnqIm8Y6YjiyEOcY25GfkD9kWmmg8gbSpJ23sg0m7R6MLeh iPPT3pRkCvLj/QQZqvfXzlst4M9C5ukvQUZG9+APMGdkDqK02iJTCnb8z6GObuRYG5mT3oEs lupyNNclEZHLbO1aR4fj6Yj39NuRZ9RRq893SEeSgXQkbYDBWCuHwQQ6xDWSZzqeScmXALvn O96hfvo0oJ183JY1GnmrronEsHJ6blO1vEZo97Qb8XbxtHbdSS52dbkf+Bix0Por8Azivb0r 7tpLKFRF2dl936lNh0oq8CQSU+w7F+cB/zxjMTJ8Wow8VK8pTQ6Bb3g3IgtY5clY4OVyzrMi cTNNVwPpvPMR5fKxdv1VQ9otiCLORRqM2YBhKdLZnUDCQ9xmUY5dWpCF0kPIM3+VkgulSci6 VYZ2bS/ybIxvgeZpuK74h/LVLa6XxoAhWB3LKkdjXcbgX/TGxTFIZ7ZSKz8TUdrG38e92vmj iAWceZrODU6m8XbP165+TvIJtS2la+lTtWOnttUbWUM5iUztvm8rBff3/RetHq9o6fT1mZex by/6FJR+v5214++1Yz0C8dtUfdnZfd+uzYQiI5AoAj5kJG8k2PmJIIpmODJKqqlVaAsyD6qz Dhme/Z/hXDiU0de4nwqJJDWRuETdTOetlJGi4gl1r8dGpD27Pa7qlOdemASkg53LmRHWXMku PPyujG4yXWiNzKV30I7XIcPIHPxrB2Zl9AKi0bOQ8MadghR6Pv44MOn43xA+QoaSh7XzrSy+ W5E0Q95o7kUWOScjZo9ZyFvDCkqO4pQyqhyU98bD043ylE8fpF9oWg55VQWU7MJDUAOGTYgC 6o5/r8RGZD3nb8g0npEuyHzleYhCaoT1AnUMMof6HhKNsh0yD78ZuAXpyKdr1yuKGKTeF5k+ Oci85g7tswhRktsRZaSovBxGvWnaUZ7y+R6Zkj1TULILE3YGDIeQeVYjTyHznS+azuchVixt gfkEj7/TGVmLeB5Zo1qGDM+GAL+EUvEykARcjti6X46YF25H5jBXIcpwJTLXr1AoFIoKwE4Z 1aFkh7wdCXL2BH7LIhAF9Q9ESbVErH9GI5YjRtIQRWU0a9yJjJDCRQyytnMF0BNRmEuQ+t+n 1b001iIKhUKhKCeCKaOWyNrOfItrzyD24emm8+9qn1qITf3fkV3ERg4gU3ge/AqpMX5b9fKk CzAMuAExyJiFKMxFBLffVygUCkUE8Bj+RiPTctcgU1WTsbaW2424g3jYcO48xNjBg981hpUT 1sXIlN6j2vV2iMIwm82WluaIDftWZLf8LmTvSzfE2eQ8lCICGaH+gMhpL+L+w8iPiNNTJ+w2 rp5Edm6Xlicoucnw38j64lbkBeM/2vnyKK8slEfZ5vuNQwxntiH3uwpxPVMWDiO/ie1avreW Mb/ywouYPteJdEUUkcXozygHaRQPEDhqWkfgD6EeonB0ZdUJWKN9PwvZMBmsYV0ALESs6XYR aMr9LaUz7W4PfImMsF7UyogEVcWargFwofb/hci+Ar0zvQrxO+UGO2XUkbIt9BYS2AY/QV6Q 9HXMeMSQRt+fEUllVNZ7hZL3+wXSpvUNqm2QF8EBQb7vDXLeyGH8e7y6IM+9fvDkpS6nNNxJ 1d5jqCgbVd43XTNkDSsdWaNKtE0dfsKljAYgLwRrEUMP46jFh4z6vkTWvwYbrvVE1sfWIG/W fSzy7oW8FOhv5V8Q+OLhVPZTyIh3i6lso3Kwq8dVwK/atTVa2ue1vH9CRrMXICNqO9kay/sM MY7ZgOzyNvon+xpYr5U51eG8W4xll+Z5BLvfVAK5Bb8vML2sZ7X63qOduxl5FgsRy9dCQ3qj MgJZE9Z9Cdo9I3M5dvIqbVtNQdaYw6XsFJWbKquMopAfxUFkbSqYC4yKJhzKqBEy2myhHd+B /JCNZeq7v5vhd+BYBzHH1/eFnYVMyRkVdjvEbN1oQHJAS+u27NHa/02QjdH6m7beQdvVo572 nYu1ax788jOOFG5AOj07jArBaAX6ODLdBSXjESU7nAeZzkwP8qlmUXZpn4eb+22JrLXqHbaP wA79LEThNNCO7ye4MuqDTFnXcVE3cznB5FXatqqzlvAaMykqL1VSGcUjb76LkR9nZSIcymgI fpcbIB3RKfxv+z78frdA3qhjkQ7tIPKmrX82IxuadRYha4Q6MVp++jqMm7KN9zsd/6hK76Dt 6nEj4uLfirIoo4eQkcHPyFu+fg9NkFHgG0jnmuxw3i1mZVSa51FaZVTNcH0IshdQJ4WSymgv cq+r8Hswd6qbuZxg8iptW9X5EfdOXhWnF1XOa7cXmUbKQfYIKWMEId/wfzEywvAgb5pX2HzP i2xw1tFd3Mdj7XW7NNjV4yLcrbWsRPaDpSA+u+zohvj36qil/QPwZ+3aTmTtpZdWn+eRkUKw 83mIFWYwY45WlHRqCqV/HjqrEKMg8/12RabRigznrMq3ozclndS6qZuxnGDycoOVbHTiEfc4 CkWl5zlkIbuy7q4P5zSdHoTKaurDSC7yo07TvtfDcK29Ke0fKVnf1YgFotuy9Wm6plhP09nV Iw15W9en6bz410myCZxu+wwxYNAjT8YDD1LSgKEv8mav8yGiUECmr/Qp3ThgP2KBGey8W8wj IyNun4f5fr9E/EPqBgznIQYMxvU8c1mNcT9NZ8SpbuZygsmrtG1V54Ch7oozi0oxTZeBu7eq 1oh7nkhZTLkhXAYMA5F7/w2ZfjIGpbL7gffAv5C/EenMjWQgoxMjTyHejt2W/S+tjG0EOhM9 id/Dt109rkRGAr8hb+c9tPPP4DdpTkCmc57VyklHFulfoqRpdwxiDfg/ZBT9Fn5l1BsZWazW 6vG0w3m3uFFGYC8H8/0mIKbruhm2ecHfqiwQc+3tiFXs08hWC51gysipbuZy7ORV2rZ6If7I uIozjyqljF7H/xZeWakqpt121EOmxcpi1ZSMTOtU1hHs6YxxbWc4fkVc2XkTCXinODMJuzJy syblVhktp/Jb2pwOygikUzjbMZU1bZA1BXOwP0XF8CzyW1mPeMePtPd7N3iRjfCKM5eJEDz0 QyPEw3Y2ojD+bvjic4iPuePIcNwYkTADMaddhvwgQKxvpiGGB5lIuAhj+ru0fPIQbwwxlGQd wUPqVhZOF2WkUCgUFclEkPl33VtCI6AhYuGyColwGYssKm7Ev3g6EFlIjkKmArLwTw9kIBvi 9BjxXkQpvYLMg8cgu78xpP8B8WlXVyvnNkryGZU/wJlSRgqFQhE6E6OQ/QU3Ik5RdXPeTojN f038ZqSjEbNZK4WwFfExtwRRLkOQ6IUg5qjTEIudQovvmtM/jyg2s5PV3oiJ7tVu7y4C+IDU Sa9MyvckxLnx7aZQKBRnJPkez+6hI/sd1g4nRmMd+qERYgm13vDdWPxmmiMRDwi1EQXTAL8J Ksi0n059ZIOclSKySn+cknGUQEZPoxGXKB9ZXK80xKXERZ8s8IXq8yvsjHnj6WmAZ9A1g285 u1mrw45fqEBefnvMhG4duj/XuV23LeZrE74Yf0dUVFTxrTfcOaG88jTy4rjnJl5x6dV/u6Rt +52h1vtMw61MnSjtM63qKPn5iZatIMZjy9APkxAz0HMpaY7ZBhm9dMUfenczwS2n9iHuRbwE btYrDXcj/rsOIT7HFKcJLZqe/UnD+meZ419VujwVCkV48GAd+mER4kTxKfyb21ohG+GSkV3S 6dr5q7B3y7ME2cz2PP59IF1s0tuxB7H0egfZUKeIMCdOnigXLx7X9Rk0+6wGjZ28K0Q8T4VC ER6igfeR3fPFyKjj39r/f0D29uxHFNRmZErvB8T/1Tpk+m0dgdN5ZooR/2dvIiOaQiTExKJS 1nkF4mH4G8Ql0GicXcRElDFvPD0DoEXTlm/u3JN+Q3FxcULjho0/q1+3wdZf1yy7v6CwoE5q So35t99416sx0THFABs2r683d9HsO3OPH7vA5/PFVEtI3NCtQ/d39Kmk0uSps2bDqkum/PjN DYWFBbVSklMXDel/82spySmnXJY7DfA0b9zi7d37dg0AfH+++7HbZ8ya2q2ouCj6T1f3/ymI DKbdeO1Nw5ue1SwT4IPP373L6/WevOX6Oz6GwOmLpSsXtfhl2fyHCwoL6iRWS/wtNiY2MyYm NidUuRvzXLF2eZMFS38adfLkyeZerzenWeMWnw7oe/3/9LQ7dm07d96iOY8XFOSnpSSnLL7l hjtfTohPKASZxmtYr9E3h44c6lxYVFAjMSFxs/G6GbuynOTglhfHPTexft0G049mHbm4sLAw JbFa0uah/YePTU5KzgfYumNz7R9+mnnf8bzc86OiovIbpDWcOmzALV841c8pXyN2ZZhxeqab tm2oO2v+j/ccz8ttCxSnVE9dPPKm+14JRSbB6rN+09r6M2ZPe7VHl55/63hxl207dm2r+dWM L97scGGn53p0vWLtR5Pev+XQ0YNXFBUVJcXExB684JwL373yst4rdHk0bdTs0937dl1bWFhY q06tujMv7XjZlJlzZzxy4mReq2oJib8N6z/8mZo1ap2o6vKzy8OpzYQio2B4EHf11RG3Ktfi X7/Zi1jNpWrX2yNOEH3AKGQfSi/E5cj5+DfX1aOk76t0RCElI+tBtxqumdM/g0zH2bEVMbI4 hijCYVSBDZbpu7cPS4iPTy8uLkpK373jzqUrF/8jLi5+D0Bm1tErZs6Z3h3gaOaRhBlzpr6Q cyy7S/Wk6r/WqVV35vG83LazF/z43P4De5NLk6eR7Tu33Vw9KXmtx+Nm7zjrAAAORUlEQVTJ y8rJvPyr6Z/fFmq5O3Zvvy2xWuLGpMSk3wD2H9x78f4DezuUVUYnTp6I/nnJT/+sn9bgf4/c /djgNq3aTj6adbRHWfOc+8usf9WqUXv5I/c8Nqhr+0uf35q+eeT8JfPO09PsP7iv25Brh/1l yHU335Z3Iq/5zDnTexrzyDmW3eLeW+9/9P47/jziVP6peubroZRVXuTk5rS455b7H3twxCN3 FxUXJXz93aQhAMXFRVHTZk15MrFa4q7Rtz88ZNA1g0cfOJTRa/qsKZe6qV+wfI3YlWElE7tn WlBY4Plu9rSnEuIT9t0z/P6ho29/eOj5rdqGNA1vV582rdvub9GkxYQFy+b/JftYdtyM2VMf ql2zzqweXa9YC1C7Zp2tw/oPv+8v9zw+sHnj5l+uWLf8sexj2br3EA4czuh808BbH+p31XX3 HT566Mrv5kx7rEeXXmNHDL1nqM9XHPP9vBlGZ8NVUn52ebhpM6HKyIqq5ijVSB5wH/AxMup6 EPgngV6DKxVtWrd9o2+vfoteeeeFd/IL8hvVrlXnf7cNHvH++IlvPXAk88jVR7OONAd+mr/0 p86FhYW142Ljdva7uv84gG9nftXw2PFj7Rcs/fmy6/sNmRFqnsZ6tD33wrG9e/Rd+sO87zqu XPfrv45kHukJvB1KuWc3bfnuwGsG/y7rO4fe80Z5yGjZqsWtfb7imBv6DZni8Xh9Pbpesfa3 zetWGNOM+3js47nHj1lulK6WUG3Lfbc++KQ5z2JfccKQ626a5PF4fV3aX7p5/eZ1czdv33R5 9049fgNo07rtl/XTGh4DqFWj9qKs7KMBvunatG47TR9hpqbUWGm+HkpZdoRyb62bnzNDr9M5 Z587beW6X+8HPlr868JWBQX5acMG3PJRTHRMcbPGLY42qn/W9D37dnVbtmpxplP9guVrrItd Gchm2wCZ2D3TJSsWti4sLKwxbMAtH8TFxhUBdOt4mb4e7UomTvUZeM3g79/88LWOH3z2zn8A 3w39hv5bz+OaK//0i/7/dX0GzX75nReGrN+4pmnXDt03AZzb8vzJdWunHa9bO+343IWz1icm Ju284LyL9gCk1a73S2ZOZsDG4qooP7s83LTpUGVkRVVWRjpLkHWvgYhV4PPAOCToXm4E61WC 5o1bbAfwer3HKYBaNWpvBYiOjskFKC4ujgE4npdbC+BU/qkm//1qwmfGPHLzcuuVJk8jjRs0 2QXQqP5Zu1eu+5Xi4qKk43nHY0Ipt3WLc9eUVg525OTm1IiNiT3o8Xh/N5yJj084YEzTv8+g sSdPnbTaGE1cbGyJqbOc3JwaMdExh415VkuodjD7WPbvXiZSklN/n+r1er0nCwrzjdahJFZL Ov77dY83v8CXXz1Y/Z3KsiOUe0upnpql/59avUZWUWFRKkBmdmZtn88XM/b9V8bp130+X0xC QrXtrmQRJF8jdmWY0zo90+yc7JoxMTGH9E6wNDJxU58WTc7+YdX6FU+0bNZqbGK1xN+90n81 /fM/7N6/+5qiosLqUUQVFRYV1jxx6uTvMdJqpNTI1P/3eDz5CXEJ/mOvt8Bn+o1VRfnZ5eGm zYQqIytOB2UEMnX4FeLcsSdwL+IW5XNEMTm+kZqIR5xflivR3uiAB+3xeCwbT2K1pCMAsbFx uy887+K3jdeMDz2UPI3s2rfzrHNbtcnYs393I/mONzexWmJBKOXGx8WXmAO3IyoqqvBUvv8H UVhYmOj1ekvIuHpS9czCwsKAH29+QX5KfFz876boX8/88oHjx3PbWpWTkJCwZdRtD/3TnGdB YUHt4uKiKP0HlXcir05sTGyWVR5lwaksJzmEcm+Hjx6qiwRH5NCRg3W90d4sgOrJ1TO9Xm/O gyMeudvYgQD8vHhuGydZBMs34D5tyrCSid0zTa2eeqSgoKBOQWGBx7y+6VYmTvU5mnkkYf3m tXfVqlHrxx27tg/bf2DvL/XTGh5bsXZ5k+27tt/ap0ffP+tv8q+888J4u/txoirKzy6Pivr9 nC7KSMcHzNE+DYARyObdfYjBw7eIV2InHkOmAccSgfgq3TtevnjL9k1H8/NPnbVl+8be1ZNT tp88eaJmVk7WJZe0bV/m6bC1G1Y/kL5nx4qcY9ntAWrVqDWvrOU6GTDEx8VvX79p7UWtW5z7 45btm+pk52R1qlsnrcS8doeLOm9aumpJ1A/zvuvQu0ffZRu3/paWcyy7Y3xc/O9pr+09YOyJ E3mx5u8CxMXFl4jDpOV56vMpEwfdeO2wr5atWtLiaNaRnp0v6fqk3T255b1Px40qKiqKH3nz qJecynKSQyj3tnn7xoGXtG2/DmDj1g2Da9eoMx+gW4fuG5avXnrsk68/Gta/z/WTkpOS89du WN3weF5uNTeyCJavEbsyOrfrtsVCJkGfaZf23TYtXbU4c+Lkj24deM3gT6Kjo4tXrFl2tj5N 5EYmTvWZ/N0Xd1VLSNwyYti9r42fOG70tz98Peqe4aOfP3EiL8ETFZXfrHGLgwCz5/94cX5B fpnCWFRF+dnlEe7fj05FKqN0xJ3Q8goqbx9imv4M4jniOiSqaD6ilL5F3OyXeJNAIoTORtak HkNGWLZvL+VJzRq1TvTpec1ff14y7/ac3Jx2WTlZl0ZHR2cmVUta36j+WfvLmn+zxi3+m75n x/XFxcUJqdVTfx7Q94YJZS13/8G9FxcVFcVjWp/S6XBhp3cXr1j48KvjX7wmNjbuUHJydcvI rQnxCYWXduj+7OIVC+/fuHXD4Ojo6GPVk1KWGdM0rNcoJMu6hPiEwh5dej31y7KfR700bsyN Hq/3WIsmLd+7rHNPOytQ15zKP1W7bq20ZW7KcpJDKPeWVrveL59M/vA/hUWFNVOSUxYP6HvD pwAej9f3p94Dnvhh3nd3j/v49U8AT2xM7N42rdt+7EYWwfI1YleGlUzsnqnH4/X9odcfn5y9 4Md7xn38+qdollx6Z+pGJnb1mTlneufsnOz2wwYMvxdgYN8b3psw6b2xU374ume/q66dt3Hb hoXvTnzrrdiYmEPVEhJ3xsXGlWnzc1WVX7A8wv370alIC7R0/MpoD6IcKkoxGblIK/taxNPE AkT5LEBCJxQiFn7GzncpEuNnnkPePiB1yvtTik8W+EpYsSkqlpfeHvPhZZ0uf7rjxV22hauM gsICz9j3Xxk38uZRo4zrEOEmXF4jyiPfSMmkMqDk556oKO+6G0b226Udlgg7Ho29257TgVXa 50nEVVF34FLE3LwJYhBhfmvviPjO+wZxdb+1YqqqKC17M/ZULyoqTKmf1jCsbo9iomOKHx75 15HhLKOqoWRSNs5U+XkIDPmg+56zCx8RLOSEPqLQeRWZIjPzlpZuKjJaGu6QbzjZj7g+uh+J NNkU2eibFiR9f8QY4i3EL5+iErJo+YJWEyd/NCGtTr2pygODQlE1iEKUzUIkpHGhdm4Fsl/n CaTTnYN4X9iLhHLogCiORsjU1F7tu420/ECUUa72PbCfputik28kuBfZu2RHEaKkX8Nveaem 6RQKhcIFwabpxuIPH9ERaIZ0tEWIIcCbiCLRwzu0RUJO7CmneuWFKd/SEIVY4VmRh0zxrUVC b8zALzeFQqFQlBKP9tcYwsEYPmKj9nlIO7caf8iJI8AXSEC8shKufEvDXYiRQx4yYhyLrCe1 RdwidUPcFT2BuDEqqyfyCmPMG09PG/PG0zO27thc6aYYX357zITFv/5i6XB3whfj7/hw0ntW ARcVlQC7ZxcKZ+pzVvITPBbnMvCHjzhH+zRH1ktAwk20Q0ZPCfjXk/IRhaVjF/HUykw6WL4V SRwSGt2oeHRXHlVK8VQ1VLgHheLMxkoZ2YWPOA/rkBMgo5srtf8bA/1syj2KKB0du3wrklPI 2pVSPC6pzCEkwsWp/FPeSNdBoTjdsOpI7MJHZALjKRlyAsRR6YdIBNjdSKiJYLyATH+NB/4C rLHJt8qjQkhEJoREqK7tnUIJNEhrOOXQkUNdfb7iuHp16s/KzMk8595b7n9WL+/9z965Owp8 tw8Z+Y65LiqsRElUWInKL79whpXo0fXKocayPFiHfAgWPmIJwUNOLEGm9tojU3rD8FvSgSga 3XruU63cVEQJ2eV72qBCSDhT3iEkQnFt7xRKIPtYdquRN9/3yAN3/vnezu26zj2Wm9Pu4OED iSCjpaNZRy5r07rtbKt7UmElSspEhZWo3PILd1iJSVMn3mws73TzTVepUSEknCnvEBKhuLZ3 DiVw3lQ9oF6zxi2OJlZLXD9/ybzuA68Z/P28hbPbeb3ROZ0u6VpiQ7QKK6HCSlRF+YU7rMSu vTsDXsaUMqpAVAgJZ8o7hEQoru2dQgkYw0wANG7YdFb67h19ge937NrWM6122pxg96TCSgSi wkpUfvmFPayEzxfgvFUpowpEhZCITAgJN5QmlEDPrlcuGvfx6/etWLu8Sc6xnI5XXHr1B1bp VFgJa5mosBKBVDb5VXRYCaWMKiEqhET5hpBwQ2lCCSQnJefXSKnxy0+L5jyakJCwuWXz1r+v c6qwEpEPi6DCSlStsBJKGVVCVAiJ8g0h4YYu7bttKk0ogdYtzp21cPmCq5s0avaq8bwKK1E5 wiKosBJVJ6xERYaQOBNQvunOMLZs31Tn65lfvnvHkJHDateskwcqrIQVZ0pYBCuU/KxxCiGh UChCYMGyn/+UmlJjvq6I4MwNAWCHkknZOBPkp5SRQlEKMrMz48dPfOuTmOiYQ3/o9ccnI10f haKqo6bpyhcfkDp37tzjezYfrRPpyigUCkVlJZXY7H4j++kzChMjWpnTEB/2DmIVCoVCURK1 ZhQGLkKCCioUCoXCHTXVNF35si3SFVAoFIqqyP8DrqC+qm2XwigAAAAASUVORK5CYII= --------------060504090007030105050009--

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 15 Nov '09

15 Nov '09

--vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * hyc(a)symas.com <hyc(a)symas.com> [2009-11-15 17:58:03 +0000]: > alexs(a)ulgsm.ru wrote: > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > >=20 > >=20 > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP= =3D"" > >=20 > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > >=20 > > Testing database consist of 1000 users accounts with minimum attributes= =2E=20 > >=20 > > On stress test load slapd Segmentation fault in 10-30 sec. >=20 > Looks like you've had a stack overrun.=20 Is it OS issue? >The "be" parameter should be the same in your frame 0 and frame 1. I don't understand. It's need to make them same? Or what i need to do? :) >=20 > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > >=20 > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory ad= dress > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=3D0x801a853d0, db=3D0x803519= 800, > > txn=3D0x80352b040, k=3D0x8069005 > > 70, ids=3D0x806a00000, saved_cursor=3D0x0, get_flag=3D0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=3D0x803521000, rtxn= =3D0x80352b040, > > ava=3D0x7ffffda7a4f0, > > ids=3D0x806c00000, tmp=3D0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a550, > > ids=3D0x806c00000, tmp=3D0x806a00000, stack=3D0x806d00000) at filterin= dex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=3D0x803521000, rtxn=3D0x8= 0352b040, > > flist=3D0x7ffffda7a5 f > > type=3D161, ids=3D0x806b00000, tmp=3D0x806a00000, save=3D0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a530, > > ids=3D0x806b00000, tmp=3D0x806a00000, stack=3D0x806c00000) at filterin= dex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=3D0x803521000, rtxn=3D0x8= 0352b040, > > flist=3D0x7ffffda7a5 f > > type=3D160, ids=3D0x7ffffdafa760, tmp=3D0x806a00000, save=3D0x806b00000= ) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=3D0x803521000, > > rtxn=3D0x80352b040, f=3D0x7ffffda7a570, > > ids=3D0x7ffffdafa760, tmp=3D0x806a00000, stack=3D0x806b00000) at filte= rindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=3D0x803521000, rs=3D0x7= ffffdbfab30, > > e=3D0x7ffffda7a71 tx > > n=3D0x80352b040, ids=3D0x7ffffdafa760, scopes=3D0x7ffffda7a760) at sear= ch.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=3D0x803521000, rs=3D0x7ffffdbf= ab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=3D0x803521000, rs=3D0x7ffffd= bfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=3D0x803521000, rs=3D0x7ffffdbfa= b30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=3D0x7ffffdbfac70, > > arg_v=3D0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=3D0x7ffffdbfac70,= argv=3D0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. >=20 >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ --=20 Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iQEcBAEBAgAGBQJLAP/dAAoJELAIdrQw5JcdEXgIAJ4KkW6gYy+Nm6XykkqGAyad HG/vIY1KeG9vJyPLzduonCaqhi32ZIuSl3qkGgywy4q/wJV0kW3rRZ2tzQLzMahr gKlVFJvyqtPhocKARppKWFSIXxJT64lvCqEabrfw2JLDhDNJGtIOcdn51TlKvfIy 4paEDvv5c+A3aDD7BFKK0QePq8E38v5evK1a8UG94rbGiKiCjtgYjJVfm03NUjmR FvyBwMV+CgcXGj4fQ+bnvfTTC8jb00oftw/7NS2orZi6EHcGaxvbeuPmrEVIRtL4 Fi82XlKfcEqFq/znja041mrkF7tnPLfysMzXEjqeOgrsedAIWS52M2LHGUYkY0k= =PI7h -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL--

1 0

ITS#6290 dynamic group documentation
by hyc＠symas.com 15 Nov '09

15 Nov '09

Yeah, the example should have used groupOfURLs instead of groupOfNames. Notice that "member" is not a valid attribute in the groupOfURLs class: it can not be used to store static members, only dynamic references. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 15 Nov '09

15 Nov '09

mike(a)flyn.org wrote: > Followup 4 states that slapd did not initially crash when using "threads > 1" and no indexes. In this case, slapd did eventually crash as before. I have removed the two asserts you previously reported; please try the current code in CVS HEAD. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 15 Nov '09

15 Nov '09

Followup 4 states that slapd did not initially crash when using "threads 1" and no indexes. In this case, slapd did eventually crash as before.

1 0

Re: (ITS#6304) Slapd freezes during SSL handshake when TLSVerifyClient=allow
by hyc＠symas.com 15 Nov '09

15 Nov '09

Jan Zelený wrote: > Dne čtvrtek 24 září 2009 22:19:40 Howard Chu napsal(a): >> jzeleny(a)redhat.com wrote: >>> Full_Name: Jan Zeleny >>> Version: 2.4.18 >>> OS: Fedora 11 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (62.40.79.66) >>> >> I'm unable to reproduce this using slapd on a debian x86-64 system, whether >> on the local LAN or from 13 hops away. I've also used the tcp-buffer >> option to set a minimum sized socket buffer and still could not duplicate >> the problem. You will need to provide more explicit information on how to >> reproduce this issue. Perhaps providing a set of CA/server certs will also >> be necessary. > I'm not sure I have much more explicit information for you. I'm sending > certificate in attachment. It's a self signed testing certificate I generated on > my system. I'm also sending you slapd.conf with relevant information and CA > bundle file. If you need anything else, just let me know. > > Just for complete information: > I tried slapd on Fedora 12 and RHEL 5.3 (x86_64) and on Ubuntu 9.04 (i386). On > each system I used different self signed certificate. In both cases attached > slapd.conf file was used. To reproduce error, I just started the slapd service > (slapd -h 'ldaps:///' -u ldap) with given config file and connected to it. When > I tried to connect with openssl s_client -connect fedora12-64, I received this > output (and then freeze): > > CONNECTED(00000003) > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify error:num=18:self signed certificate > verify return:1 > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com > verify return:1 > > >> Please note that the bug report you reference (509230) gives inconsistent >> information; it says that no hang occurs with -d2, but that hangs occur >> with no diagnostics, even with -d -1. Obviously -d -1 includes -d 2, so: >> does it hang, or not, with -d -1? > > I believe what is stated there is that hangs don't occur with -d2, but they do > with -d1 (not -d -1). I can also confirm this behaviour, that with -d1 hangs > occur, but with -d2 they don't. (or at least I didn't encounter them during my > testing). > > Hopefully I provided some useful information. Thanks, that helped, a fix is now in CVS HEAD. I should point out that the configuration used to reproduce this problem is quite a poor one. As the OpenLDAP Admin Guide clearly states, your server should only be configured with the CA certs for which it will accept client certs. Your ca-bundle.crt file is 670KB and loaded with a lot of CAs that are irrelevant; it's when slapd sends the client its list of acceptable CAs that the connection was getting jammed. -- -- 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#6325) test054: test failed - producer and consumer databases differ
by michael＠stroeder.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Download testrun/ here: >>> >>> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz >> It's certainly a mystery. The *.flt shows that an entry is missing on the >> slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log >> shows that the consumer received the entry and ignored it. (See slapd.4.log >> line 3307-3313. Compare with the previously received entry, lines 3161-3169.) >> >> The most puzzling part is that every code path in the consumer that rejects an >> entry logs an error message, and there is no error message in the log file. >> Without any means to reproduce this there's not much we can do. Setting a >> higher debug level might be useful, but any error messages in this path should >> have shown up regardless. > > The same problem is in your ITS#6126 logs. The entry was received on the > consumer but skipped without any error message. > > I see now, the entry was skipped because its CSN was too old. (And that CSN > too old message is only logged with SYNC debug is enabled.) This should be > fixed by the patch for ITS#6346. > > It was also suggested that we should only reject mods if their CSN is actually > older than the target entry's CSN. That's still a possibility if the current > patch is insufficient. These ITS were filed based on failed test runs on my old Pentium III Mobile 1,8 GHz laptop (now broken). I always suspected that it might be something others won't see because their hardware is faster. Maybe it would be good to run the test suite on really slow systems from time to time. Ciao, Michael.

1 0

Re: (ITS#6325) test054: test failed - producer and consumer databases differ
by hyc＠symas.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Download testrun/ here: >> >> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz > > It's certainly a mystery. The *.flt shows that an entry is missing on the > slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log > shows that the consumer received the entry and ignored it. (See slapd.4.log > line 3307-3313. Compare with the previously received entry, lines 3161-3169.) > > The most puzzling part is that every code path in the consumer that rejects an > entry logs an error message, and there is no error message in the log file. > Without any means to reproduce this there's not much we can do. Setting a > higher debug level might be useful, but any error messages in this path should > have shown up regardless. The same problem is in your ITS#6126 logs. The entry was received on the consumer but skipped without any error message. I see now, the entry was skipped because its CSN was too old. (And that CSN too old message is only logged with SYNC debug is enabled.) This should be fixed by the patch for ITS#6346. It was also suggested that we should only reject mods if their CSN is actually older than the target entry's CSN. That's still a possibility if the current patch is insufficient. -- -- 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#6200) slapd crashes under load w/ syncrepl
by hyc＠symas.com 15 Nov '09

15 Nov '09

joacim.breiler(a)hgo.se wrote: > Thanks for your fast replies! The 'make install STRIP=""' did the trick. > > I ran the server for about a week with no segfaults, then I decided that > I couldn't wait for it any longer. So I connected to the server using an > LDAP browser, and then after about ten minutes it segfaulted. So to > reproduce I need one connection that is reading/updating/creating > entries. And one connection that does an occasional read, otherwise the > server will keep on running. > > The traceback from gdb gives: This trace looks like the problem fixed in ITS#6335. The fix is in CVS HEAD and RE24 (2.4.20 pre-release). > > 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0, rs=0x44688c80) > at syncprov.c:1970 > 1970 for ( m2 = mt->mt_mods; m2->mi_next != mi; > (gdb) where > #0 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0, > rs=0x44688c80) at syncprov.c:1970 > #1 0x00000000004c438a in overlay_op_walk (op=0x7f9688000ac0, > rs=0x44688c80, which=op_modify, oi=0x12293c0, on=0x12295a0) at > backover.c:659 > #2 0x00000000004c4667 in over_op_func (op=0x7f9688000ac0, > rs=0x44688c80, which=op_modify) at backover.c:721 > #3 0x00000000004c47ac in over_op_modify (op=0x7f9688000ac0, > rs=0x44688c80) at backover.c:760 > #4 0x000000000045bb21 in fe_op_modify (op=0x7f9688000ac0, > rs=0x44688c80) at modify.c:301 > #5 0x000000000045b430 in do_modify (op=0x7f9688000ac0, rs=0x44688c80) > at modify.c:175 > #6 0x000000000043c3ec in connection_operation (ctx=0x44688de0, > arg_v=0x7f9688000ac0) at connection.c:1123 > #7 0x000000000043c975 in connection_read_thread (ctx=0x44688de0, > argv=0x17) at connection.c:1259 > #8 0x0000000000525193 in ldap_int_thread_pool_wrapper (xpool=0x1190290) > at tpool.c:685 > #9 0x00007f96c49613ea in start_thread () from /lib/libpthread.so.0 > #10 0x00007f96c44b9cbd in clone () from /lib/libc.so.6 > #11 0x0000000000000000 in ?? () > > /J -- -- 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#6325) test054: test failed - producer and consumer databases differ
by hyc＠symas.com 15 Nov '09

15 Nov '09

michael(a)stroeder.com wrote: > Download testrun/ here: > > http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz It's certainly a mystery. The *.flt shows that an entry is missing on the slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log shows that the consumer received the entry and ignored it. (See slapd.4.log line 3307-3313. Compare with the previously received entry, lines 3161-3169.) The most puzzling part is that every code path in the consumer that rejects an entry logs an error message, and there is no error message in the log file. Without any means to reproduce this there's not much we can do. Setting a higher debug level might be useful, but any error messages in this path should have shown up regardless. -- -- 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: RE : (ITS#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com 15 Nov '09

15 Nov '09

CHIROSSEL Olivier wrote: > sorry for this > > the url is ok now Thanks. This is now fixed in HEAD. > > Cdt, > > Olivier > ________________________________________ > De : Howard Chu [hyc(a)symas.com] > Date d'envoi : vendredi 13 novembre 2009 23:33 > À : CHIROSSEL Olivier > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored > > olivier.chirossel(a)sfr.com wrote: >> Full_Name: olivier chirossel >> Version: 2.4.17 and 2.4.19 >> OS: linux >> URL: http://86.64.145.174:8080/ >> Submission from: (NULL) (62.39.9.251) >> >> >> in refreshend persist mode, the replication is incorrect for an entry which be >> delete/add after master restart and before the reconnection of the slave. > >> 2) master set up >> >> on /etc/openldap tar xvf slapd_master.tar (get on the url ) > > The URL you provided always times out for me, so I've been unable to set up > this test. > -- -- 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#6362) slapd 2.4.19 Segmentation fault under load
by hyc＠symas.com 15 Nov '09

15 Nov '09

alexs(a)ulgsm.ru wrote: > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. Looks like you've had a stack overrun. The "be" parameter should be the same in your frame 0 and frame 1. > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs