- openldap-bugs - openldap.org

(ITS#7011) signal 6 got in ldap_abandon
by ogermain＠tibco.com 03 Aug '11

03 Aug '11

Full_Name: Olivier GERMAIN Version: 2.4.24 OS: Solaris 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.157.248.2) Dear All, One of our customer got a signal 6 during the execution of the ldap_abandon. This signal occurred whereas some maintenance was doing on a firewall which is not located on the same network. It seems that the ldap_abandon thrown this assert because it was a situation like a can't happen. I don't have much information on the action performed on the firewall which led to this sigabort. Please find the logs I have : 2011-07-19 04:08:52.876909|ENG|FATAL|84|engine.cpp(109)| /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/distrib/kabira/lib/libsyssrv.so:sw_debugSignalHandler+0x18 2011-07-19 04:08:52.877541|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:<static-func>+0x5b0 2011-07-19 04:08:52.878082|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:<static-func>+0x628 2011-07-19 04:08:52.878658|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:_lwp_kill+0x8 [ Signal 6 (SIGABRT) ] 2011-07-19 04:08:52.879196|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:abort+0xd0 2011-07-19 04:08:52.879733|ENG|FATAL|84|engine.cpp(109)| /lib/sparcv9/libc.so.1:_assert+0x74 2011-07-19 04:08:52.880325|ENG|FATAL|84|engine.cpp(109)| /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:<static-func>+0x4ec 2011-07-19 04:08:52.880776|ENG|FATAL|84|engine.cpp(109)| /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:ldap_abandon+0xac I am in the process of a reproduction of this signal 6 but I would like to share the following idea. Do you think there is a possibility to enhance the openldap library to avoid this assert? Is it possible that instead of having an assert, we have a exception or a status code which tell us something went wrong of obviously that we can handle in our source code. My best regards Olivier GERMAIN TIBCO Support team

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by hyc＠symas.com 02 Aug '11

02 Aug '11

whm(a)stanford.edu wrote: > --On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount<quanah(a)zimbra.com> wrote: > >> --On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: >>>>> Your log shows that the subsequent search request initiates a new >>>>> Bind to the remote server, which implies that it's not re-using the >>>>> same connection as the first request. Since a paged results cookie >>>>> is only valid within the context of a single connection, you get >>>>> this error result. >>>> >>>> Not sure which log you are looking at. When I look at the log: >>>> >>>> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >>>> lts.log.gz >>>> >>>> The only connection I see in the log is conn=1000 and it ends with: >>>> >>>> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >>>> cookie is invalid ldap_read: want=8, got=7 >>>> 0000: 30 05 02 01 07 42 00 0....B. >>>> ldap_read: want=8, got=0 >>>> >>>> conn=1000 op=6 UNBIND >>>> conn=1000 fd=11 closed >>>> >>>> These tests where made with a single ldapsearch request. The ldapsearch >>>> tests fail when using the proxy and succeed when connecting directly to >>>> the LDAP server with the database on it. >>>> >>>> A side node: the test case I submitted used ldapsearch, but the >>>> problem was uncovered using a python application that is used for >>>> syncing Gmail account data. >>>> >>>> Bill >>> >>> I have copied the backend server configuration to >>> http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an >>> copy of cn=config and there is a files based version the in ldap >>> subdirectory as well. >> >> Where's the configuration for the slapd-ldap server? That's of the >> most importance... >> >> --Quanah > > Of course, sorry about that. I have copied the files to the web site. Sounds like this may be related to ITS#6817. Please try adding a dummy binddn to your idassert-bind directive and re-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

(ITS#7010) Deadlock in Producer/Consumer Nodes
by ghola＠rebelbase.com 02 Aug '11

02 Aug '11

Full_Name: Duncan Idaho Version: 2.4.25 OS: Centos 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.148.0.72) We are running a cluster of "synchronization hosts" that act as Producers for a large number of Consumers and additionally Consume from a single global read/write master. After several weeks of stable operation synchronization came to a halt on both nodes in the Producer/Consumer cluster simultaneously. Stack-trace: Thread 15 (Thread 10745): #0 0x000000322ea07b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041929d in slapd_daemon () at daemon.c:2922 #2 0x000000000040730e in main (argc=<value optimized out>, argv=0x7fffd2567cb8) at main.c:983 Thread 14 (Thread 8866): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 14876): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x471a9d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x471a9d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 12 (Thread 14875): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 11 (Thread 14874): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x461a7d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x461a7d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 10 (Thread 14873): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:217 ...back 1 page Thread 15 (Thread 10745): #0 0x000000322ea07b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041929d in slapd_daemon () at daemon.c:2922 #2 0x000000000040730e in main (argc=<value optimized out>, argv=0x7fffd2567cb8) at main.c:983 Thread 14 (Thread 8866): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 14876): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x471a9d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x471a9d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 12 (Thread 14875): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 11 (Thread 14874): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x461a7d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x461a7d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 10 (Thread 14873): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:217 [root@su1-admin-syncrepl01 ldap]# cat gdb.txt Thread 15 (Thread 10745): #0 0x000000322ea07b35 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041929d in slapd_daemon () at daemon.c:2922 #2 0x000000000040730e in main (argc=<value optimized out>, argv=0x7fffd2567cb8) at main.c:983 Thread 14 (Thread 8866): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 14876): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac06ab4a0, rs=0x471a9c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac06ab4a0, rs=0x471a9c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x471a9d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x471a9d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 12 (Thread 14875): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004ec695 in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:672 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Thread 11 (Thread 14874): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaac0897eb0, rs=0x461a7c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaac0897eb0, rs=0x461a7c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x461a7d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x461a7d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 10 (Thread 14873): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab82b63c0, rs=0x459a6c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab82b63c0, rs=0x459a6c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x459a6d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x459a6d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 9 (Thread 14872): #0 0x000000322ea0d4c4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x000000322ea08e1a in _L_lock_1034 () from /lib64/libpthread.so.0 #2 0x000000322ea08cdc in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d7e48 in syncprov_op_search (op=0x2aaab89e58c0, rs=0x451a5c10) at syncprov.c:2476 #4 0x000000000047e64a in overlay_op_walk (op=0x2aaab89e58c0, rs=0x451a5c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2aaab89e58c0, rs=0x451a5c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2aaab89e58c0, rs=0x451a5c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2aaab89e58c0, rs=0x451a5c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x451a5d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x451a5d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 8 (Thread 16034): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000042db1c in send_ldap_ber (op=<value optimized out>, ber=0x449a43f0) at result.c:372 #2 0x00000000004308d8 in slap_send_search_entry (op=0x449a45a0, rs=0x449a4af0) at result.c:1410 #3 0x00000000004da80d in syncprov_qplay (ctx=<value optimized out>, arg=<value optimized out>) at syncprov.c:884 #4 syncprov_qtask (ctx=<value optimized out>, arg=<value optimized out>) at syncprov.c:1006 #5 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #6 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #7 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () Thread 7 (Thread 16033): #0 0x000000322ea0d605 in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000322ea0a0e7 in _L_unlock_766 () from /lib64/libpthread.so.0 #2 0x000000322ea0a04e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x00000000004d7e5e in syncprov_op_search (op=0x2d554b70, rs=0x441a3c10) at syncprov.c:2471 #4 0x000000000047e64a in overlay_op_walk (op=0x2d554b70, rs=0x441a3c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #5 0x000000000047ec27 in over_op_func (op=0x2d554b70, rs=0x441a3c10, which=op_search) at backover.c:721 #6 0x0000000000420a79 in fe_op_search (op=0x2d554b70, rs=0x441a3c10) at search.c:372 #7 0x0000000000421217 in do_search (op=0x2d554b70, rs=0x441a3c10) at search.c:217 #8 0x000000000041e965 in connection_operation (ctx=0x441a3d60, arg_v=<value optimized out>) at connection.c:1113 #9 0x000000000041f23c in connection_read_thread (ctx=0x441a3d60, argv=<value optimized out>) at connection.c:1249 #10 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #11 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #12 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () Thread 6 (Thread 11937): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0x2aaab802af20, rs=0x418f7c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0x2aaab802af20, rs=0x418f7c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0x2aaab802af20, rs=0x418f7c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0x2aaab802af20, rs=0x418f7c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0x2aaab802af20, rs=0x418f7c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x418f7d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x418f7d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 5 (Thread 10755): #0 0x000000322ea0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002b1d8ae85bd1 in __db_pthread_mutex_lock () from /usr/local/openldap/lib/libdb-5.1.so #2 0x00002b1d8ae8528a in __db_tas_mutex_lock () from /usr/local/openldap/lib/libdb-5.1.so #3 0x00002b1d8af1804c in __lock_get_internal () from /usr/local/openldap/lib/libdb-5.1.so #4 0x00002b1d8af189ea in __lock_vec () from /usr/local/openldap/lib/libdb-5.1.so #5 0x00002b1d8af1969b in __lock_vec_pp () from /usr/local/openldap/lib/libdb-5.1.so #6 0x00000000004bc6c1 in hdb_cache_entry_db_relock (bdb=0xe2bc780, txn=<value optimized out>, ei=0x2aaadaefc6a0, rw=1, tryOnly=<value optimized out>, lock=0x439a1640) at cache.c:198 #7 0x00000000004bcb70 in hdb_cache_modify (bdb=0x2b1d8f0fa00c, e=0x2b1df490e138, newAttrs=0x2b1e071d6918, txn=0x0, lock=0x0) at cache.c:1231 #8 0x0000000000495d13 in hdb_modify (op=0x439a2120, rs=0x439a1cb0) at modify.c:662 #9 0x000000000047e6c2 in overlay_op_walk (op=0x439a2120, rs=0x439a1cb0, which=op_modify, oi=0xe2be010, on=0x0) at backover.c:669 #10 0x000000000047ec27 in over_op_func (op=0x439a2120, rs=0x439a1cb0, which=op_modify) at backover.c:721 #11 0x000000000047240f in syncrepl_entry (si=0xe2c2800, op=0x439a2120, entry=0x2b1df490e408, modlist=0x439a2c68, syncstate=2, syncUUID=<value optimized out>, syncCSN=0x2aaade6b6ab0) at syncrepl.c:2694 #12 0x0000000000479cf7 in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:955 #13 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1455 #14 0x000000000041f7ca in connection_read_thread (ctx=0x439a2d60, argv=<value optimized out>) at connection.c:1251 #15 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #16 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #17 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #18 0x0000000000000000 in ?? () Thread 4 (Thread 10752): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0xe6f0990, rs=0x410f6c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0xe6f0990, rs=0x410f6c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0xe6f0990, rs=0x410f6c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0xe6f0990, rs=0x410f6c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0xe6f0990, rs=0x410f6c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x410f6d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x410f6d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 3 (Thread 10749): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0xe5eefa0, rs=0x431a1c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0xe5eefa0, rs=0x431a1c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0xe5eefa0, rs=0x431a1c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0xe5eefa0, rs=0x431a1c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0xe5eefa0, rs=0x431a1c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x431a1d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x431a1d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (Thread 10748): #0 0x000000322e2baa27 in sched_yield () from /lib64/libc.so.6 #1 0x00000000004d7e7f in syncprov_op_search (op=0xe5ebbf0, rs=0x429a0c10) at syncprov.c:2475 #2 0x000000000047e64a in overlay_op_walk (op=0xe5ebbf0, rs=0x429a0c10, which=op_search, oi=0xe2be010, on=0xe2c30b0) at backover.c:659 #3 0x000000000047ec27 in over_op_func (op=0xe5ebbf0, rs=0x429a0c10, which=op_search) at backover.c:721 #4 0x0000000000420a79 in fe_op_search (op=0xe5ebbf0, rs=0x429a0c10) at search.c:372 #5 0x0000000000421217 in do_search (op=0xe5ebbf0, rs=0x429a0c10) at search.c:217 #6 0x000000000041e965 in connection_operation (ctx=0x429a0d60, arg_v=<value optimized out>) at connection.c:1113 #7 0x000000000041f23c in connection_read_thread (ctx=0x429a0d60, argv=<value optimized out>) at connection.c:1249 #8 0x00000000004ec63c in ldap_int_thread_pool_wrapper (xpool=0xe232120) at tpool.c:685 #9 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #10 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 1 (Thread 10747): #0 0x000000322e2d4108 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041bc8b in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2528 #2 0x000000322ea0673d in start_thread () from /lib64/libpthread.so.0 #3 0x000000322e2d3d1d in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () Logs at the time of the lock-up: Producer: Jul 28 22:27:08 admin02 slapd[5178]: conn=422733 op=92 MOD dn="thing=thing1,ou=things,dc=example,dc=net" Jul 28 22:27:08 admin02 slapd[5178]: conn=422733 op=92 MOD attr=stuff Jul 28 22:27:08 admin02 slapd[5178]: slap_queue_csn: queing 0x4b0883f0 20110728222708.058275Z#000000#000#000000 Jul 28 22:27:08 admin02 slapd[5178]: syncprov_sendresp: cookie=rid=001 ,csn=20110728222708.058275Z#000000#000#000000 Jul 28 22:27:08 admin02 slapd[5178]: syncprov_sendresp: cookie=rid=001 Producer later: Jul 29 07:04:55 admin02 slapd[5178]: Entry thing=thing1,ou=things,dc=example,dc=net CSN 20110728222708.058275Z#000000#000#000000 older or equal to ctx 20110728222708.058275Z#000000#000#000000 Producer/Consumer: Jul 28 22:27:08 su1-admin-syncrepl01 slapd[10745]: do_syncrep2: rid=001 cookie=rid=001,csn=20110728222708.058275Z#000000#000#000000 Jul 28 22:27:08 su1-admin-syncrepl01 slapd[10745]: slap_queue_csn: queing 0x2aaadecf4b00 20110728222708.058275Z#000000#000#000000 ^^ No more syncrepl logs after this Help!

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 02 Aug '11

