(ITS#7014) TLS: certificate hostnames are being checked when TLS_REQCERT is se to allow
by jvcelak＠redhat.com
Full_Name: Jan Vcelak
Version: master
OS: Linux
URL: http://jvcelak.fedorapeople.org/openldap/0001-TLS-do-not-check-hostname-w...
Submission from: (NULL) (209.132.186.34)
Hello.
If server certificate hostname does not match the server hostname, connection is
closed even if client has set TLS_REQCERT to 'allow'. This is wrong - the
documentation says, that bad certificates are being ignored when TLS_REQCERT is
set to 'allow'. (Other certificate failures (like invalid CA) are handled as
expected - at least with MozNSS.)
I'm attaching patch, which fixes this behavior. The patch applies on master
branch. (OpenLDAP FTP server for incoming patches reports 'No space left on
device.', that's why I uploaded the patch to fedorapeople.org.)
Regards,
Jan
11 years, 9 months
- 1
- 0
Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu
--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc(a)symas.com> wrote:
> Sounds like this may be related to ITS#6817. Please try adding a
> dummy binddn to your idassert-bind directive and re-test.
And, at Quanah's prompting I tried it with an empty empty binddn and
got similar results. Still a failure, sometimes after returning 1000
entries, sometimes after returning 2000 entries.
Bill
--
Bill MacAllister
Infrastructure Delivery Group, Stanford University
11 years, 9 months
- 1
- 0
Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu
--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc(a)symas.com> wrote:
> 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.
I modified the configuration to include:
idassert-bind bindmethod=SASL
saslmech=GSSAPI
mode=none
binddn=cn=auth
I am stilling getting the invalid-cookie error.
% ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost "(&(objectclass=suPerson)(suVisibIdentity=world))" ou telephonenumber title
...lots of entries...
# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MA0CAQAECGIdAAAAAAAA
pagedresults: cookie=Yh0AAAAAAAA=
# 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: 3
result: 2 Protocol error
text: paged results cookie is invalid
# numResponses: 1002
# numEntries: 1000
Bill
--
Bill MacAllister
Infrastructure Delivery Group, Stanford University
11 years, 9 months
- 1
- 0
(ITS#7013) OpenLDAP freezes and doesn't respond
by cgrosjean＠janua.fr
Full_Name: Cyril Grosjean
Version: 2.4.26
OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.66.198.206)
My OpenLDAP server freezes, after a few requests, and I can't understand why.
I have a few LDAP clients (ldapsearch, a custom Java app. and
ApacheDirectoryStudio), running from different systems, either locally on the
OpenLDAP server, or on another OpenLDAP server, or on a remote workstation, and
none manages to get an answer from OpenLDAP. The connection is established but
each client gets stuck waiting for any result.
We can reproduce the freeze, after a few requests coming from the custom Java
application. The problem doesn't occur if we don't use that application.
The last time, it occured only a few minutes after the OpenLDAP daemon was
restarted, under very low load.
I use OpenLDAP 2.4.26, over Red Hat Enterprise Linux Server release 5.4
(Tikanga), Kernel version 2.6.18-164.el5, amd64 architecture over VMWare.
I also use BDB 4.8.30, and OpenLDAP's been compiled with the following options:
./configure --prefix=/opt/openldap-2.4.26 --enable-dynamic=yes
--enable-dynlist=yes --enable-memberof=yes --enable-ppolicy=yes
--enable-accesslog=yes --enable-sssvlv=yes
I noticed only 60 to 70 established connections on port 389 (according to
netstat) when the freeze occurs.
The OpenLDAP server is set in syncrepl mirror mode replication, and the other
OpenLDAP server (only used as a hot stand-by) works fine (but doesn't receive
any load). However, one can reproduce the problem with replication disabled.
In the OpenLDAP accesslog, I usually see the client requests, but no lines for
the responses.
Also, I noticed sometimes the "deferring operation: binding" message :
Jul 12 10:20:05 dev-ldap1 slapd[28525]: connection_input: conn=3377 deferring
operation: binding
Jul 12 10:20:07 dev-ldap1 slapd[28525]: conn=3378 fd=66 ACCEPT from
IP=......:3823 (IP=0.0.0.0:389)
I don't know if this message is linked or not to the main problem so I'd like to
know if this message is harmless or not, and I mention it here just in case it
could help.
Below is a full backtrace of the slapd process when it freezes. We can reproduce
the problem easily
[root@rhvtq ldap-master1]# gdb
GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
(gdb) bt full
No stack.
(gdb) attach 20884
Attaching to process 20884
Reading symbols from /opt/openldap-2.4.26/libexec/slapd...done.
Reading symbols from /opt/openldap-2.4.26/lib/libldap_r-2.4.so.2...done.
Loaded symbols for /opt/openldap-2.4.26/lib/libldap_r-2.4.so.2
Reading symbols from /opt/openldap-2.4.26/lib/liblber-2.4.so.2...done.
Loaded symbols for /opt/openldap-2.4.26/lib/liblber-2.4.so.2
Reading symbols from /lib64/libuuid.so.1...done.
Loaded symbols for /lib64/libuuid.so.1
Reading symbols from /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so...done.
Loaded symbols for /usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
Reading symbols from /lib64/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x2b1c9a53dbd0 (LWP 20884)]
[New Thread 0x48a36940 (LWP 21499)]
[New Thread 0x40930940 (LWP 21498)]
[New Thread 0x48235940 (LWP 21203)]
[New Thread 0x47a34940 (LWP 21202)]
[New Thread 0x47233940 (LWP 21201)]
[New Thread 0x46a32940 (LWP 21200)]
[New Thread 0x46231940 (LWP 21087)]
[New Thread 0x45a30940 (LWP 21086)]
[New Thread 0x4522f940 (LWP 21021)]
[New Thread 0x44a2e940 (LWP 21020)]
[New Thread 0x4422d940 (LWP 20891)]
[New Thread 0x43a2c940 (LWP 20890)]
[New Thread 0x4322b940 (LWP 20889)]
[New Thread 0x42a2a940 (LWP 20888)]
[New Thread 0x42229940 (LWP 20887)]
[New Thread 0x41a28940 (LWP 20886)]
[New Thread 0x41227940 (LWP 20885)]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /usr/lib64/libsasl2.so.2...done.
Loaded symbols for /usr/lib64/libsasl2.so.2
Reading symbols from /lib64/libssl.so.6...done.
Loaded symbols for /lib64/libssl.so.6
Reading symbols from /lib64/libcrypto.so.6...done.
Loaded symbols for /lib64/libcrypto.so.6
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /usr/lib64/libkrb5support.so.0...done.
Loaded symbols for /usr/lib64/libkrb5support.so.0
Reading symbols from /lib64/libkeyutils.so.1...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libselinux.so.1...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libsepol.so.1...done.
Loaded symbols for /lib64/libsepol.so.1
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
Reading symbols from /lib64/libnss_dns.so.2...done.
Loaded symbols for /lib64/libnss_dns.so.2
Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done.
Loaded symbols for /usr/lib64/sasl2/liblogin.so.2
Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done.
Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2
Reading symbols from /usr/lib64/sasl2/libplain.so.2...done.
Loaded symbols for /usr/lib64/sasl2/libplain.so.2
Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...done.
Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2
0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0
(gdb) bt full
#0 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x000000000042aca4 in slapd_daemon () at daemon.c:2922
i = 0
rc = 0
listener_tid = (ldap_pvt_thread_t *) 0x1ef88c60
#2 0x0000000000409f34 in main (argc=7, argv=0x7ffff62c9618) at main.c:983
i = 7
no_detach = 0
rc = -12
urls = 0x1ec6a460 "ldap://rhvtq:1389/"
username = 0x1ec6a3b0 ""
groupname = 0x0
sandbox = 0x0
syslogUser = 160
g_argc = 7
g_argv = (char **) 0x7ffff62c9618
configfile = 0x1ec6a4d0 "/opt/openldap/etc/openldap/slapd-master1.conf"
configdir = 0x0
serverName = 0x7ffff62caa62 "slapd"
serverMode = 1
scp = (struct sync_cookie *) 0x0
scp_entry = (struct sync_cookie *) 0x0
debug_unknowns = (char **) 0x0
syslog_unknowns = (char **) 0x0
serverNamePrefix = 0x55db15 ""
l = 4222019
slapd_pid_file_unlink = 1
slapd_args_file_unlink = 1
firstopt = 0
__PRETTY_FUNCTION__ = "main"
(gdb) thread apply all bt
Thread 18 (Thread 0x41227940 (LWP 20885)):
#0 0x00000031a7ad4018 in epoll_wait () from /lib64/libc.so.6
#1 0x0000000000429b23 in slapd_daemon_task (ptr=0x0) at daemon.c:2528
#2 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#3 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 17 (Thread 0x41a28940 (LWP 20886)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1101171008) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x41a26fe0, rs=0x41a27150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x41a26fe0, rs=0x41a27150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x41a26fe0, rs=0x41a27150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x41a26fe0, rs=0x41a27150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4aef00, rs=0x41a27c30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1f4aef00, rs=0x41a27c30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1f4aef00, rs=0x41a27c30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4aef00, rs=0x41a27c30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1f4aef00, rs=0x41a27c30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1f4aef00, rs=0x41a27c30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1f4aef00, rs=0x41a27c30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1f4aef00, rs=0x41a27c30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1f4aef00, rs=0x41a27c30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1f4aef00, rs=0x41a27c30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1f4aef00, rs=0x41a27c30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1f4aef00, rs=0x41a27c30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x41a27d70,
arg_v=0x1f4aef00) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x41a27d70, argv=0x69) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 16 (Thread 0x42229940 (LWP 20887)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1109563712) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x42227fe0, rs=0x42228150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x42227fe0, rs=0x42228150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x42227fe0, rs=0x42228150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x42227fe0, rs=0x42228150) at
backover.c:762
---Type <return> to continue, or q <return> to quit---
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4b2aa0, rs=0x42228c30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1f4b2aa0, rs=0x42228c30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1f4b2aa0, rs=0x42228c30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4b2aa0, rs=0x42228c30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1f4b2aa0, rs=0x42228c30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1f4b2aa0, rs=0x42228c30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1f4b2aa0, rs=0x42228c30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1f4b2aa0, rs=0x42228c30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1f4b2aa0, rs=0x42228c30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1f4b2aa0, rs=0x42228c30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x42228d70,
arg_v=0x1f4b2aa0) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x42228d70, argv=0x61) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 15 (Thread 0x42a2a940 (LWP 20888)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#3 0x00002b1c9a280b49 in __lock_get_internal () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#4 0x00002b1c9a2812c2 in __lock_get_pp () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30,
txn=0x1f4ae470, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x428a8460) at cache.c:234
#6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f4b09e0, tid=0x1f4ae470,
id=1968, eip=0x428a8490, flag=0, lock=0x428a8460) at cache.c:988
#7 0x00000000004e15e7 in hdb_search (op=0x1f4b09e0, rs=0x42a29c30) at
search.c:737
#8 0x00000000004bbbba in overlay_op_walk (op=0x1f4b09e0, rs=0x42a29c30,
which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671
#9 0x00000000004bbdbd in over_op_func (op=0x1f4b09e0, rs=0x42a29c30,
which=op_search) at backover.c:723
#10 0x00000000004bbe8b in over_op_search (op=0x1f4b09e0, rs=0x42a29c30) at
backover.c:750
#11 0x00000000004318b4 in fe_op_search (op=0x1f4b09e0, rs=0x42a29c30) at
search.c:402
#12 0x00000000004bbbba in overlay_op_walk (op=0x1f4b09e0, rs=0x42a29c30,
which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671
#13 0x00000000004bbdbd in over_op_func (op=0x1f4b09e0, rs=0x42a29c30,
which=op_search) at backover.c:723
#14 0x00000000004bbe8b in over_op_search (op=0x1f4b09e0, rs=0x42a29c30) at
backover.c:750
#15 0x0000000000431193 in do_search (op=0x1f4b09e0, rs=0x42a29c30) at
search.c:247
#16 0x000000000042dbce in connection_operation (ctx=0x42a29d70,
arg_v=0x1f4b09e0) at connection.c:1138
#17 0x000000000042e153 in connection_read_thread (ctx=0x42a29d70, argv=0x55) at
connection.c:1274
#18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 14 (Thread 0x4322b940 (LWP 20889)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1126349120) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x43229fe0, rs=0x4322a150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x43229fe0, rs=0x4322a150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x43229fe0, rs=0x4322a150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x43229fe0, rs=0x4322a150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1f1a3d80, rs=0x4322ac30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1f1a3d80, rs=0x4322ac30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1f1a3d80, rs=0x4322ac30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f1a3d80, rs=0x4322ac30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1f1a3d80, rs=0x4322ac30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1f1a3d80, rs=0x4322ac30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1f1a3d80, rs=0x4322ac30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1f1a3d80, rs=0x4322ac30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1f1a3d80, rs=0x4322ac30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1f1a3d80, rs=0x4322ac30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x4322ad70,
arg_v=0x1f1a3d80) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x4322ad70, argv=0x31) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 13 (Thread 0x43a2c940 (LWP 20890)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#3 0x00002b1c9a280b49 in __lock_get_internal () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#4 0x00002b1c9a2812c2 in __lock_get_pp () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30,
txn=0x1f4b3740, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x438aa460) at cache.c:234
#6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f2ac080, tid=0x1f4b3740,
id=1968, eip=0x438aa490, flag=0, lock=0x438aa460) at cache.c:988
#7 0x00000000004e15e7 in hdb_search (op=0x1f2ac080, rs=0x43a2bc30) at
search.c:737
#8 0x00000000004bbbba in overlay_op_walk (op=0x1f2ac080, rs=0x43a2bc30,
which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671
#9 0x00000000004bbdbd in over_op_func (op=0x1f2ac080, rs=0x43a2bc30,
which=op_search) at backover.c:723
#10 0x00000000004bbe8b in over_op_search (op=0x1f2ac080, rs=0x43a2bc30) at
backover.c:750
---Type <return> to continue, or q <return> to quit---
#11 0x00000000004318b4 in fe_op_search (op=0x1f2ac080, rs=0x43a2bc30) at
search.c:402
#12 0x00000000004bbbba in overlay_op_walk (op=0x1f2ac080, rs=0x43a2bc30,
which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671
#13 0x00000000004bbdbd in over_op_func (op=0x1f2ac080, rs=0x43a2bc30,
which=op_search) at backover.c:723
#14 0x00000000004bbe8b in over_op_search (op=0x1f2ac080, rs=0x43a2bc30) at
backover.c:750
#15 0x0000000000431193 in do_search (op=0x1f2ac080, rs=0x43a2bc30) at
search.c:247
#16 0x000000000042dbce in connection_operation (ctx=0x43a2bd70,
arg_v=0x1f2ac080) at connection.c:1138
#17 0x000000000042e153 in connection_read_thread (ctx=0x43a2bd70, argv=0x57) at
connection.c:1274
#18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 12 (Thread 0x4422d940 (LWP 20891)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1143134528) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x4422bfe0, rs=0x4422c150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x4422bfe0, rs=0x4422c150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x4422bfe0, rs=0x4422c150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x4422bfe0, rs=0x4422c150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1f3ac600, rs=0x4422cc30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1f3ac600, rs=0x4422cc30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1f3ac600, rs=0x4422cc30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f3ac600, rs=0x4422cc30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1f3ac600, rs=0x4422cc30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1f3ac600, rs=0x4422cc30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1f3ac600, rs=0x4422cc30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1f3ac600, rs=0x4422cc30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1f3ac600, rs=0x4422cc30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1f3ac600, rs=0x4422cc30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1f3ac600, rs=0x4422cc30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1f3ac600, rs=0x4422cc30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x4422cd70,
arg_v=0x1f3ac600) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x4422cd70, argv=0x62) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 11 (Thread 0x44a2e940 (LWP 21020)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
---Type <return> to continue, or q <return> to quit---
#2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#3 0x00002b1c9a280b49 in __lock_get_internal () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#4 0x00002b1c9a2812c2 in __lock_get_pp () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30,
txn=0x1fc7ade0, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x448ac460) at cache.c:234
#6 0x0000000000510f4b in hdb_cache_find_id (op=0x1f5bf860, tid=0x1fc7ade0,
id=1968, eip=0x448ac490, flag=0, lock=0x448ac460) at cache.c:988
#7 0x00000000004e15e7 in hdb_search (op=0x1f5bf860, rs=0x44a2dc30) at
search.c:737
#8 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf860, rs=0x44a2dc30,
which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671
#9 0x00000000004bbdbd in over_op_func (op=0x1f5bf860, rs=0x44a2dc30,
which=op_search) at backover.c:723
#10 0x00000000004bbe8b in over_op_search (op=0x1f5bf860, rs=0x44a2dc30) at
backover.c:750
#11 0x00000000004318b4 in fe_op_search (op=0x1f5bf860, rs=0x44a2dc30) at
search.c:402
#12 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf860, rs=0x44a2dc30,
which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671
#13 0x00000000004bbdbd in over_op_func (op=0x1f5bf860, rs=0x44a2dc30,
which=op_search) at backover.c:723
#14 0x00000000004bbe8b in over_op_search (op=0x1f5bf860, rs=0x44a2dc30) at
backover.c:750
#15 0x0000000000431193 in do_search (op=0x1f5bf860, rs=0x44a2dc30) at
search.c:247
#16 0x000000000042dbce in connection_operation (ctx=0x44a2dd70,
arg_v=0x1f5bf860) at connection.c:1138
#17 0x000000000042e153 in connection_read_thread (ctx=0x44a2dd70, argv=0x68) at
connection.c:1274
#18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 10 (Thread 0x4522f940 (LWP 21021)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#3 0x00002b1c9a280b49 in __lock_get_internal () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#4 0x00002b1c9a2812c2 in __lock_get_pp () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30,
txn=0x1fcfb000, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x450ad460) at cache.c:234
#6 0x0000000000510f4b in hdb_cache_find_id (op=0x20012790, tid=0x1fcfb000,
id=1968, eip=0x450ad490, flag=0, lock=0x450ad460) at cache.c:988
#7 0x00000000004e15e7 in hdb_search (op=0x20012790, rs=0x4522ec30) at
search.c:737
#8 0x00000000004bbbba in overlay_op_walk (op=0x20012790, rs=0x4522ec30,
which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671
#9 0x00000000004bbdbd in over_op_func (op=0x20012790, rs=0x4522ec30,
which=op_search) at backover.c:723
#10 0x00000000004bbe8b in over_op_search (op=0x20012790, rs=0x4522ec30) at
backover.c:750
#11 0x00000000004318b4 in fe_op_search (op=0x20012790, rs=0x4522ec30) at
search.c:402
#12 0x00000000004bbbba in overlay_op_walk (op=0x20012790, rs=0x4522ec30,
which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671
#13 0x00000000004bbdbd in over_op_func (op=0x20012790, rs=0x4522ec30,
which=op_search) at backover.c:723
#14 0x00000000004bbe8b in over_op_search (op=0x20012790, rs=0x4522ec30) at
backover.c:750
#15 0x0000000000431193 in do_search (op=0x20012790, rs=0x4522ec30) at
search.c:247
#16 0x000000000042dbce in connection_operation (ctx=0x4522ed70,
arg_v=0x20012790) at connection.c:1138
#17 0x000000000042e153 in connection_read_thread (ctx=0x4522ed70, argv=0x5f) at
connection.c:1274
#18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
---Type <return> to continue, or q <return> to quit---
#19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 9 (Thread 0x45a30940 (LWP 21086)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#3 0x00002b1c9a280b49 in __lock_get_internal () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#4 0x00002b1c9a2812c2 in __lock_get_pp () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30,
txn=0x2000f1d0, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x458ae460) at cache.c:234
#6 0x0000000000510f4b in hdb_cache_find_id (op=0x1fed5290, tid=0x2000f1d0,
id=1968, eip=0x458ae490, flag=0, lock=0x458ae460) at cache.c:988
#7 0x00000000004e15e7 in hdb_search (op=0x1fed5290, rs=0x45a2fc30) at
search.c:737
#8 0x00000000004bbbba in overlay_op_walk (op=0x1fed5290, rs=0x45a2fc30,
which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671
#9 0x00000000004bbdbd in over_op_func (op=0x1fed5290, rs=0x45a2fc30,
which=op_search) at backover.c:723
#10 0x00000000004bbe8b in over_op_search (op=0x1fed5290, rs=0x45a2fc30) at
backover.c:750
#11 0x00000000004318b4 in fe_op_search (op=0x1fed5290, rs=0x45a2fc30) at
search.c:402
#12 0x00000000004bbbba in overlay_op_walk (op=0x1fed5290, rs=0x45a2fc30,
which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671
#13 0x00000000004bbdbd in over_op_func (op=0x1fed5290, rs=0x45a2fc30,
which=op_search) at backover.c:723
#14 0x00000000004bbe8b in over_op_search (op=0x1fed5290, rs=0x45a2fc30) at
backover.c:750
#15 0x0000000000431193 in do_search (op=0x1fed5290, rs=0x45a2fc30) at
search.c:247
#16 0x000000000042dbce in connection_operation (ctx=0x45a2fd70,
arg_v=0x1fed5290) at connection.c:1138
#17 0x000000000042e153 in connection_read_thread (ctx=0x45a2fd70, argv=0x60) at
connection.c:1274
#18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 8 (Thread 0x46231940 (LWP 21087)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#3 0x00002b1c9a280b49 in __lock_get_internal () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#4 0x00002b1c9a2814ea in __lock_vec () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#5 0x00002b1c9a28212b in __lock_vec_pp () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#6 0x000000000050f6fe in hdb_cache_entry_db_relock (bdb=0x1ed02f30,
txn=0x207ff300, ei=0x1fe43b10, rw=1, tryOnly=0, lock=0x4622f180) at cache.c:198
#7 0x0000000000511817 in hdb_cache_modify (bdb=0x1ed02f30, e=0x1ee1ed68,
newAttrs=0x201b6b30, txn=0x207ff300, lock=0x4622f180) at cache.c:1231
#8 0x00000000004da9ce in hdb_modify (op=0x20011d70, rs=0x46230c30) at
modify.c:662
#9 0x00000000004bbbba in overlay_op_walk (op=0x20011d70, rs=0x46230c30,
which=op_modify, oi=0x1ed31f10, on=0x0) at backover.c:671
#10 0x00000000004bbdbd in over_op_func (op=0x20011d70, rs=0x46230c30,
which=op_modify) at backover.c:723
#11 0x00000000004bbed3 in over_op_modify (op=0x20011d70, rs=0x46230c30) at
backover.c:762
#12 0x000000000044dfd7 in fe_op_modify (op=0x20011d70, rs=0x46230c30) at
modify.c:303
---Type <return> to continue, or q <return> to quit---
#13 0x00000000004bbbba in overlay_op_walk (op=0x20011d70, rs=0x46230c30,
which=op_modify, oi=0x1ed02760, on=0x0) at backover.c:671
#14 0x00000000004bbdbd in over_op_func (op=0x20011d70, rs=0x46230c30,
which=op_modify) at backover.c:723
#15 0x00000000004bbed3 in over_op_modify (op=0x20011d70, rs=0x46230c30) at
backover.c:762
#16 0x000000000044d8e5 in do_modify (op=0x20011d70, rs=0x46230c30) at
modify.c:177
#17 0x000000000042dbce in connection_operation (ctx=0x46230d70,
arg_v=0x20011d70) at connection.c:1138
#18 0x000000000042e153 in connection_read_thread (ctx=0x46230d70, argv=0x66) at
connection.c:1274
#19 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#20 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#21 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 7 (Thread 0x46a32940 (LWP 21200)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1185098048) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x46a30fe0, rs=0x46a31150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x46a30fe0, rs=0x46a31150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x46a30fe0, rs=0x46a31150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x46a30fe0, rs=0x46a31150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1f4acf50, rs=0x46a31c30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1f4acf50, rs=0x46a31c30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1f4acf50, rs=0x46a31c30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f4acf50, rs=0x46a31c30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1f4acf50, rs=0x46a31c30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1f4acf50, rs=0x46a31c30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1f4acf50, rs=0x46a31c30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1f4acf50, rs=0x46a31c30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1f4acf50, rs=0x46a31c30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1f4acf50, rs=0x46a31c30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1f4acf50, rs=0x46a31c30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1f4acf50, rs=0x46a31c30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x46a31d70,
arg_v=0x1f4acf50) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x46a31d70, argv=0x63) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x47233940 (LWP 21201)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c9a1f0dd2 in __db_pthread_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#2 0x00002b1c9a1f0426 in __db_tas_mutex_lock () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
---Type <return> to continue, or q <return> to quit---
#3 0x00002b1c9a280b49 in __lock_get_internal () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#4 0x00002b1c9a2812c2 in __lock_get_pp () from
/usr/local/BerkeleyDB.4.8/lib/libdb-4.8.so
#5 0x000000000050f89e in bdb_cache_entry_db_lock (bdb=0x1ed02f30,
txn=0x1fbf4800, ei=0x1fe43b10, rw=0, tryOnly=0, lock=0x470b1460) at cache.c:234
#6 0x0000000000510f4b in hdb_cache_find_id (op=0x1fbf6de0, tid=0x1fbf4800,
id=1968, eip=0x470b1490, flag=0, lock=0x470b1460) at cache.c:988
#7 0x00000000004e15e7 in hdb_search (op=0x1fbf6de0, rs=0x47232c30) at
search.c:737
#8 0x00000000004bbbba in overlay_op_walk (op=0x1fbf6de0, rs=0x47232c30,
which=op_search, oi=0x1ed31f10, on=0x0) at backover.c:671
#9 0x00000000004bbdbd in over_op_func (op=0x1fbf6de0, rs=0x47232c30,
which=op_search) at backover.c:723
#10 0x00000000004bbe8b in over_op_search (op=0x1fbf6de0, rs=0x47232c30) at
backover.c:750
#11 0x00000000004318b4 in fe_op_search (op=0x1fbf6de0, rs=0x47232c30) at
search.c:402
#12 0x00000000004bbbba in overlay_op_walk (op=0x1fbf6de0, rs=0x47232c30,
which=op_search, oi=0x1ed02760, on=0x0) at backover.c:671
#13 0x00000000004bbdbd in over_op_func (op=0x1fbf6de0, rs=0x47232c30,
which=op_search) at backover.c:723
#14 0x00000000004bbe8b in over_op_search (op=0x1fbf6de0, rs=0x47232c30) at
backover.c:750
#15 0x0000000000431193 in do_search (op=0x1fbf6de0, rs=0x47232c30) at
search.c:247
#16 0x000000000042dbce in connection_operation (ctx=0x47232d70,
arg_v=0x1fbf6de0) at connection.c:1138
#17 0x000000000042e153 in connection_read_thread (ctx=0x47232d70, argv=0x67) at
connection.c:1274
#18 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#19 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#20 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x47a34940 (LWP 21202)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1201883456) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x47a32fe0, rs=0x47a33150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x47a32fe0, rs=0x47a33150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x47a32fe0, rs=0x47a33150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x47a32fe0, rs=0x47a33150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1fe6e000, rs=0x47a33c30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1fe6e000, rs=0x47a33c30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1fe6e000, rs=0x47a33c30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fe6e000, rs=0x47a33c30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1fe6e000, rs=0x47a33c30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1fe6e000, rs=0x47a33c30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1fe6e000, rs=0x47a33c30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1fe6e000, rs=0x47a33c30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1fe6e000, rs=0x47a33c30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1fe6e000, rs=0x47a33c30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1fe6e000, rs=0x47a33c30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1fe6e000, rs=0x47a33c30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x47a33d70,
arg_v=0x1fe6e000) at connection.c:1138
---Type <return> to continue, or q <return> to quit---
#20 0x000000000042e153 in connection_read_thread (ctx=0x47a33d70, argv=0x6a) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x48235940 (LWP 21203)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1210276160) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x48233fe0, rs=0x48234150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x48233fe0, rs=0x48234150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x48233fe0, rs=0x48234150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x48233fe0, rs=0x48234150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1fe91140, rs=0x48234c30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1fe91140, rs=0x48234c30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1fe91140, rs=0x48234c30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fe91140, rs=0x48234c30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1fe91140, rs=0x48234c30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1fe91140, rs=0x48234c30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1fe91140, rs=0x48234c30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1fe91140, rs=0x48234c30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1fe91140, rs=0x48234c30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1fe91140, rs=0x48234c30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1fe91140, rs=0x48234c30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1fe91140, rs=0x48234c30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x48234d70,
arg_v=0x1fe91140) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x48234d70, argv=0x64) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x40930940 (LWP 21498)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1083377984) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x4092efe0, rs=0x4092f150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x4092efe0, rs=0x4092f150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x4092efe0, rs=0x4092f150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x4092efe0, rs=0x4092f150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1f5bf360, rs=0x4092fc30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1f5bf360, rs=0x4092fc30) at
result.c:505
---Type <return> to continue, or q <return> to quit---
#8 0x0000000000443c2f in send_ldap_response (op=0x1f5bf360, rs=0x4092fc30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1f5bf360, rs=0x4092fc30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf360, rs=0x4092fc30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1f5bf360, rs=0x4092fc30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1f5bf360, rs=0x4092fc30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1f5bf360, rs=0x4092fc30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1f5bf360, rs=0x4092fc30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1f5bf360, rs=0x4092fc30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1f5bf360, rs=0x4092fc30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1f5bf360, rs=0x4092fc30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x4092fd70,
arg_v=0x1f5bf360) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x4092fd70, argv=0x25) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x48a36940 (LWP 21499)):
#0 0x00000031a860ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00002b1c99d65f1b in ldap_pvt_thread_rmutex_lock (rmutex=<value optimized
out>, owner=1218668864) at rmutex.c:129
#2 0x000000000052efb7 in accesslog_op_mod (op=0x48a34fe0, rs=0x48a35150) at
accesslog.c:1889
#3 0x00000000004bbb2b in overlay_op_walk (op=0x48a34fe0, rs=0x48a35150,
which=op_modify, oi=0x1ed31f10, on=0x1ed32d60) at backover.c:661
#4 0x00000000004bbdbd in over_op_func (op=0x48a34fe0, rs=0x48a35150,
which=op_modify) at backover.c:723
#5 0x00000000004bbed3 in over_op_modify (op=0x48a34fe0, rs=0x48a35150) at
backover.c:762
#6 0x000000000053c7af in ppolicy_bind_response (op=0x1fbf8d90, rs=0x48a35c30)
at ppolicy.c:1173
#7 0x0000000000443a08 in slap_response_play (op=0x1fbf8d90, rs=0x48a35c30) at
result.c:505
#8 0x0000000000443c2f in send_ldap_response (op=0x1fbf8d90, rs=0x48a35c30) at
result.c:579
#9 0x0000000000444b14 in slap_send_ldap_result (op=0x1fbf8d90, rs=0x48a35c30)
at result.c:851
#10 0x000000000050f2f3 in hdb_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:158
#11 0x00000000004bbbba in overlay_op_walk (op=0x1fbf8d90, rs=0x48a35c30,
which=op_bind, oi=0x1ed31f10, on=0x0) at backover.c:671
#12 0x00000000004bbdbd in over_op_func (op=0x1fbf8d90, rs=0x48a35c30,
which=op_bind) at backover.c:723
#13 0x00000000004bbe43 in over_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at
backover.c:738
#14 0x0000000000456411 in fe_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at
bind.c:383
#15 0x00000000004bbbba in overlay_op_walk (op=0x1fbf8d90, rs=0x48a35c30,
which=op_bind, oi=0x1ed02760, on=0x0) at backover.c:671
#16 0x00000000004bbdbd in over_op_func (op=0x1fbf8d90, rs=0x48a35c30,
which=op_bind) at backover.c:723
#17 0x00000000004bbe43 in over_op_bind (op=0x1fbf8d90, rs=0x48a35c30) at
backover.c:738
#18 0x0000000000455b40 in do_bind (op=0x1fbf8d90, rs=0x48a35c30) at bind.c:205
#19 0x000000000042dbce in connection_operation (ctx=0x48a35d70,
arg_v=0x1fbf8d90) at connection.c:1138
#20 0x000000000042e153 in connection_read_thread (ctx=0x48a35d70, argv=0x30) at
connection.c:1274
#21 0x00002b1c99d66fc8 in ldap_int_thread_pool_wrapper (xpool=0x1ec9acb0) at
tpool.c:685
---Type <return> to continue, or q <return> to quit---
#22 0x00000031a86064a7 in start_thread () from /lib64/libpthread.so.0
#23 0x00000031a7ad3c2d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x2b1c9a53dbd0 (LWP 20884)):
#0 0x00000031a86077e5 in pthread_join () from /lib64/libpthread.so.0
#1 0x000000000042aca4 in slapd_daemon () at daemon.c:2922
#2 0x0000000000409f34 in main (argc=7, argv=0x7ffff62c9618) at main.c:983
I've tried to upload bulky materials to the incoming directory of
ftp.openldap.org but there was no space left to upload. My upload required
5950450 bytes only.
So, I'm waiting for free disk space on the FTP server. BTW, here's the
slapd.conf file :
###########################################################################
# Section globale: les directives definies dans cette section s'appliquent
# a tous les suffixes definis.
# Cette section se termine juste avant la premiere directive "database"
###########################################################################
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/vetoquinol.schema
# Inclusion du fichier definissant les droits d'acces globaux
# (cad s'appliquant a tous les suffixes (donnees, schema, cn=config, cn=monitor,
etc ...))
include /etc/openldap/vtq-global-access.conf
# Delai en secondes au bout duquel les connections inactives sont fermees par le
serveur
#idletimeout 600
# Allow LDAPv2 client connections. This is NOT the default.
#allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd-master1.pid
argsfile /var/run/openldap/slapd-master1.args
logfile /var/log/openldap-master1-debug.log
loglevel 256
#loglevel 8193
# Option utilisee en mode multi-maitre seulement
# La valeur doit etre differente pour chaque instance d'annuaire
serverID 1
# Load dynamic backend modules:
# modulepath /usr/lib64/openldap
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
#TLSCACertificateFile /etc/openldap/OpenSSL_ca.crt
#TLSCertificateFile /etc/openldap/OpenSSL_server.crt
#TLSCertificateKeyFile /etc/openldap/OpenSSL_server.key
#TLSCipherSuite TLSv1:SSLv3
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
# Inclusion du fichier definissant les droits d'acces pour dc=vetoquinol
authz-policy to
include /etc/openldap/vtq-access.conf
include /etc/openldap/deleted-access.conf
# Nombre maximum par defaut d'entrees renvoyees lors d'une recherche
sizelimit 2000
# Module necessaire pour pouvoir demander a OpenLDAP
# de trier les entrees renvoyees
overlay sssvlv
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
#######################################################################
# Monitoring BDB database definition #
#######################################################################
# Base (optionnelle) utilisee pour la supervision et l'obtention de
statistiques
# sur l'activite de l'annuaire
database monitor
rootdn cn=monitoring,cn=Monitor
rootpw {SSHA}pdXDKQIKBa/oYZgDeNyum8VvJ8D0yTaZ
#rootpw monitoring
database hdb
suffix "dc=vetoquinol"
rootdn "cn=Manager,dc=vetoquinol"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw *********
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
# Emplacement de la base pour le suffixe dc=vetoquinol
directory /var/lib/ldap-master1/vtq
# Indices to maintain for this database
# Index generaux
index objectclass,entryCSN,entryUUID,creatorsname,modifiersname eq
index pwdaccountlockedtime,pwdfailuretime,pwdgraceusetime,uid,uniquemember pres
index businessCategory,employeeType eq,pres
index c,cn,employeeNumber,givenName,mail,sn,telephonenumber,l,departmentnumber
eq,pres,sub
# Index specifiques VTQ
index vtq-langues,vtq-section,vtq-date-entree,vtq-date-sortie,vtq-date-mutation
eq
index vtq-activite eq,pres
index vtq-ref-fonction eq,pres,sub
# Extension pour pouvoir gerer des groupes dynamiques
# Dans l'exemple ci-dessous:
# - un groupe dynamique doit avoir la classe d'objet groupOfURLs
# - l'attribut (du groupe dynamique) memberURL doit contenir une URL LDAP,
# par exemple ldap://hostname:port/ou=people??one?(&(objectclass=vtq-personne)(c=FR))
# - l'attribut multi-valué (du groupe dynamique) uniqueMember est alors généré
dynamiquement
# et contient la liste des membres du groupe (donc une liste de DN)
# overlay dynlist
#dynlist-attrset groupOfURLs memberURL uniqueMember
# Extension pour obtenir a partir d'un utilisateur
# la liste des groupes auxquels il appartient
#memberof-memberof-ad isMemberOf
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
memberof-refint TRUE
# Definition des parametres de replication pour un annuaire maitre
# L'appel au module syncprov est necessaire pour indiquer que l'annuaire est
maitre
# Le parametrage ci-dessous indique que la derniere ecriture sur la base est
consignee
# sur disque soit tous les 100 changements, soit au bout de 2 minutes
overlay syncprov
syncprov-checkpoint 100 2
# Definition des liens de replication
# Le numero de rid doit etre different pour chaque suffixe replique
# d'une instance d'annuaire, mais identique entre les maitres et esclaves d'un
meme suffixe
# (A faire sur chaque annuaire recevant des mises a jour, qu'il soit maitre ou
esclave)
# L'etablissment de la connection au maitre peut prendre jusqu'a 5 secondes
# L'authentification aupres du maitre peut prendre jusqu'a 10 secondes
# Tous les attributs et toutes les entrees sont repliques
syncrepl rid=001
provider=ldap://rhvtq:2389
bindmethod=simple
binddn="cn=replication user,ou=special users,dc=vetoquinol"
credentials=*********
searchbase="dc=vetoquinol"
type=refreshAndPersist
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
retry="60 +"
network-timeout=5
timeout=10
schemachecking=on
attrs="*,+"
filter="(objectclass=*)"
# Activation du mode multi-maitre
mirrormode on
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 07+00:00 01+02:00
# Recherche en nombre et en temps illimitee pour le compte de replication, sur
le suffixe dc=vetoquinol
limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol"
time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
# Recherche en nombre et en temps illimitee pour le compte de synchronisation
vers AD sur le suffixe dc=vetoquinol
limits dn.exact="cn=lsc user,ou=special users,dc=vetoquinol" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# Nombre maximum d'entrees renvoyees pour le compte "cn=yellow pages" sur le
suffixe "dc=vetoquinol"
# Lors de requetes ou cn=yellow pages se fait passer pour un autre utilisateur,
# ce sont les limites de cet utilisateur qui s'appliquent
limits dn.base="cn=yellow pages,ou=special users,dc=vetoquinol" size=unlimited
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
# Emplacement de la strategie par defaut de gestion des mots de passe
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=vetoquinol"
# L'option ci-dessous permet de renvoyer un code d'erreur explicite en cas de
compte verrouille
# Ne pas activer cette option donne moins d'informations en cas d'attaque
#ppolicy_use_lockout
# Hachage automatique des mots de passe entres en clair
ppolicy_hash_cleartext
# tuning base du suffixe dc=vetoquinol
# Taille du cache des entrees
cachesize 2000
# Taille du cache pour les recherches les plus demandees
idlcachesize 6000
# Taille du cache de base de donnees
# voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_m...
# Idealement: taille du fichier id2entry.bdb (3883008 octets au 5/07/2011) +
10%
# Syntaxe: x y z ou:
# x represente la taille du cache en Go
# y represente la taille du cache en octets
# z represente le nombre de sous-regions de cache a creer
dbconfig set_cachesize 0 4400000 1
# Taille en octets du tampon memoire pour le journal des transactions
dbconfig set_lg_bsize 2097152
# Emplacement du journal des transactions
dbconfig set_lg_dir /var/lib/ldap-master1/vtq
# Rotation automatique du journal des transactions
dbconfig set_flags DB_LOG_AUTOREMOVE
# Nombre maximum de verrous sur la base
dbconfig set_lk_max_locks 10000
# Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des
verrous
dbconfig set_lk_max_lockers 10000
# Nombre maximum d'objets verrouilles
dbconfig set_lk_max_objects 10000
#######################################################################
# Deleted Entries database definition #
#######################################################################
database hdb
suffix "o=deleted entries"
rootdn "cn=Manager,o=deleted entries"
rootpw *********
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
# Emplacement de la base pour le suffixe o=deleted
directory /var/lib/ldap-master1/deleted
# Module necessaire pour pouvoir demander a OpenLDAP
# de trier les entrees renvoyees
overlay sssvlv
# Index generaux
index entryCSN,entryUUID,objectclass eq
index employeeType eq,pres
index cn,sn,employeeNumber eq,pres,sub
# Definition des parametres de replication pour un annuaire maitre
# L'appel au module syncprov est necessaire pour indiquer que l'annuaire est
maitre
# Le parametrage ci-dessous indique que la derniere ecriture sur la base est
consignee
# sur disque soit tous les 100 changements, soit au bout de 2 minutes
overlay syncprov
syncprov-checkpoint 100 2
# Definition des liens de replication
# Le numero de rid doit etre different pour chaque suffixe replique
# d'une instance d'annuaire, mais identique entre les maitres et esclaves d'un
meme suffixe
# (A faire sur chaque annuaire recevant des mises a jour, qu'il soit maitre ou
esclave)
# L'etablissment de la connection au maitre peut prendre jusqu'a 5 secondes
# L'authentification aupres du maitre peut prendre jusqu'a 10 secondes
# Tous les attributs et toutes les entrees sont repliques
syncrepl rid=002
provider=ldap://rhvtq:2389
bindmethod=simple
binddn="cn=replication user,ou=special users,dc=vetoquinol"
credentials=*********
searchbase="o=deleted entries"
type=refreshAndPersist
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
retry="60 +"
network-timeout=5
timeout=10
schemachecking=on
attrs="*,+"
filter="(objectclass=*)"
# Activation du mode multi-maitre
mirrormode on
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
logpurge 07+00:00 01+02:00
# Recherche en nombre et en temps illimitee pour le compte de replication, sur
le suffixe o=deleted entries
limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol"
time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
# Nombre maximum d'entrees renvoyees pour le compte "cn=yellow pages" sur le
suffixe "o=deleted entries"
limits dn.base="cn=yellow pages,ou=special users,dc=vetoquinol" size=unlimited
# tuning base du suffixe o=deleted entries
# Taille du cache des entrees
# Arbitrairement, on le regle a 10% de la taille du cache des entrees du suffixe
principal (dc=vetoquinol)
cachesize 200
# Taille du cache pour les recherches les plus demandees
idlcachesize 600
# Taille du cache de base de donnees
# voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_m...
# Idealement: taille du fichier id2entry.bdb + 10%
# Syntaxe: x y z ou:
# x represente la taille du cache en Go
# y represente la taille du cache en octets
# z represente le nombre de sous-regions de cache a creer
dbconfig set_cachesize 0 4400000 1
# Taille en octets du tampon memoire pour le journal des transactions
dbconfig set_lg_bsize 2097152
# Emplacement du journal des transactions
dbconfig set_lg_dir /var/lib/ldap-master1/deleted
# Rotation automatique du journal des transactions
dbconfig set_flags DB_LOG_AUTOREMOVE
# Nombre maximum de verrous sur la base
dbconfig set_lk_max_locks 10000
# Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des
verrous
dbconfig set_lk_max_lockers 10000
# Nombre maximum d'objets verrouilles
dbconfig set_lk_max_objects 10000
#######################################################################
# Accesslog HDB database definition #
#######################################################################
# Definition de la base (optionnelle) accesslog
# Cette base permet d'optimiser la replication en ne repliquant
# que la partie d'une entree qui est modifiee plutot que l'entree en entier
database hdb
suffix cn=accesslog
directory /var/lib/ldap-master1/accesslog
rootdn cn=accesslog
# Definition des index pour optimiser l'acces au suffixe cn=accesslog
# Seul un annuaire esclave accede a ce suffixe en principe pour savoir ce qui
# a ete modifie depuis la session de replication precedente
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
#Recherche en nombre et en temps illimitee pour le compte de replication, sur le
suffixe cn=accesslog
limits dn.exact="cn=replication user,ou=special users,dc=vetoquinol"
time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
# tuning base du suffixe cn=accesslog
# Taille du cache des entrees
# Arbitrairement, on le regle a 10% de la taille du cache des entrees du suffixe
principal (dc=vetoquinol)
cachesize 200
# Taille du cache pour les recherches les plus demandees
idlcachesize 600
# Taille du cache de base de donnees
# voir http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/frame_m...
# Idealement: taille du fichier id2entry.bdb + 10%
# Syntaxe: x y z ou:
# x represente la taille du cache en Go
# y represente la taille du cache en octets
# z represente le nombre de sous-regions de cache a creer
dbconfig set_cachesize 0 4400000 1
# Taille en octets du tampon memoire pour le journal des transactions
dbconfig set_lg_bsize 2097152
# Emplacement du journal des transactions
dbconfig set_lg_dir /var/lib/ldap-master1/accesslog
# Rotation automatique du journal des transactions
dbconfig set_flags DB_LOG_AUTOREMOVE
# Nombre maximum de verrous sur la base
dbconfig set_lk_max_locks 10000
# Nombre maximum d'entites (threads dans le cas d'OpenLDAP) demandant des
verrous
dbconfig set_lk_max_lockers 10000
# Nombre maximum d'objets verrouilles
dbconfig set_lk_max_objects 10000
The slapd.conf file is as follows
11 years, 9 months
- 1
- 0
(ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by ashish＠sendmail.com
Full_Name: Ashish Gawarikar
Version: 2.4.23
OS: Redhat 5.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (66.253.98.197)
In my slapd.conf file:
...
TLSCertificateFile
TLSCertificateKeyFile
...
If I have the above, I get a core dump, with the error:
slapd: ch_malloc.c:123: ch_strdup: Assertion `0' failed.
Let me know if you need the core file.
11 years, 9 months
- 1
- 0
(ITS#7011) signal 6 got in ldap_abandon
by ogermain＠tibco.com
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
11 years, 10 months
- 1
- 0
Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by hyc＠symas.com
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/
11 years, 10 months
- 1
- 0
(ITS#7010) Deadlock in Producer/Consumer Nodes
by ghola＠rebelbase.com
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!
11 years, 10 months
- 1
- 0
Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu
--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
11 years, 10 months
- 1
- 0
Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by quanah＠zimbra.com
--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
11 years, 10 months
- 1
- 0