02 Aug '11

--On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: > >> >> >> --On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister >> <whm(a)stanford.edu> wrote: >> >>> >>> >>> --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu >>> <hyc(a)symas.com> wrote: >>> >>>> whm(a)stanford.edu wrote: >>>>> Full_Name: Bill MacAllister >>>>> Version: 2.4.26 >>>>> OS: Debian 6 >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (171.64.19.165) >>>>> >>>>> >>>>> We typically setup local proxy servers to support applications that >>>>> cannot support a GSSAPI bind to the directory server. The proxy >>>>> server allows anonymous access to the directory for connections from >>>>> the localhost and connects to the master using GSSAPI. We are >>>>> experiencing a failures when we attempt to use the paged results >>>>> control on the proxy. For example: >>>>> >>>>> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h >>>>> localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou >>>>> telephonenumber title >>>>> >>>>> ends with the error: >>>>> >>>>> # search result >>>>> search: 5 >>>>> result: 0 Success >>>>> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >>>>> pagedresults: cookie=KIMAAAAAAAA= >>>>> # extended LDIF >>>>> # >>>>> # LDAPv3 >>>>> # base<cn=people,dc=stanford,dc=edu> with scope subtree >>>>> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >>>>> # requesting: ou telephonenumber title >>>>> # with pagedResults control: size=1000 >>>>> # >>>>> >>>>> # search result >>>>> search: 6 >>>>> result: 2 Protocol error >>>>> text: paged results cookie is invalid >>>>> >>>>> # numResponses: 4005 >>>>> # numEntries: 4000 >>>>> >>>>> This result is not consistent. We have seen examples where 2000 and >>>>> 3000 entries being returned and then the error. Another test that we >>>>> performed with a slightly more complex filter, i.e. >>>>> >>>>> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity= >>>>> world)))" >>>>> >>>>> returned usually returned 1000 entries before erroring. >>>>> >>>>> Issuing a similar search directly against the backend ldap server >>>>> completes without >>>>> error. >>>>> >>>>> We have seen the same behavior on OpenLDAP 2.4.23 as well. >>>>> >>>>> Logs generated running slapd standalone with '-d stats,packets' are >>>>> available at http://www.stanford.edu/~whm/files/ldap-debugging/. >>>> >>>> Your log shows that the subsequent search request initiates a new >>>> Bind to the remote server, which implies that it's not re-using the >>>> same connection as the first request. Since a paged results cookie >>>> is only valid within the context of a single connection, you get >>>> this error result. >>> >>> Not sure which log you are looking at. When I look at the log: >>> >>> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >>> lts.log.gz >>> >>> The only connection I see in the log is conn=1000 and it ends with: >>> >>> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >>> cookie is invalid ldap_read: want=8, got=7 >>> 0000: 30 05 02 01 07 42 00 0....B. >>> ldap_read: want=8, got=0 >>> >>> conn=1000 op=6 UNBIND >>> conn=1000 fd=11 closed >>> >>> These tests where made with a single ldapsearch request. The ldapsearch >>> tests fail when using the proxy and succeed when connecting directly to >>> the LDAP server with the database on it. >>> >>> A side node: the test case I submitted used ldapsearch, but the >>> problem was uncovered using a python application that is used for >>> syncing Gmail account data. >>> >>> Bill >> >> I have copied the backend server configuration to >> http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an >> copy of cn=config and there is a files based version the in ldap >> subdirectory as well. > > Where's the configuration for the slapd-ldap server? That's of the > most importance... > > --Quanah Of course, sorry about that. I have copied the files to the web site. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by quanah＠zimbra.com 02 Aug '11

02 Aug '11

--On Tuesday, August 02, 2011 5:54 PM +0000 whm(a)stanford.edu wrote: > > > --On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister > <whm(a)stanford.edu> wrote: > >> >> >> --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu >> <hyc(a)symas.com> wrote: >> >>> whm(a)stanford.edu wrote: >>>> Full_Name: Bill MacAllister >>>> Version: 2.4.26 >>>> OS: Debian 6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (171.64.19.165) >>>> >>>> >>>> We typically setup local proxy servers to support applications that >>>> cannot support a GSSAPI bind to the directory server. The proxy >>>> server allows anonymous access to the directory for connections from >>>> the localhost and connects to the master using GSSAPI. We are >>>> experiencing a failures when we attempt to use the paged results >>>> control on the proxy. For example: >>>> >>>> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h >>>> localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou >>>> telephonenumber title >>>> >>>> ends with the error: >>>> >>>> # search result >>>> search: 5 >>>> result: 0 Success >>>> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >>>> pagedresults: cookie=KIMAAAAAAAA= >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base<cn=people,dc=stanford,dc=edu> with scope subtree >>>> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >>>> # requesting: ou telephonenumber title >>>> # with pagedResults control: size=1000 >>>> # >>>> >>>> # search result >>>> search: 6 >>>> result: 2 Protocol error >>>> text: paged results cookie is invalid >>>> >>>> # numResponses: 4005 >>>> # numEntries: 4000 >>>> >>>> This result is not consistent. We have seen examples where 2000 and >>>> 3000 entries being returned and then the error. Another test that we >>>> performed with a slightly more complex filter, i.e. >>>> >>>> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity= >>>> world)))" >>>> >>>> returned usually returned 1000 entries before erroring. >>>> >>>> Issuing a similar search directly against the backend ldap server >>>> completes without >>>> error. >>>> >>>> We have seen the same behavior on OpenLDAP 2.4.23 as well. >>>> >>>> Logs generated running slapd standalone with '-d stats,packets' are >>>> available at http://www.stanford.edu/~whm/files/ldap-debugging/. >>> >>> Your log shows that the subsequent search request initiates a new >>> Bind to the remote server, which implies that it's not re-using the >>> same connection as the first request. Since a paged results cookie >>> is only valid within the context of a single connection, you get >>> this error result. >> >> Not sure which log you are looking at. When I look at the log: >> >> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >> lts.log.gz >> >> The only connection I see in the log is conn=1000 and it ends with: >> >> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >> cookie is invalid ldap_read: want=8, got=7 >> 0000: 30 05 02 01 07 42 00 0....B. >> ldap_read: want=8, got=0 >> >> conn=1000 op=6 UNBIND >> conn=1000 fd=11 closed >> >> These tests where made with a single ldapsearch request. The ldapsearch >> tests fail when using the proxy and succeed when connecting directly to >> the LDAP server with the database on it. >> >> A side node: the test case I submitted used ldapsearch, but the >> problem was uncovered using a python application that is used for >> syncing Gmail account data. >> >> Bill > > I have copied the backend server configuration to > http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an > copy of cn=config and there is a files based version the in ldap > subdirectory as well. Where's the configuration for the slapd-ldap server? That's of the most importance... --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#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 02 Aug '11

02 Aug '11

--On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister <whm(a)stanford.edu> wrote: > > > --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > >> whm(a)stanford.edu wrote: >>> Full_Name: Bill MacAllister >>> Version: 2.4.26 >>> OS: Debian 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (171.64.19.165) >>> >>> >>> We typically setup local proxy servers to support applications that cannot >>> support a GSSAPI bind to the directory server. The proxy server allows >>> anonymous access to the directory for connections from the localhost and >>> connects to the master using GSSAPI. We are experiencing a failures when >>> we attempt to use the paged results control on the proxy. For example: >>> >>> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost >>> "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title >>> >>> ends with the error: >>> >>> # search result >>> search: 5 >>> result: 0 Success >>> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >>> pagedresults: cookie=KIMAAAAAAAA= >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base<cn=people,dc=stanford,dc=edu> with scope subtree >>> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >>> # requesting: ou telephonenumber title >>> # with pagedResults control: size=1000 >>> # >>> >>> # search result >>> search: 6 >>> result: 2 Protocol error >>> text: paged results cookie is invalid >>> >>> # numResponses: 4005 >>> # numEntries: 4000 >>> >>> This result is not consistent. We have seen examples where 2000 and 3000 >>> entries being returned and then the error. Another test that we performed with >>> a slightly more complex filter, i.e. >>> >>> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" >>> >>> returned usually returned 1000 entries before erroring. >>> >>> Issuing a similar search directly against the backend ldap server completes >>> without >>> error. >>> >>> We have seen the same behavior on OpenLDAP 2.4.23 as well. >>> >>> Logs generated running slapd standalone with '-d stats,packets' are available at >>> http://www.stanford.edu/~whm/files/ldap-debugging/. >> >> Your log shows that the subsequent search request initiates a new >> Bind to the remote server, which implies that it's not re-using the >> same connection as the first request. Since a paged results cookie >> is only valid within the context of a single connection, you get >> this error result. > > Not sure which log you are looking at. When I look at the log: > > http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-results… > > The only connection I see in the log is conn=1000 and it ends with: > > conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results cookie is invalid > ldap_read: want=8, got=7 > 0000: 30 05 02 01 07 42 00 0....B. > ldap_read: want=8, got=0 > > conn=1000 op=6 UNBIND > conn=1000 fd=11 closed > > These tests where made with a single ldapsearch request. The ldapsearch > tests fail when using the proxy and succeed when connecting directly to > the LDAP server with the database on it. > > A side node: the test case I submitted used ldapsearch, but the > problem was uncovered using a python application that is used for > syncing Gmail account data. > > Bill I have copied the backend server configuration to http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an copy of cn=config and there is a files based version the in ldap subdirectory as well. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 02 Aug '11

02 Aug '11

--On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: 2.4.26 >> OS: Debian 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> >> We typically setup local proxy servers to support applications that cannot >> support a GSSAPI bind to the directory server. The proxy server allows >> anonymous access to the directory for connections from the localhost and >> connects to the master using GSSAPI. We are experiencing a failures when >> we attempt to use the paged results control on the proxy. For example: >> >> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost >> "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title >> >> ends with the error: >> >> # search result >> search: 5 >> result: 0 Success >> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >> pagedresults: cookie=KIMAAAAAAAA= >> # extended LDIF >> # >> # LDAPv3 >> # base<cn=people,dc=stanford,dc=edu> with scope subtree >> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >> # requesting: ou telephonenumber title >> # with pagedResults control: size=1000 >> # >> >> # search result >> search: 6 >> result: 2 Protocol error >> text: paged results cookie is invalid >> >> # numResponses: 4005 >> # numEntries: 4000 >> >> This result is not consistent. We have seen examples where 2000 and 3000 >> entries being returned and then the error. Another test that we performed with >> a slightly more complex filter, i.e. >> >> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" >> >> returned usually returned 1000 entries before erroring. >> >> Issuing a similar search directly against the backend ldap server completes >> without >> error. >> >> We have seen the same behavior on OpenLDAP 2.4.23 as well. >> >> Logs generated running slapd standalone with '-d stats,packets' are available at >> http://www.stanford.edu/~whm/files/ldap-debugging/. > > Your log shows that the subsequent search request initiates a new > Bind to the remote server, which implies that it's not re-using the > same connection as the first request. Since a paged results cookie > is only valid within the context of a single connection, you get > this error result. Not sure which log you are looking at. When I look at the log: http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-results… The only connection I see in the log is conn=1000 and it ends with: conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results cookie is invalid ldap_read: want=8, got=7 0000: 30 05 02 01 07 42 00 0....B. ldap_read: want=8, got=0 conn=1000 op=6 UNBIND conn=1000 fd=11 closed These tests where made with a single ldapsearch request. The ldapsearch tests fail when using the proxy and succeed when connecting directly to the LDAP server with the database on it. A side node: the test case I submitted used ldapsearch, but the problem was uncovered using a python application that is used for syncing Gmail account data. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

(ITS#7009) TIMEOUT with unexpected results
by bj＠sernet.de 02 Aug '11

02 Aug '11

Full_Name: Bjoern Jacke Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.159.216.39) When TIMEOUT is set and happend to occur there is nothing that shows that we timed out. For example if you do a large/slow LDAP search using ldapsearch and then stop the conversation between slapd and ldapsearch by "killall -STOP slapd" then ldapsearch will terminate after TIMEOUT seconds and it will return the number of records that it got so far and exit with return code 0 and not error message. I'd expect that after TIMEOUT occuring that we get a warning and a return code != 0

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by hyc＠symas.com 02 Aug '11

02 Aug '11

Quanah Gibson-Mount wrote: > --On Monday, August 01, 2011 9:47 PM +0000 hyc(a)symas.com wrote: >> Your log shows that the subsequent search request initiates a new Bind to >> the remote server, which implies that it's not re-using the same >> connection as the first request. Since a paged results cookie is only >> valid within the context of a single connection, you get this error >> result. > > Given that the client making the request is ldapsearch, which is not going > to rebind mid search, and you can see it is done with noprompt, so there's > no human interaction here, it seems like back-ldap is buggy here. Why is > *back-ldap* closing its connection to the upstream server and initiating a > new bind? You haven't provided any slapd configuration info. Without seeing that it's way premature to claim there's any bug here. Look at the log yourself. back-ldap *doesn't* close the connection. Don't spew garbage about what it does when it didn't actually do such a thing. -- -- 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#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by quanah＠zimbra.com 02 Aug '11

02 Aug '11

--On Monday, August 01, 2011 9:47 PM +0000 hyc(a)symas.com wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: 2.4.26 >> OS: Debian 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> >> We typically setup local proxy servers to support applications that >> cannot support a GSSAPI bind to the directory server. The proxy server >> allows anonymous access to the directory for connections from the >> localhost and connects to the master using GSSAPI. We are experiencing >> a failures when we attempt to use the paged results control on the >> proxy. For example: >> >> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h >> localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou >> telephonenumber title >> >> ends with the error: >> >> # search result >> search: 5 >> result: 0 Success >> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA >> pagedresults: cookie=KIMAAAAAAAA= >> # extended LDIF >> # >> # LDAPv3 >> # base<cn=people,dc=stanford,dc=edu> with scope subtree >> # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) >> # requesting: ou telephonenumber title >> # with pagedResults control: size=1000 >> # >> >> # search result >> search: 6 >> result: 2 Protocol error >> text: paged results cookie is invalid >> >> # numResponses: 4005 >> # numEntries: 4000 >> >> This result is not consistent. We have seen examples where 2000 and 3000 >> entries being returned and then the error. Another test that we >> performed with a slightly more complex filter, i.e. >> >> "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=wo >> rld)))" >> >> returned usually returned 1000 entries before erroring. >> >> Issuing a similar search directly against the backend ldap server >> completes without >> error. >> >> We have seen the same behavior on OpenLDAP 2.4.23 as well. >> >> Logs generated running slapd standalone with '-d stats,packets' are >> available at http://www.stanford.edu/~whm/files/ldap-debugging/. > > Your log shows that the subsequent search request initiates a new Bind to > the remote server, which implies that it's not re-using the same > connection as the first request. Since a paged results cookie is only > valid within the context of a single connection, you get this error > result. Given that the client making the request is ldapsearch, which is not going to rebind mid search, and you can see it is done with noprompt, so there's no human interaction here, it seems like back-ldap is buggy here. Why is *back-ldap* closing its connection to the upstream server and initiating a new bind? --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#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by hyc＠symas.com 01 Aug '11

01 Aug '11

whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: 2.4.26 > OS: Debian 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.165) > > > We typically setup local proxy servers to support applications that cannot > support a GSSAPI bind to the directory server. The proxy server allows > anonymous access to the directory for connections from the localhost and > connects to the master using GSSAPI. We are experiencing a failures when > we attempt to use the paged results control on the proxy. For example: > > ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost > "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title > > ends with the error: > > # search result > search: 5 > result: 0 Success > control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA > pagedresults: cookie=KIMAAAAAAAA= > # extended LDIF > # > # LDAPv3 > # base<cn=people,dc=stanford,dc=edu> with scope subtree > # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) > # requesting: ou telephonenumber title > # with pagedResults control: size=1000 > # > > # search result > search: 6 > result: 2 Protocol error > text: paged results cookie is invalid > > # numResponses: 4005 > # numEntries: 4000 > > This result is not consistent. We have seen examples where 2000 and 3000 > entries being returned and then the error. Another test that we performed with > a slightly more complex filter, i.e. > > "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" > > returned usually returned 1000 entries before erroring. > > Issuing a similar search directly against the backend ldap server completes > without > error. > > We have seen the same behavior on OpenLDAP 2.4.23 as well. > > Logs generated running slapd standalone with '-d stats,packets' are available at > http://www.stanford.edu/~whm/files/ldap-debugging/. Your log shows that the subsequent search request initiates a new Bind to the remote server, which implies that it's not re-using the same connection as the first request. Since a paged results cookie is only valid within the context of a single connection, you get this error result. -- -- 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#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 01 Aug '11

01 Aug '11

Full_Name: Bill MacAllister Version: 2.4.26 OS: Debian 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) We typically setup local proxy servers to support applications that cannot support a GSSAPI bind to the directory server. The proxy server allows anonymous access to the directory for connections from the localhost and connects to the master using GSSAPI. We are experiencing a failures when we attempt to use the paged results control on the proxy. For example: ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou telephonenumber title ends with the error: # search result search: 5 result: 0 Success control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA pagedresults: cookie=KIMAAAAAAAA= # extended LDIF # # LDAPv3 # base <cn=people,dc=stanford,dc=edu> with scope subtree # filter: (&(objectClass=suPerson)(suVisibIdentity=world)) # requesting: ou telephonenumber title # with pagedResults control: size=1000 # # search result search: 6 result: 2 Protocol error text: paged results cookie is invalid # numResponses: 4005 # numEntries: 4000 This result is not consistent. We have seen examples where 2000 and 3000 entries being returned and then the error. Another test that we performed with a slightly more complex filter, i.e. "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=world)))" returned usually returned 1000 entries before erroring. Issuing a similar search directly against the backend ldap server completes without error. We have seen the same behavior on OpenLDAP 2.4.23 as well. Logs generated running slapd standalone with '-d stats,packets' are available at http://www.stanford.edu/~whm/files/ldap-debugging/. Bill

1 0

(ITS#7007) sync: inconsistent directory when starting with emtpy node
by steffo76＠gmx.de 01 Aug '11

01 Aug '11

Full_Name: Stephan Version: 2.4.26 OS: Debian 5.0.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.100.101.1) Hi everybody, I have an odd problem with synchronisation. I have 5 nodes running multi master synchronisation. I recently updated one of them to 2.4.26 (they were all running 2.4.23 before) and started it with an empty database (the database directory contained nothing more than the DB_CONFIG file). Afterwards I noted that some attributes were missing, especially in the root of the directory tree, which looks like this: dn: o=test objectClass: organization o: test After the sync was complete, I could search for the o=test entry but couldn't see it: ldapsearch -H "ldaps://filled.test.xyz" -D cn=superman,o=test -W -x -b o=test o=test # extended LDIF # # LDAPv3 # base <o=test> with scope subtree # filter: o=test # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 I played around a bit and am able to reproduce the problem. I tried combinations of 2.4.23 and 2.4.26, bdb and hdb backends, bdb versions 4.5.20-13 and 4.6.21 but the problem persists. If I take the output of slapcat on one of the nodes and feed it to the empty node before its startup everything seems to be ok. I increased the loglevel and can see the following (rid 1 being the node with the filled database and rid 2 the one with the empty database): On the empty node (rid2) I get lots of 'syncrepl_entry: rid=001 inserted UUID xxx' 'syncprov_matchops: skipping original sid 001' and 'syncrepl_entry: rid=001 be_add' Once the sync is complete the log on the formerly empty node says: Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110310162449.396663Z#000000#000#000000;20110801135804.526931Z#000000#001#000000;20110614092017.772141Z#000000#003#000000;20110722131433.793594Z#000000#004#000000;20110225131904.168266Z#000000#005#000000 Aug 1 17:24:55 empty slapd[7796]: slap_queue_csn: queing 0x9f901da8 20110801135804.526931Z#000000#001#000000 Aug 1 17:24:55 empty slapd[7796]: syncprov_matchops: skipping original sid 001 Aug 1 17:24:55 empty slapd[7796]: slap_graduate_commit_csn: removing 0x9f91f5f8 20110801135804.526931Z#000000#001#000000 Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 cookie= Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 be_search (0) Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 o=test Aug 1 17:24:55 empty slapd[7796]: syncrepl_entry: rid=001 entry unchanged, ignored (o=test) Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 1 17:24:55 empty slapd[7796]: do_syncrep2: rid=001 NEW_COOKIE: rid=001,sid=001,csn=20110801152321.168164Z#000000#000#000000;20110801135804.526931Z#000000#001#000000;20110614092017.772141Z#000000#003#000000;20110722131433.793594Z#000000#004#000000;20110225131904.168266Z#000000#005#000000 On the node from which it took the database (rid 1): Aug 1 17:24:54 filled slapd[17862]: do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Aug 1 17:24:54 filled last message repeated 7 times Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 be_search (0) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 o=test Aug 1 17:24:54 filled slapd[17862]: syncprov_sendresp: cookie= Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 be_modify o=test (0) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Aug 1 17:24:54 filled slapd[17862]: dn_callback : entries have identical CSN sambaDomainName=XYZ,ou=abc,o=test 20110722131010.624524Z#000000#004#000000 Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 be_search (0) Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 sambaDomainName=XYZ,ou=abc,o=test Aug 1 17:24:54 filled slapd[17862]: syncrepl_entry: rid=002 entry unchanged, ignored (sambaDomainName=XYZ,ou=abc,o=test) Aug 1 17:24:54 filled slapd[17862]: do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT Aug 1 17:24:54 filled slapd[17862]: do_syncrep2: rid=002 cookie=rid=002,csn=20110801152321.168164Z#000000#000#000000 Aug 1 17:24:54 filled slapd[17862]: slap_queue_csn: queing 0x7eff600022c0 20110801152321.168164Z#000000#000#000000 Aug 1 17:24:54 filled slapd[17862]: slap_graduate_commit_csn: removing 0x7eff60007040 20110801152321.168164Z#000000#000#000000 It seems to me that the formerly empty node overwrites the entry on the node from which it took all the entries. This is what my config looks like: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE serverID 1 "ldaps://filled.test.xyz" serverID 2 "ldaps://empty.test.xyz" #filled syncrepl rid=2 provider=ldaps://filled.test.xyz:636 type=refreshAndPersist searchbase="o=test" retry="120 20 300 5 1800 5 3600 +" scope=sub bindmethod=simple binddn="cn=superman,o=test" credentials="hello" tls_reqcert=never mirrormode on And the other node: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE serverID 1 "ldaps://filled.test.xyz" serverID 2 "ldaps://empty.test.xyz" #filled syncrepl rid=2 provider=ldaps://empty.test.xyz:636 type=refreshAndPersist searchbase="o=test" retry="120 20 300 5 1800 5 3600 +" scope=sub bindmethod=simple binddn="cn=superman,o=test" credentials="hello" tls_reqcert=never mirrormode on It seems to me that the formerly empty node overwrites the other one after the sync. In some cases the entries don't go missing on the source node, they just don't get replicated to the formerly emtpy node. Unless I made some terrible mistake in the config this is seems to be a bug since in the administrator's guide http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master%2… it says: "Syncrepl is self-synchronizing; you can start with a consumer database in any state from totally empty to fully synced and it will automatically do the right thing to achieve and maintain synchronization" All nodes are configured to use the same ntp source.

1 0

(ITS#7006) openldap does not accept wildcard certificates with mozilla/nss
by hash_oldap＠cycdolphin.net 01 Aug '11

01 Aug '11

Full_Name: Philippe Kueck Version: 2.4.23 / 2.4.26 OS: RHEL 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.98.65.86) When compiled against Mozilla/NSS OpenLDAP does not accept wildcard certificates. This is probably because in tls_m.c the certificate CN (*.domain.example) is matched against the hostname (foo.domain.example), not against the domain (.domain.example). I suggest the following patch: --%snip%-- diff -Nru openldap-2.4.26-orig/libraries/libldap/tls_m.c openldap-2.4.26/libraries/libldap/tls_m.c --- openldap-2.4.26-orig/libraries/libldap/tls_m.c 2011-06-30 17:13:36.000000000 +0200 +++ openldap-2.4.26/libraries/libldap/tls_m.c 2011-08-01 16:29:42.000000000 +0200 @@ -2590,7 +2590,7 @@ if ( av->len == nlen && !strncasecmp( name, (char *)av->data, nlen )) { ret = LDAP_SUCCESS; } else if ( av->data[0] == '*' && av->data[1] == '.' && - domain && dlen == av->len - 1 && !strncasecmp( name, + domain && dlen == av->len - 1 && !strncasecmp( domain, (char *)(av->data+1), dlen )) { ret = LDAP_SUCCESS; } else { --%snip%-- Kind regards, Philippe Kueck

1 0

(ITS#7005) Collision of LDAP calls between Oracle, Curl and OpenLDAP libraries
by mahesh.babu.pothuri＠convergys.com 01 Aug '11

01 Aug '11

Full_Name: Mahesh P Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.126.170.20) Hi, We have one application which will use the Oracle DB, OpenLDAP and Curl libraries. We have started the LDAP server. And we want to perform search/add/update operations using LDAP calls ldap_search_ext_s(), ldap_add_ext_s() and ldap_modify_ext_s(). While performing the search Operation, getting the "Bad Search Filter" error. In the application code we have used the ldap_initialize() for getting the LDAP handle.I am thinking this problem is result of the collision of LDAP calls between Oracle Library and OpenLDAP,Curl libraries. When we did nm on libclntsh.so.11.1, got the references for 0000000001055732 T ldap_search_ext 0000000001055594 T ldap_search_ext_s 0000000001051714 T ora_ldap_search_ext 000000000105145a T ora_ldap_search_ext_s If we try to have a standalone program without any database connectivity same LDAP code is working fine for the search/add/modify operations. Kindly please advise how we can avoid the problem if we use Oracle DB, OpenLDAP and CURL functionality in out application code. Thanks Mahesh

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

hyc(a)symas.com wrote: > I guess we > need to keep using the NULL timeout while the connection is actually in its > Refresh phase, before it enters its Persist phase. Fixed now in master, please 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#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

ml+openldap(a)esmtp.org wrote: > On Fri, Jul 29, 2011, Howard Chu wrote: > >> The ITS mailer only supports plaintext, no attachments. > > Sorry about that. Here's the log inline (5 attempts by syncrepl): I was able to reproduce this behavior. The culprit is the ldap_result() call in do_syncrep2() returning 0 due to a timeout. The actual sequence of events is that do_syncrep1() successfully binds to the master and sends a syncsearch request, then do_syncrep2() reads the search response. The first message is a Present UUID list which it parses successfully. It then loops back to look for the next message from the provider, but due to whatever timing vagaries, that message is not available yet. But anyway, do_syncrep2() returns with rc=0 and this resets the retry counter, as I said before. At the moment I don't have any good ideas how this could be fixed in the code. Timeouts of this sort are normal behavior for refreshAndPersist. I guess we need to keep using the NULL timeout while the connection is actually in its Refresh phase, before it enters its Persist phase. I think you could workaround it by using delta-syncrepl, which doesn't use a Present UUID list. This will require some more thought. -- -- 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#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 29 Jul '11

29 Jul '11

On Fri, Jul 29, 2011, Howard Chu wrote: > The ITS mailer only supports plaintext, no attachments. Sorry about that. Here's the log inline (5 attempts by syncrepl): Jul 22 13:12:25 vmca02 slapd[23778]: slapd starting Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 fd=16 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 BIND dn="cn=manager" method=128 Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=1 SRCH attr=* + Jul 22 13:12:26 vmca02 slapd[23778]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 fd=17 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 BIND dn="cn=Manager" method=128 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 BIND dn="cn=Manager" mech=SIMPLE ssf=0 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=1 ADD dn="uid=user68,ou=People,dc=example,dc=com" Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x43403110 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=2 UNBIND Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=1 RESULT tag=105 err=0 text= Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (0) Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user68,ou=People,dc=example,dc=com Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c51b20 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: slap_graduate_commit_csn: removing 0x2c49060 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 fd=17 closed Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user68,ou=People,dc=example,dc=com (0) Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c51b20 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 fd=17 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 BIND dn="cn=Manager" method=128 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 BIND dn="cn=Manager" mech=SIMPLE ssf=0 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=1 ADD dn="uid=user69,ou=People,dc=example,dc=com" Jul 22 13:12:52 vmca02 slapd[23778]: slap_queue_csn: queing 0x44405110 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: slap_graduate_commit_csn: removing 0x2b40df0 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=1 RESULT tag=105 err=0 text= Jul 22 13:12:52 vmca02 slapd[23778]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=2 UNBIND Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 fd=17 closed Jul 22 13:12:52 vmca02 slapd[23778]: conn=-1 op=0 ldap_back_retry: retrying URI="ldap://vmca01" DN="cn=monitor" Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:12:52 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c518d0 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1000 op=2 UNBIND Jul 22 13:12:52 vmca02 slapd[23778]: conn=1000 fd=16 closed Jul 22 13:12:52 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 BIND dn="cn=manager" method=128 Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=1 SRCH attr=* + Jul 22 13:12:57 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:12:57 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:12:57 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=2 UNBIND Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 fd=15 closed Jul 22 13:12:57 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=1 SRCH attr=* + Jul 22 13:13:02 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:02 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:02 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:02 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=2 UNBIND Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 fd=15 closed Jul 22 13:13:02 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:02 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=1 SRCH attr=* + Jul 22 13:13:07 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:07 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:07 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=2 UNBIND Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 fd=15 closed Jul 22 13:13:07 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=1 SRCH attr=* + Jul 22 13:13:12 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:12 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:12 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:12 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=2 UNBIND Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 fd=15 closed Jul 22 13:13:12 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:12 vmca02 slapd[23778]: connection_read(15): no connection!

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

ml+openldap(a)esmtp.org wrote: > --UugvWAfsgieZRqgk > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Thu, Jul 28, 2011, Howard Chu wrote: > >> I think we need to see more of the log than this. The only reason >> for your observed behavior to occur is that somewhere along the >> line, a step in the replication actually returned LDAP_SUCCESS, >> which resets the retry counter. So we need to see the complete log >> for at least one full cycle of "(4 retries left)", "(3 retries >> left)", "(4 retries left)". > > I've attached the full log of the test (from start to stop); it's > rather small in .gz format. I hope that will go through, otherwise > I can extract the requested full cycle and send that inline. The ITS mailer only supports plaintext, no attachments. -- -- 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#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 29 Jul '11

29 Jul '11

--UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 28, 2011, Howard Chu wrote: > I think we need to see more of the log than this. The only reason > for your observed behavior to occur is that somewhere along the > line, a step in the replication actually returned LDAP_SUCCESS, > which resets the retry counter. So we need to see the complete log > for at least one full cycle of "(4 retries left)", "(3 retries > left)", "(4 retries left)". I've attached the full log of the test (from start to stop); it's rather small in .gz format. I hope that will go through, otherwise I can extract the requested full cycle and send that inline. --UugvWAfsgieZRqgk Content-Type: text/plain; charset=unknown-8bit Content-Disposition: attachment; filename="ldap.2.gz" Content-Transfer-Encoding: quoted-printable =1F=8B=08=08=D2=D72N=02=03ldap.2=00=D5=9DOs=1C=C7=91=C5=EF=FB)=C6=DC=0B=E9= =15=C1=AE?=3D=DD=8D=08=1C=B8$=1C=A2Cb(H=EA=E0=DD=D8@=0Cf=86=12V =86=1A=80= =B2=FC=ED=DDC=D22ATU=BF=AC=CAW=1D=F0=C1$aO=E6+LU=E5=FBe=02=D3=7F=FDp=B9=B0v= a=DC=B1=B1=C7=B6]=FC=F6n=BDj=EC=E2=FAr=F5~=F3=BF=D6u]=FF=7F=C7=9F=FE=B5=B8= =BEY=EDo.=AE~=FA=8F=BF=DEz=CD2=FC=9A=F5=EE=EA=EA=C44M=B3x=BB91=CB=C5=D3g=CF= N=7Fx=B3x=BB=DF=BD[=FC=F0=F4=CD=B7'O~[=ED=9F=EC?\=3D=B9=DC=AC=DE_,=1E=06=BE= =F8H=9Aj=F7=FE=A4Y=FC=F7=8B=97=CF=17=9B=AB=93=07=EB=AB=93w=AB=AB=D5O=DB=FD= =83=C5=BB=ED=CD=CF=BBQ=88=ED5c=AE=7F>y=FD=E2=FB=1F=BE;]\_=BF=3Di=B2B=BF:}= =FD=E3wo=167=AB=9FN=86n=B1=DD=EF=C7=AF=DDl=7F=BF9=C9=88f=16=AF_=3D=FBvq=BE= =BA=DE=9E<x=B0=B8^=EF=DEoO=ECb=B3=DDoGy=8B=B7=17=977=DB=FD=C9=83=87=BB=F3= =FF=DF=AEo=9E]=AE=AE=AFO=FE=FC=E8A~=A6=D5=CD=CD=FE=E4=CF=8B=FF=C2"lvg=D7=FF= =B8Z=EF=B7=EF=ED=F1b=7F=B19i=1A=B3=F8=EE=F9=D3=1F=CE=C6o=C2=D9=8B=97oN_}=7F= =FA=FC=C5=D37=A7=8B=C7=E3=F7=E5/=E3W=BF=3D{~=FA=DD=E9=9B=D3=DB =9CKK4=1F7]= =A7=B1=E9=A6S=DD=D9 =DFOm=BA=B2=98=C9M=07=86=067=1D=14=CD,=9E>=FF=A4=F3=C3= =F8=96~=B8=DE=EE=97=FD7=BB=0F'?lw=EF/=B7=DFl=D6'=DB=DFW=EF>=FFu=BD{=F7=00= =CBq=F8=D7=D9=AF=1F=B6=1F=B6g=EB=EB=AB=E3=C5=F8=D7=F1=F2Y4=BF{=E7=1BgL=B3= =B0=CD=F8=DF=9D=B5=E3=9F=D6=B9#=DF=99f9=FC=CF=7F6=1F=FF3=FEa>=FF=15=CC7=EE= =CC=F7=FB=DDog=D7=DB=AB=CD~{=FD=FE=B0=CC=DD/=17=DB=93=CF;=F5=9B=EB=CF=7F=8E= rNts=07=0FF=B5=EC=9FS_=9Em=AFn=F6=FF=08=9C=CC=D7=A7O=C7=C3~v=FA=F2=CD=AB=BF= =3D=FC=F8=D5=D7=7F{=F9=ECl|=DBs=0E=8B]=FC=F8=F2=B0=B5=B3=B6=DA=17=1B=D74=AD= |=E7=C6=D6z=BE=1D=DF=F7=D5~=FD=F3=E2a=F3=A8,=14v =0F=81]=B7=E6=DC=AA=9F=81C=BA=9F=F6=AB=CD=87=D5=CD=98q=F7=EE=DD=C5=CD=A7=C4= =FB=ED=BB=DDo=FFJ=ED=87f=A9=9D=FA=EB=AB{}=B9=BB=DEn=8A=DF=D4=D5f=03=BE!=827= =9E=F3=A6=B46=FD=9D=B1zEm:=95=BC=A8=95=C5L=16504X=D4=A0h=81=A26=08=8AZ,G=BC= =A8y=DF=B4_=17=B5=D6=1E=F5=B6=19:=93=BDw=B0=03}=EE=9B=CD[=ED=D4_};=D1=8B;= =BA=92=EC=F2\=BE=94=92=F2=AC=F0=1E=AA=95g=E8=AD =97g=F4r ]=DB=C9=D7>=FE=ECH=0F=D7=D4=D9=F9j=FD=CB=D9~=FBi=99=87?=0E=1B=F4=C7W/N=1E= =1C=FE=E7=E3'O>=C61=0F=16=CF_~B=B1=DD=D5=C5=CDn=FF=A0=EC=1B=F9E=EDo=ED=A3= =B2X=D8mQxY=1C=EAL=BF=D1>=B0W=1F./=CF=D6=AB=CB=CB=C3=BB=B08>=1C=D1=DD~|=936= =DB1=A5=F3=C5=DF=E3[=A5xH=97=E2=E2=F7A=96=EF=ED=EA=E2r=BB=11=A4=BD=C5=C2y'= =E6_=8D=11=C9=89=F9=F7Et=F9=EF=A5=EE=D7=8B=F1=FF=FF=C7qy=E8?=FE=FDb{=BD=B8= =DC=BE=BD=F9zA]Z=95=CB=E8=A1=94=C5LW~,4Z=F9'=A3=1D=DE=92V=C5a!=C2U=DA5=92L= =E1vM,=C2=F5=FEz1^<=B9v6=12=F5r=F7=13!=EA=FA=DD=FBE=F3=CD=E2f=B7[=EC.7=F9J= =04=D7h$=EA=E9=E1"B=99=E3=D9=EB=97=F07=E2=B0=B0=ED~1=DE=C9=DB_?=AC.=C7=B5.= =D67=BF+=7F=1F=BF=B0Y=87=8AxvpZ=BB=AB=EB-=C3mut=BF#=CCp1.t=7F3=16=82=1F=7F|= =F1|1=B4=E7=BD=EBW=F6=B1?o=DB=F1=BF=D6=EB=C7=FDy=D3<>=DF:;=9C=1B=D7o=CE=0BW= =944=1E]=05=E3=D1i8=81=AE=B2=13=E8=E6q=02=C85=1Bq=02`=D9 :=81=AE=C0 =B8=B8= =13p=C7=CD=84?=F1b'P=1A3=E1=04=E0=D0=90=13=00=A3)=94gY=A6Py=8EG()=CF=F1=A8%= =E59=B1=DAhy=96)A=ABK<=EA}(=CF=89=F7=BCVyNK=D0(=CF=F2=0Ce=E5=199=8AJ=F6_=BE= =B4=B8=13=90=C7=92;=81x=0E=81=13=C8Zt=81=13`=E7=8B8=81x=DAR8=07kE=C8c=E0{= =FB=AE=C7H=BFv,l=17=BB=AB=F1=9EYm=1E=9A=F6=D1=B8#v_|=FDO=AC@=13=8E=A9U<=A9= =93=A92lPQ=CC=B4=0D=C2B=A36=08=89=A6c=83=04=99"6=A8=A3=D8=A0=8Eb=83=BA=0C= =1B=D4QlPw=AFmP7=BF=0D=EA=E86=A8=ABl=83:Eo=D2U=F0&=9D=867=E9*{=93n=1Eo=82\= =B3=11=07=01=D6=DC=A0=83=A0u)=CC=84=AFY=EA9=81=E9Tr'P=163=E9=04=C0=D0=A0=13= =80=A2=A98=01I=A6=B0=130=94=86=88=A14DLFC=C4P=1A"=E6^7D=CC=FC=0D=11Co=88=98= =CA=0D=11=A3=D8=A50=15=BA=14F=A3Ka*w)=CC<] C=EBR@=17x=D8c=A0=D5<=E41=8CVsA/=D0=84c=EA=14=BD=C9d=AA=0CoR=143=EDM=B0=D0= =A87A=A2=E9x=13A=A6=887=A1t)=0C=A5Ka2=BA=14=86=D2=A50=F7=BAKa=E6=EFR=18z=97= =C2T=EER=18=C5.=85=A9=D0=A50=1A] S=B9Ka=E6=E9R=98=8E=E6M=90=0B<=E2M=C0j=1E=F4&]=05K! d'=9CV=AF=E7M=A6S=C9=BDIY=CC=A47=01C=83=DE=04=8A=A6=E2M$=99=C2=DE=C4R=FA&= =96=D27=B1=19}=13K=E9=9B=D8{=DD7=B1=F3=F7M,=BDob+=F7M=ACb=DF=C4V=E8=9BX=8D= =BE=89=AD=DC7=B1=F3=F4M,=ADo=02]=E0ao=82V=F3=907=B1=B6=82=A5=90=05=EA=D3=AB= =19=14=BD=C9d=AA=0CoR=143=EDM=B0=D0=A87A=A2=E9x=13A=A6=887=E9)=DE=A4=A7x=93= >=C3=9B=F4=14o=D2=DFko=D2=CF=EFMz=BA7=E9+{=93^=D1=9B=F4=15=BCI=AF=E1M=FA=CA= =DE=A4=9F=C7=9B=F44o=82\=E0=11o=02V=F3=A07=E9+X Q=A0=89=8F'1=8D=9E7=99N%=F7&e1=93=DE=04=0C=0Dz=13(=9A=8A7=91d {=93=E8=E7=C0=14y=93X=D42o=12]m=C2=9BH=94=E0=A55=16=F5~x=13=E0S=C2=D8=DE=84= =FDq]=F2=0C=A5=DE=A4=E0C=B9=EE=D4=C2=ECO=E5=12x=93X=0E=917)=FD=D0*=A97=E1= =E6=8Bz=13=E8=9A=0D;=08=B4=E6=86=1C=C4=F4'=EA=E5Z"=97=F65=C6(:=81=C9T=19N= =A0(f=DA `=A1Q'=80D=D3q=02=82L=11'@=E9R8J=97=C2et)=1C=A5K=E1=EEu=97=C2=CD= =DF=A5p=F4.=85=AB=DC=A5p=8A] W=A1K=E14=BA=14=AEr=97=C2=CD=D3=A5=80=AE=D9=88=13=00kn=D0 =D0=9A#~=C2=9FX= =3D'0=9DJ=EE=04=CAb&=9D=00=18=1At=02P4=15' =C9=14v=02=9E=D2=13=F0=94=9E=80= =CF=E8 xJO=C0=DF=EB=9E=80=9F=BF'=E0=E9=3D=01_=B9'=E0=15{=02=BEBO=C0k=F4=04|= =E5=9E=80=9F=A7'=E0=DD|%9=EA1=D0j=1E=F2=18=A9=D7=8A=C6=0Cz=81&=1C=93S=F4&= =93=A92=BCIQ=CC=B47=C1B=A3=DE=04=89=A6=E3M=04=99"=DE=84=D2=A5=F0=94.=85=CF= =E8RxJ=97=C2=DF=EB.=85=9F=BFK=E1=E9] _=B9K=E1=15=BB=14=BEB=97=C2kt)|=E5.=85=9F=A7K=E1y=ED=02=E4=02=8Fx=13=B0=9A= =07=BDI_=C1R=88=02=B5=13NK=F1=F3=F6=A6S=C9=BDIY=CC=A47=01C=83=DE=04=8A=A6= =E2M$=99=C2=DE=A4=A5=F4MZJ=DF=A4=CD=E8=9B=B4=94=BEI{=AF=FB&=ED=FC}=93=96=DE= 7i+=F7MZ=C5=BEI[=A1o=D2j=F4M=DA=CA}=93v=9E=BEIK=EB=9B@=17x=D8=9B=A0=D5<=E4M= ZW=C1R=C8=02M8-=C5O=18=9DN=95=E1M=8Ab=A6=BD =16=1A=F5&H4=1Do"=C8=14=F1&=94= =BEIK=E9=9B=B4=19}=93=96=D27i=EFu=DF=A4=9D=BFo=D2=D2=FB&m=E5=BEI=AB=D87i+= =F4MZ=8D=BEI[=B9o=D2=CE=D37ii}=13=E8=02=8Fx=13=B0=9A=07=BDI_=C1R=08=02=F9= =E3f=C2i=A9}=E6)=92J=EAMJc&=BC =1C=1A=F2&`4=05o"=CB=14=F2&=F1=08%=DE$=1E=B5= =C4=9B$V=1B=F5&2%hi=8DG=BD=0F=DE$=F1=9E=D7=F2&i =1A=DED=9E=A1=CC=9B=C8=F3E= =1F=0C/=0F%=B7&Yr%=AE=02]R=F0 =C8=7F=BC=D9/^=BE9}=F5=FD=E9=F3=17O=DF=9C.=1E= =8F=D7=EF_=C6=AF~{=F6=FC=F4=BB=D37=A7=05 =EAm=E7=F8=93v}=DB=9Eg<i=B7=3D=B6= =FD=B1[=A6=AF=FDN=E5=89=EE`*=D1=13=DD=15b=C6 =B9$=F4t!=C7=A3=DD}=A2{=D7`OtO=E6=88?=D1=DD8w=FB=89=EE=D6=F6ny44=CD=B2=05= =F6N_=F2D=F7u=EBM=AF=9E:=EF=11=EC*=B9=B3=EF=07=B5=95=17=97=BBd=86[[=F5=0E= =E4=E0/5_=9E=19=D3=B4=89C=D3c=97=D3W=CC4=FDZ=DD'=BAg=BD/=E1=A2=9D=15 =BB,=04g7=F2@w=DB=9Fg=9F=D7=A1=C8#=A4W=16=F8=0E=0E=F5V=E7=C6=8Cmz=9F=F6JE= =14J%,=A2=C51=E3E=14=0F=8D=14Q4=9AY=8C=A6.=B3=88&r=C4=8B=A8]7=B6=F5_=EE=1D= =D7=DA=F6=C8t=FD=B2k=B2=F7Nn%=D3=C8=9D_=C9=B4V=9ES=C9>y=F9GY[=E6VE=CA=D8=81= =98=E59=F7=8DYgo=94%=B0=92@Y=86^=1A=A9=A3=89=D7J=EBZF(q]K=E5=88=DE=FC+=D7= =B9=FC7E=FE=E9=D4=9B=ED=E5=F6f=9BW=DAR=19 =0B=F4=CBcg=D2[gP*mP*ai+=8E=19/mx= h=A4=B4=A1=D1JJ["G=9A=0Fo=976=BFt=E6=A8].]=EB=14=F6N=EC=EEuV=F2=3DBy=D3l=B9= K \=BE=82=13t=E7=F2=3D=BC6]=BDl=A3x=FA&Se=9C=BE=A2=98=E9=D3=87=85FO=1F=12= =ED=EE=E9K=B7.=1F`9=E2=A7o=BC=B5=FD=9D=D3=D7=1E-=9B~=D9=0C=D3[=B6=C8=AA=1C= =9A=8Ao=D5SgzZ=8D=DC=F9=9EVk=E5:=9E=16=DF=AD=90=A7E=C3E=EE6=F0~ =DEmJ=C62#=94p=CA=91=CE=91=EA=CB=DB=FC=D3=BB,5=96=82=B9=CA,=0BL=F7=F6=ACQ,m= =93=A92J[Q=CCti=C3B=A3=A5=0D=89=16(m=BD=A4=B4=F5=E5=3D=93q=EF=F4G=B6=ED=EC= =D0g=EF=9D=82=FAR=9C=BB=A8=BE=A8=AC\=AF=BE`[=06=AE/=BD=B6m/=FEv=DDZI=A4=B4= =81=F7S=B0=B4=F5z=A5-=F7g=0B{Ai=13=CF=02=CE=BD=DD=AC=19=A7=17,m=BD=B0=B4=D5= ]=E0=B8]=93[=C7=EA=95=B6=E9T=F2=D2V=163Y=DA=C0=D0`i=83=A2=05J['(m=B1=1C2j= =F3=CD=D1=D2vm=DBd=EF=9D=FC=D2V=9E=BB=A4=B4=E9=AC\=AD=B4=81[=06-m=C9=DD=810= =F6=B9=FAF=B9=B5=92piC=EF=A7Pi=93=BEK=89=D2&=0D=85=9D=DF=C2=E3{xS=D6=E7=8C= =D3=0B=96=B6NV=DAj/0=FDS=C2=D6)=96=B6=C9T=19=A5=AD(f=BA=B4a=A1=D1=D2=86D=0B= =94=B6=A5=A4=B49=0Dj=F3=EE=A8i=BCm=87=EC=BDSP=DA=8As=17=956=95=95=EB=956l= =CB=C0=A5=CD=95Q=9B=DD=AC=B47=CA=AD=95DJ=1Bx?=05K=9B=D3+m=B9?v=BD=14=946=97= =015[=C38=BD`i[ K[=E5=05=A6=1F=AEl=BDbi=9BL=95Q=DA=8Ab=A6K=1B=16=1A-mH=B4@ik%=A5=ADS=A1=B6= =EE=C8v=B6-=D8;=05=A5=AD8wQiSY=B9^i=C3=B6=0C\=DA=BA=92=D2=B6r]=EB=B47=CA=AD= =95DJ=1Bx?=05K[=A7W=DA=BA=CC=D2=D6 J['=FF=F1=DD=A6w=8C=D3=0B=96=B6VX=DA*/pHo=9DV=B1=B4M=A6=CA(mE1=D3=A5=0D=0B= =8D=966$Zii=1BT=A8m8j=9Dm;=8D=BD#=FB!=AE=A4~=84+V-u)=91=CB=17<A=A1=CBw=E2S= =89=ECR=EF=F4M=A7=92=9F=BE=B2=98=C9=D3=07=86=06O=1F=14-p=FA=BC=E0=F4=B5N=C3= X=B6=EEh|a3L=F7=DBZ=F5=9EIy=EE=12c=A9=B3r5c n=19=D4X=B6=AEp=1C=E0Z=ED=8Drk%= =E1=BB=0D=BD=9F$w[=86=B1=CC=FE=84?=8F=1B=CB6=E7=97=AB=BDa=9C^=D0Xz=99=B1=AC= =BD=C0=89=9F=FF=EB=14K=DBd=AA=8C=D2V=143]=DA=B0=D0hiC=A2=05J=9B=93=94=B6V= =E3=B7=03=DA=C3=0F=00=FA=AE=B3=D9{=A7=A0=B4=15=E7.*m*+=D7+m=D8=96=81K[=AB]= =DA=8A=BF]=B7V=12)m=E0=FD=14,m=AD^ik3K=9B=13=94=B66=E3=F7=C2<=E5=F4=82=A5= =CD K[=E5=05N=B4=DBz=C5=D26=99*=A3=B4=15=C5L=976,4Z=DA=90h=81=D2f%=A5Me=1C= =D0vG}k;=B3T=D8;=B2=9EI[=D8=B0^v=96=BA=94=C8=E5=0B=9E=A0=BB=97ow=DC=A4=7Fi= =CE=AA=FD=DA)=92Jz=FAJc&N=1F=1C=1A:}`=B4=C0=E93=F0=E9=8B=E7=10=19=CB=AE1G= =B6=F7=C3=E4=EFj&=F2=E5=1AK=85=DC=05=C6Ri=E5J=C6=12=DE2=98=B1=9C=D8=1D=C80= =CE=F5=DA=1B=E5=D6JBw=1B~?I=EE6=B1=B1=94=87=C2=CEo=E1=F1=FD=D8RX3N/h,=8D=C4= X=D6_=A0On=1D=D7(=96=B6=C9T=19=A5=AD(f=BA=B4a=A1=D1=D2=86D=0B=94=B6FR=DA=BC= =B4=B4=8D(a)r=B7=B4=F9#=D7=BAe?d=EF=9D=82=D2V=9C=BB=A8=B4=A9=AC\=AF=B4a[=06.m= ^w=D4=A9=F0=ED=BA=B5=92Hi=03=EF=A7`i=F3z=A5=CDg=96=B6FP=DA=BC=C6=CDO=DB=C3= =81=D2=D6=08K[=DD=05N|=C6=BD3z=A5m:=95=BC=B4=95=C5L=96604X=DA=A0hw?LVT=DA= =DA=BE=FC=C3d}=D7=F6G=ED=D29=93=BFw=F2K[y=EE=92=D2=A6=B3r=85Ot=C5=F7=0B=F4= =B1=ACS[c=B2=AE=BDm=97=CBA{=97=DCZI=B8=AE=A1=97S=A8=AE=B55?L6cKD=9EN=93=15+= =A7=90=8A/=0B=D7l=CE=BB-e=17T|;=D0=87=EF=E4=BE=A7=B7>&=BF=C1=1F=BES!_=E8=E1= ;=C813=CB=EC=13=FA=C7Ce$'=B4=E8=99?c=E4~=EA=C1(=CE=AA<=EA=06L%z=D4=8DB=CC= =84=A9=81CC=A6=06=8CV=FA=A8=1Bq=A6;=8F=BAIF=B8=F3=A8=1B=81}=EE=F5=1Fu=93^= =ED=BB=F7=8B=C7=E6=EE=B3n=C4R=C0=87M=D0=A5=E0=1F=D9=CD=97=82=7F=C4*] =FE=A1\5=A4=80=1F=A2RA =FAK=EF5=A4=80=BF=A4XC =F8K%=15=A4=A0?=86XC =F8c#|)=F0=A0=A1=86=94=E2=CA=16y=DC=9AX =8A=0E=3D=E9=81ej=124x=BF/|`=D9fXu= =AD}=BBy=BCZ=9F=BB=C7~=BD2=8FW=E7=C6?=EE=97=E7=FD=CA=0D}o=D6=DB=B2|q\=ED=F3= =9FX=06=E3j<=87=80=E7=FA=E2=C7=9E=C9x=8E=9D/=C2s=A0Y=0E=F1=1CNNwy=AE=07=1E= =C2=96=E09=97=E4=B9=89>=90S=E4=B9=C9T=19<W=143=CDsXh=94=E7=90h:<'=C8=14=E1= =B9=9E=C2s=3D=85=E7=FA=9C=B2=DESx=8E*E=C6s\)"=9E=E3J=11=F1=1C] =CEsl)=02=9E=A3K=C1y=8E.=05=E79=B6=14=01=CF=D1=A5=E0<G=96"=E19=BA=94=E2=CA= =96=E4=B9=9E=C2s=FD=FC<=D7=D3y=AE=AF=CCs=BD"=CF=F5=15x=AE=D7=E0=B9=BE2=CF= =F5=F3=F0=1Cb=96#<=07=92S=90=E7h=F393A=99^=8F=E7=A6S=C9y=AE,f=92=E7=C0=D0 = =CFA=D1TxN=92)=CCs=862=9F3=94=F9=9C=C9i=D3=1A=CA|=8E+E=C4sd)=12=9E#K=91=F0= =1C_ =CCst)8=CF=F1=A5=C0<=C7=97=02=F3=1C] =CEs|)0=CF=B1=A5=08x=8E/=A5=B8=B2=A5x=CEP=E6sf=FE=F9=9C=A1=CF=E7L=E5=F9=9CQ= =9C=CF=99 =F39=A31=9F3=95=E7sf=9E=F9=1Cd=96=C3<=87=92S=88=E7=8C=A3=F1=DC=04e=B6=8A<7= =99*=83=E7=8Ab=A6y=0E=0B=8D=F2=1C=12M=87=E7=04=99"<G=99=CF=19=CA|=CE=E4=B4i= =0De>=C7=95"=E39=AE=14=11=CFq=A5=88x=8E.=05=E79=B6=14=01=CF=D1=A5=E0<G=97= =82=F3=1C[=8A=80=E7=E8Rp=9E#K=91=F0=1C]JqeK=F2=1Ce>g=E6=9F=CF=19=FA|=CET=9E= =CF=19=C5=F9=9C=A90=9F3=1A=F39Sy>g=E6=99=CFAf9=C2s 9=05y=8E6=9F=B3=13=94=B9= =D4=E3=B9=E9Tr=9E+=8B=99=E4904=C8sP4=15=9E=93d =F3=9C=A5=CC=E7,e>gs=DA=B4=962=9F=E3J=11=F1=1CY=8A=84=E7=C8R$<=C7=97=02=F3= =1C] =CEs|)0=CF=F1=A5=C0<G=97=82=F3=1C_ =CCsl)=02=9E=E3K)=AEl)=9E=B3=94=F9=9C=9D=7F>g=E9=F39[y>g=15=E7s=B6=C2|=CEj= =CC=E7l=E5=F9=9C=9Dg>g=DD|`=15%E=94=C9B=A4=98z=ED=C8=0C=17=BB=AB=F1=F0=AF6= =0FM=FBh=DC=11=BB/=BE=FE'V=A0 =EE=ED=14 s2U=06a=16=C5L=13&=16=1A%L$=9A=0Ea 2E=08=9321=B4=94=89=A1=CDi=1C[=CA=C4=90+EF=98\)"=C2=E4J=11=11&] N=98l)=02=C2=A4K=C1 =93.=05'L=B6=14=01a=D2=A5=E0=84I=96"!L=BA=94=E2=CA=96$L= =CA=C4=D0=CE?1=B4=F4=89=A1=AD<1=B4=8A=13C[abh5&=86=B6=F2=C4=D0=CE31=B4=BC= =D1=1Db=C3#=84 2Y=900=FB `( =E4&x=B9=D7#=CC=E9Tr=C2,=8B=99$L04H=98P4=15=C2=94d =13=A6=A3=CC0=1De=86=E9rZ=D9=8E2=C3=E4J=11=11&Y=8A=840=C9R$=84=C9=97=02=13&] N=98|)0a=F2=A5=C0=84I=97=82=13&_ L=98l)=02=C2=E4K)=AEl)=C2t=94=19=A6=9B=7F=86=E9=E83LWy=86=E9=14g=98=AE=C2= =0C=D3i=CC0]=E5=19=A6=9Bg=86=E9h3L=C8=86=87 =13e=B2=10a:W=01=0Ce=81&xyP$=CC= =C9T=19=84Y=143M=98Xh=940=91h:=84)=C8=14!L=CA=0C=D3Qf=98.=A7=95=ED(3L=AE=14= =19ar=A5=88=08=93+ED=98t)8a=B2=A5=08=08=93.=05'L=BA=14=9C0=D9R=04=84I=97=82= =13&Y=8A=840=E9R=8A+[=920)3L7=FF=0C=D3=D1g=98=AE=F2=0C=D3)=CE0]=85=19=A6=D3= =98a=BA=CA3L7=CF=0C=D3=F5=AC=C7=3D@6<B=98 =93=05 =B3=AF=00=86=A2@>=CD=CB=BE= =D1#=CC=E9Tr=C2,=8B=99$L04H=98P4=15=C2=94d =13=A6=A7=CC0=3De=86=E9sZ=D9=9E2=C3=E4J=11=11&Y=8A=840=C9R$=84=C9=97=02=13&] N=98|)0a=F2=A5=C0=84I=97=82=13&_ L=98l)=02=C2=E4K)=AEl)=C2=F4=94=19=A6=9F=7F=86=E9=E93L_y=86=E9=15g=98=BE=C2= =0C=D3k=CC0}=E5=19=A6=9Fg=86=E9i3L=C8=86=87 =13e=B2=10azW=01=0Ce=81=D2=BC= =EC=8D"aN=A6=CA =CC=A2=98i=C2=C4B=A3=84=89D=D3!LA=A6=08aRf=98=9E2=C3=F49=AD= lO=99ar=A5=C8=08=93+ED=98\)"=C2=A4K=C1 =93-E@=98t)8a=D2=A5=E0=84=C9=96" L= =BA=14=9C0=C9R$=84I=97R\=D9=92=84I=99a=FA=F9g=98=9E>=C3=F4=95g=98^q=86=E9+= =CC0=BD=C6=0C=D3W=9Ea=FAyf=98=90Y=8Ep HNA=0E=A4=FD=FAg=EB=D3=AA=AC=1E=CFM= =A7=92=F3\Y=CC$=CF=81=A1A=9E=83=A2=A9=F0=9C$S=98=E7b=11=CAx.=16=B5=8C=E7=A2= =ABM=95u=89=14=9C=E7=B8RD<G=96"=E19=B2=14 =CF=F1=A5=C0<G=97=82=F3=1C_ =CCs|)0=CF=D1=A5=E0<=C7=97=02=F3=1C[=8A=80=E7=F8R=8A+[=8A=E7$Jp=98=8AV=EEz<= =97=92=A0=C3s=D2=0C=A5<'=CD=97=E29i=AC=1C=9E=8B=E5=10=F1\=C6=A2=8Bx=8E=9B/= =CAs=90Y=0E=F3=1CJN!=9E=8B=BDV=81=E7=86=B4*=A7=C8s=93=A92x=AE(f=9A=E7=B0=D0= (=CF!=D1txN=90)=C2s=03=85=E7=06 =CF=0D9e}=A0=F0=1CU=8A=8C=E7=B8RD<=C7=95"=E29=BA=14=9C=E7=D8R=04<G=97=82=F3= =1C] =CEsl)=02=9E=A3K=C1y=8E,E=C2st)=C5=95-=C9s=03=85=E7=86=F9yn=A0=F3=DCP=99=E7= =06E=9E=1B*=F0=DC=A0=C1sCe=9E=1B=E6=E19=C4,Gx=0E$=A7 =CF=0D=1C=9E=1B=8E=9B = =CA=F4Z<=87=A4=92=F2\i=CC=04=CF=C1=A1!=9E=03=A3)=F0=9C,S=88=E7=E2=11Jx.=1E= =B5=84=E7=12=AB=8D=97u=99=14=94=E7=D8R=04<G=97=82=F3=1C] =CEs5=A4=80<WA =CAs5=A4=80<WC =C8s=15=A4=A0<WC =C8s|)0=CF=D5=90R\=D9=E2<'S=82=C2T=A2r=D7=E2=B9=B4=04=0D=9E=93g(=E39y=BE8= =CF=C9c=C9y.=9EC=C0sY=8B.=E09v=BE=08=CF=81f9=C4s89=DD=E5=B9=F8k=15xn=822[E= =9E=9BL=95=C1sE1=D3<=87=85Fy=0E=89=A6=C3s=82L=11=9E=1B(<7Pxn=C8)=EB=03=85= =E7=A8Rd<=C7=95"=E29=AE=14=11=CF=D1=A5=E0<=C7=96"=E09=BA=14=9C=E7=E8Rp=9EcK= =11=F0=1C] =CEsd)=12=9E=A3K)=AElI=9E=1B(<7=CC=CFs=03=9D=E7=86=CA<7(=F2=DCP=81=E7=06=0D= =9E=1B*=F3=DC0=0F=CF=0D=F3=81U=9C=14A&=0B=92=E2=A0=F2=C1*=8A=81=CC=04=F7.= =F5=08s:=95=9C0=CBb& =13=0C=0D=12&=14M=850%=99=C2=84i(=13CC=99=18=9A=9C=C6= =B1=A1L=0C=B9RD=84I=96"!L=B2=14 a=F2=A5=C0=84I=97=82=13&_ L=98|)0a=D2=A5=E0=84=C9=97=02=13&[=8A=800=F9R=8A+[=8A0=0Debh=E6=9F=18=1A=FA= =C4=D0T=9E=18=1A=C5=89=A1=A9014=1A=13CSybh=E6=99=18=1A=DA=E8=0E=B2=E1a=C2D= =99,D=98=A9=D7=AA=81=A1,=D0=04/w=8A=849=99*=830=8Bb=A6 =13=0B=8D=12&=12M=87= 0=05=99"=84I=99a=1A=CA=0C=D3=E4=B4=B2=0De=86=C9=95"#L=AE=14=11ar=A5=88=08= =93.=05'L=B6=14=01a=D2=A5=E0=84I=97=82=13&[=8A=800=E9Rp=C2$K=91=10&]JqeK=12= &e=86i=E6=9Fa=1A=FA=0C=D3T=9Ea=1A=C5=19=A6=A90=C34=1A3LSy=86i=E6=99a=1A=DA= =0C=13=B2=E1=11=C2=04=99,H=98C=050=14=05=B2=13=BC=DC=EB=11=E6t*9a=96=C5L=12= &=18=1A$L(=9A aJ2=85 =D3Rf=98=962=C3=B49=ADlK=99ar=A5=88=08=93,EB=98d)=12=C2=E4K=81 =93.= =05'L=BE=14=980=F9R`=C2=A4K=C1 =93/=05&L=B6=14=01a=F2=A5=14W=B6=14aZ=CA=0C= =D3=CE?=C3=B4=F4=19=A6=AD<=C3=B4=8A3L[a=86i5f=98=B6=F2=0C=D3=CE3=C3=B4=B4= =19&d=C3=C3=84=892Y=880=AD=AF=00=86=B2@=13=BC<(=12=E6d=AA=0C=C2,=8A=99&L,4J= =98H4=1D=C2=14d=8A=10&e=86i)3L=9B=D3=CA=B6=94=19&W=8A=8C0=B9RD=84=C9=95""L= =BA=14=9C0=D9R=04=84I=97=82=13&] N=98l)=02=C2=A4K=C1 =93,EB=98t)=C5=95-I=98=94=19=A6=9D=7F=86i=E93L[y=86i=15= g=98=B6=C2=0C=D3j=CC0m=E5=19=A6=9Dg=86ii3L=C8=86G=08=13d=B2 a=0E=15=C0P=14= =C8=A5y=B9m=F4=08s:=95=9C0=CBb& =13=0C=0D=12&=14M=850%=99=C2=84=E9(3LG=99a= =BA=9CV=B6=A3=CC0=B9RD=84I=96"!L=B2=14 a=F2=A5=C0=84I=97=82=13&_ L=98|)0a=D2=A5=E0=84=C9=97=02=13&[=8A=800=F9R=8A+[=8A0=1De=86=E9=E6=9Fa:=FA= =0C=D3U=9Ea:=C5=19=A6=AB0=C3t=1A3LWy=86=E9=E6=99a:=DA=0C=13=B2=E1a=C2D=99,D= =98=CEW=00CY=A04/=B7F=910'Se=10fQ=CC4ab=A1Q=C2D=A2=E9=10=A6 S=840)3LG=99a= =BA=9CV=B6=A3=CC0=B9Rd=84=C9=95""L=AE=14=11a=D2=A5=E0=84=C9=96" L=BA=14=9C0= =E9Rp=C2dK=11=10&] N=98d)=12=C2=A4K)=AElI=C2=A4=CC0=DD=FC3LG=9Fa=BA=CA3L=A78=C3t=15f=98Nc=86= =E9*=CF0=DD<3L=C8,G8=10$=A7 =07=D2F=A7~=82N=AD=1E=CFM=A7=92=F3\Y=CC$=CF=81= =A1A=9E=83=A2=A9=F0=9C$S=98=E7<eb=E8)=13C=9F=D38=F6=94=89!W=8A=88=E7=C8R$<G= =96"=E19=BE=14=98=E7=E8Rp=9E=E3K=81y=8E/=05=E69=BA=14=9C=E7=F8R`=9EcK=11=F0= =1C_JqeK=F1=9C=A7L=0C=FD=FC=13CO=9F=18=FA=CA=13C=AF81=F4=15&=86^cb=E8+O=0C= =FD<=13C=C8,=87y=0E%=A7=10=CFy_=9B=E76=AB=ED=BB=DD=D5=F8=FD=FC=F9=C3=CDf=F7= =F7=AB1=C6=AF=1F=B6=D7=87c=B1=BA=DA=8Cg=E4=E2=E6b5=FE=EB=E8=ABp]=E4m9=FC=EB= =8F`=C7=8B=BF=AF=C6=D7=8F=E2=DE=8E;=EA0=0B=DD=EEW=87=E1=E1=F5=93=9B=D5=F5/= =D7=E3=158=C2=CB=D5=C5=F5=CF_E=1F=92=D1ov=EF=DF=1F=14=FD=13=11bZ$=A9=0F=02= =00=A5=C0<=C7=96"=E09=BE=94=EC=CA=16=E39O=99=18=FA=E9'=86=9E>1=F4=85'=86^qb= =E8=0BL=0C=BD=C6=C4=D0=17=9E=18=FAi&=86=90Y=1E=E69=94=9C=86x=CE=FB=D2<=B7^n= =AE=B77=FD=F7=F3=C7=BB=DB=F5=F6=D7=9B>=C6=CFw=9B=FD=E1X,o=D6=FD=19=B9=BC=BD= \=F6=7F=9B=7F=12=AE =BC-=87=BF=FD=11=ECd=F6=EB=B2=7F}/=EEM=BF=A3=0E=B3=D0= =CDny=18=1E=EE=8Fo=97=FB=9F=F6=FD=15=D8=C3=CB=CD=E5=FE=C7O=A2w=D1=E8=B7=DB= =B7o=0F=8A=FE=1F=FA=AF=82=96=7F=10=02=00 --UugvWAfsgieZRqgk--

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 28 Jul '11

28 Jul '11

ml+openldap(a)esmtp.org wrote: > The full log for one failed retry is: I think we need to see more of the log than this. The only reason for your observed behavior to occur is that somewhere along the line, a step in the replication actually returned LDAP_SUCCESS, which resets the retry counter. So we need to see the complete log for at least one full cycle of "(4 retries left)", "(3 retries left)", "(4 retries left)". > conn=1004 op=0 BIND dn="cn=manager" method=128 > conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 > conn=1004 op=0 RESULT tag=97 err=0 text= > conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" > conn=1004 op=1 SRCH attr=* + > srs csn 20110722201233.471069Z#000000#001#000000 > log csn 20110722201233.471069Z#000000#001#000000 > cmp 0, too old > log csn 20110722201252.820971Z#000000#001#000000 > Entry uid=user68,ou=People,dc=example,dc=com CSN > 20110722201233.471069Z#000000#001#000000 > older or equal to ctx 20110722201233.471069Z#000000#001#000000 > syncprov_search_response: > cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 > syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 > conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) > syncrepl_entry: rid=001 be_search (52) > syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com > null_callback : error code 0x34 > syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) > syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed > (52) > do_syncrepl: rid=001 rc 52 retrying (4 retries left) > conn=1004 op=2 UNBIND > conn=1004 fd=15 closed > connection_read(15): no connection! > connection_read(15): no connection! > > -- -- 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#7002) Patch - Mozilla NSS - if client cert is bad, VerifyCert allow should warn and try should fail
by hyc＠symas.com 28 Jul '11

28 Jul '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-if-client-cert-is-ba… > Submission from: (NULL) (76.113.106.30) > > > If the olcTLSVerifyClient is set to a value other than "never", the server > should request that the client send a client certificate for possible use with > client cert auth (e.g. SASL/EXTERNAL). > If set to "allow", if the client sends a cert, and there are problems with it, > the server will warn about problems, but will allow the SSL session to proceed > without a client cert. > If set to "try", if the client sends a cert, and there are problems with it, the > server will warn about those problems, and shutdown the SSL session. > If set to "demand" or "hard", the client must send a cert, and the server will > shutdown the SSL session if there are problems. > I added a new member of the tlsm context structure - tc_warn_only - if this is > set, tlsm_verify_cert will only warn about errors, and only if TRACE level debug > is set. This allows the server to warn but allow bad certs if "allow" is set, > and warn and fail if "try" is set. > > Note: The patch applies on top of ITS#7001 - you cannot apply this patch first, > then the patch to 7001 This patch does not apply cleanly to git master. Please remember the devel guidelines - all submissions must be relative to git master. I've cleaned up the rejected parts of this patch so you don't need to resubmit this one. -- -- 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#6996) Bad cn=config quotes in Admin Guide
by hyc＠symas.com 28 Jul '11

28 Jul '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: master, 2.4.26 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > http://www.openldap.org/doc/admin24/slapdconf2.html > contains a number of examples with quoted DNs in cn=config attributes: > olcSuffix, olcRootDN. This is wrong, likely a cut&paste from slapd.conf. There's nothing wrong here, the config parser accepts quotes for these attributes. -- -- 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#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by masarati＠aero.polimi.it 27 Jul '11

27 Jul '11

> Full_Name: Clément OUDOT > Version: 2.4.26 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (90.9.0.93) > > > I have a piece of code that does this singel modify operation on OpenLDAP: > * remove pwdPolicySubentry value > * replace userPassword value > > My password policy has pwdCheckQuality set to 2 (strict checking). My new > userPassword value is {SASL}bob(a)example.com. But the modify operation > failed > with: > > conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality > checking > policy > > > I was thinking than removing the pwdPolicySubentry was sufficient to > disable all > ppolicy constraint on the userPassword replacement in the same modify > operation. > Am I wrong or do I face a ppolicy overlay bug? I think this question should be directed to openldap-technical, as it is a usage question. In detail, I think the behavior of slapd and slapo-ppolicy(5) is correct, because pwdPolicySubentry was present when the operation initiated, and thus the behavior of slapo-ppolicy(5) needs to be based on the entry's content when the operation was initiated. I also think this may represent a possible field of application of the "relax" control, although neither draft-zeilenga-ldap-relax nor draft-behera-ldap-password-policy document it. Something like the relax control would allow to change a password despite the password policy, as soon as the final result complies with the protocol, including extensions. This would mean that slapo-ppolicy(5) constraints would eventually be evaluated for the entry as it results from the operation. But I think I've gone too far in discussing a usage question on the ITS. p.

1 0

(ITS#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by clem.oudot＠gmail.com 27 Jul '11

27 Jul '11

Full_Name: Clément OUDOT Version: 2.4.26 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.9.0.93) I have a piece of code that does this singel modify operation on OpenLDAP: * remove pwdPolicySubentry value * replace userPassword value My password policy has pwdCheckQuality set to 2 (strict checking). My new userPassword value is {SASL}bob(a)example.com. But the modify operation failed with: conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality checking policy I was thinking than removing the pwdPolicySubentry was sufficient to disable all ppolicy constraint on the userPassword replacement in the same modify operation. Am I wrong or do I face a ppolicy overlay bug?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs