- openldap-bugs - openldap.org

(ITS#5628) dereferencing user with translucent overlay
by kouk＠noc.uoa.gr 23 Jul '08

23 Jul '08

Full_Name: Kostantinos Koukopoulos Version: 2.4.11 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch Submission from: (NULL) (195.134.100.30) When using the translucent overlay, if one tries to use set syntax in an ACL or ACI rule, in order to dereference the bound user, like in the example below, then the user's entry is fetched from the local database only. Example <who> clause: by set="user/eduPersonOrgUnitDN & [ou=someunit,dc=someorg,dc=somecountry]" If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be found in the local database. I believe it would be better if the remote database was also checked, like when a search operation is performed against the overlay. I found the problem was due to that acl_set_gather2 tries to fetch the attribute directly from the backend, but the translucent overlay does not support this, so the backend is used instead. I've attached a patch which makes acl_set_gather always use an internal search operation to fetch the attribute, instead of calling acl_set_gather2. I've also tried to hack the translucent overlay so that it would support the bi_entry_get_rw callback but I haven't been able to provide something that would even satisfy me. I suppose I would have to use some sort of callback mechanism like translucent_search_cb but I haven't figured it out yet.

1 0

Re: (ITS#5627) set syntax in ACI's
by kouk＠noc.uoa.gr 23 Jul '08

23 Jul '08

actually the patch is against version 2.4.11, but tests have been done with 2.4.10. Nothing seems to have changed in servers/slapd/aci.c.

1 0

(ITS#5627) set syntax in ACI's
by kouk＠noc.uoa.gr 23 Jul '08

23 Jul '08

Full_Name: Kostantinos Koukopoulos Version: 2.4.10 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723.patch Submission from: (NULL) (195.134.100.30) It seems that while set syntax in ACIs is supported by aci_mask, it's impossible to add a ACI value with set syntax. Debugging the problem I've found that in OpenLDAPaciPrettyNormal, the subject part of the ACI value is stripped when the type is 'set'. The included patch seems to correct the problem for me.

1 0

(ITS#5626) Update online admin guide
by ghenry＠OpenLDAP.org 23 Jul '08

23 Jul '08

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Just an ITS for syncing the online guide with what's in 2.4.11 Thanks.

1 0

(ITS#5625) memberOf search ACLs
by abartlet＠samba.org 23 Jul '08

23 Jul '08

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) >From thread on opendlap-technical: > Hmm, I have the module loaded globally - perhaps I need a global rootdn > of some kind defined? > > I have one per-database (now), but the documentation strongly encourages > one not to have a rootdn at all. The fix was to define rootdn globally (as the module operates globally), and then to give it explicit manage access in an ACL. eg access to dn.subtree="${DOMAINDN}" by dn=cn=samba-admin,cn=samba manage by dn=cn=manager manage by * none rootdn cn=Manager Adding a rootdn to each database then quashed the warnings about 'rootdn can always manage'. Otherwise, if I had 'by * read' then this also allowed the module to operate correctly (but without the secrecy I desired)

1 0

Re: (ITS#5616) Docs: various admin guide corrections
by ghenry＠OpenLDAP.org 23 Jul '08

23 Jul '08

jclarke(a)linagora.org wrote: > Full_Name: Jonathan Clarke > Version: > OS: > URL: http://milopita.phillipoux.net/jonathan-clarke-20080716.patch > Submission from: (NULL) (213.41.243.192) > > > Hi, > > Reading through the admin guide (checked out via CVS), I have come across a few > typos and inconsistencies (missing words, chapter references, etc). The patch at > the URL below includes some very simple corrections for these. > > Regards, > Jonathan > > OK, thanks. I'll take a look. Sorry it's taken a week, I've been away. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5624) overlay rwm causes assertion
by ef87＠yahoo.com 22 Jul '08

22 Jul '08

Full_Name: Eric Fox Version: 2.3.42 OS: Linux i386 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.252.207.30) Using slapo-rwm can cause slapd to crash when the following conditions occur: 1. overlay rwm is used in slapd.conf before or within a database meta section. 2. The database meta configuration proxies request to a Windows Active Directory server. 3. An Active Directory User object is queried and contains a value of a single blank space in either the "homePhone" or "pager" attribute. When the "overlay rwm" is removed from the configuration, the assertion does not occur. -- slapd.conf -- database meta suffix "dc=ad,dc=company,dc=com" uri "ldaps://server.ad.example.com/dc=ad,dc=company,dc=com" suffixmassage "dc=ad,dc=company,dc=com" "dc=ad,dc=example,dc=com" chase-referrals no idassert-bind bindmethod="simple" binddn="cn=proxyuser,cn=users,dc=ad,dc=example,dc=com" credentials="secret" mode="none" overlay rwm -- client sends -- ldapsearch -x -W -D 'cn=Eric,ou=users,dc=ad,dc=company,dc=com' -b 'ou=users,dc=ad,dc=company,dc=com' '(uid=eric)' -- slapd asserts -- slapd: attr.c:141: attr_dup: Assertion `j == i' failed. -- gdb -- gdb ./slapd GNU gdb Red Hat Linux (6.5-37.el5_2.2rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/i686/nosegneg/libthread_db.so.1". (gdb) r -d0 -h ldap:/// ldaps:/// -f /usr/local/etc/openldap/slapd.conf Starting program: /usr/local/src/openldap/openldap-2.3.42/servers/slapd/slapd -d0 -h ldap:/// ldaps:/// -f /usr/local/etc/openldap/slapd.conf [Thread debugging using libthread_db enabled] [New Thread -1208166704 (LWP 19457)] [New Thread -1223799920 (LWP 19460)] [New Thread -1227998320 (LWP 19461)] [New Thread -1232196720 (LWP 19462)] [New Thread -1236395120 (LWP 19463)] [New Thread -1240593520 (LWP 19464)] slapd: attr.c:141: attr_dup: Assertion `j == i' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1232196720 (LWP 19462)] 0x004f1402 in __kernel_vsyscall () (gdb) bt full #0 0x004f1402 in __kernel_vsyscall () No symbol table info available. #1 0x0089ef20 in raise () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #2 0x008a0901 in abort () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #3 0x008982fb in __assert_fail () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. #4 0x0807dd03 in attr_dup (a=0x9b659f8) at attr.c:141 j = 0 i = 1 tmp = (Attribute *) 0x9b8d570 __PRETTY_FUNCTION__ = "attr_dup" #5 0x0807ddc8 in attrs_dup (a=0x9b659f8) at attr.c:166 tmp = (Attribute *) 0x9b659b0 next = (Attribute **) 0x9b8d4f4 #6 0x0807e3b4 in entry_dup (e=0xb68e0e98) at entry.c:840 No locals. #7 0x0817d868 in rwm_response (op=0x9b84828, rs=0xb68e21b4) at rwm.c:1380 rwmap = (struct ldaprwmap *) 0x4c06 rc = -10 #8 0x080cc3d2 in over_back_response (op=0x9b84828, rs=0xb68e21b4) at backover.c:237 on = (slap_overinst *) 0x9a01210 rc = 0 be = (BackendDB *) 0xb68e0f9c db = {bd_info = 0x9a01210, be_ctrls = "\000", '\001' <repeats 16 times>, '\0' <repeats 15 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x99e4140, be_nsuffix = 0x99e4180, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x99fa0d8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9a9a430, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x99e49c8, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x99e4a00, be_next = {stqe_next = 0x9a01590}} #9 0x0808416f in slap_send_search_entry (op=0x9b84828, rs=0xb68e21b4) at result.c:717 sc = (slap_callback *) 0xb59dd34c sc_prev = (slap_callback **) 0xb59dd34c sc_next = (slap_callback *) 0x0 berbuf = { buffer = "�\a\034\bD\016\216��\v\216�\000\000\022\204\001\000\000\000�\v\216�\030\000\000\000�\v\216���\231\000�\000\000\000��\215\000�\v\216�\000�\033\bD\016\216�\000\000\000\000\004\000\000\000\r��\t�\177\233\000(\000\000\000�\v\216���\231\000\220U�\t��\215\000@\221\233\000�\v�\t�\v\216�\200,\216\000@\221\233\000�\v�\t(\"\216�\030\000\000\000�\v\216���\231\000PU\025\b�\177\233\000@\221\233\000�\017�\t\030\f\216�\200,\216\000@\221\233\000�\017�\t�\v�\t\000\000\000\000\030\f\216�|�\031\b\220U�\t�\177\233\000@\221\233\000�Y�\tH\f\216�"..., ialign = 136054759, lalign = 136054759, falign = 4.69538316e-34, dalign = -6.5807878282580064e-46, palign = 0x81c07e7 "\211s\030\211{\b\213]�\213u�\213}�\211�]�\215�"} ber = <value optimized out> a = <value optimized out> i = <value optimized out> j = <value optimized out> rc = 0 edn = <value optimized out> userattrs = <value optimized out> acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} attrsonly = <value optimized out> ad_entry = (AttributeDescription *) 0x99a0968 ---Type <return> to continue, or q <return> to quit--- e_flags = (char **) 0x0 #10 0x080f84f2 in meta_back_search (op=0x9b84828, rs=0xb68e21b4) at search.c:2027 e = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x81f2400 ""}, e_nname = {bv_len = 0, bv_val = 0x81f2400 ""}, e_attrs = 0x9b65590, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} mod = {sm_op = 0, sm_flags = 0, sm_desc = 0x99e39a0, sm_type = {bv_len = 4, bv_val = 0x99ed2b8 "mail"}, sm_values = 0x9b659c8, sm_nvalues = 0x9b659e0} text = 0x0 textbuf = "\003\000\000\000\020\000\000\000\000\000\000\000��\235��\016\216��\r\216�\035�\a\b\f\000\000\000���\t\210\r\216�\000\001\000\000�\016\216�\000\000\000\000\000\000\000\000�F�\t�\r\216�(H�\t�\r\216�w1\034\b��\235����\t\v\000\000\000�F�\t�F�\t�\r\216��\016\216�X\213\t\b�\r\216��\r\216��\016\216��\016\216�@y\233\000\000\000\000\000�\r\216�|�\031\b\225\017\216\000\000\000\001\000\000\000\000\000e", '\0' <repeats 15 times>, "��\235���\235�\000\000\000\000\000\000\000\000���\t\225\017\216\000\v\000\000\0008\016\216��F�\t,"... next = (Attribute *) 0x9b659f8 tap = <value optimized out> ap = <value optimized out> mi = (metainfo_t *) 0x99e4a00 mc = (metaconn_t *) 0x9b47c50 tv = {tv_sec = 0, tv_usec = 100000} stoptime = 1216759554 lastres_time = 1216755954 timeout = <value optimized out> rc = 100 sres = 0 matched = <value optimized out> ncandidates = 1 candidate_match = 0 needbind = <value optimized out> sendok = <value optimized out> i = <value optimized out> dc = {target = 0x99fe348, conn = 0xb70e69e8, ctx = 0x81e6ffa "searchBase", rs = 0xb68e21b4} is_ok = 0 savepriv = <value optimized out> candidates = (SlapReply *) 0x9b4c878 __PRETTY_FUNCTION__ = "meta_back_search" #11 0x080cc5d1 in overlay_op_walk (op=0x9b84828, rs=0xb68e21b4, which=op_search, oi=0x9a01120, on=0x9a01210) at backover.c:650 sc_next = <value optimized out> rc = 32768 #12 0x080cc9bd in over_op_func (op=0x9b84828, rs=0xb68e21b4, which=op_search) at backover.c:702 oi = (slap_overinfo *) 0x9a01120 on = (slap_overinst *) 0x9a01210 be = (BackendDB *) 0x99e48f8 db = {bd_info = 0x8238080, be_ctrls = "\000", '\001' <repeats 16 times>, '\0' <repeats 15 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x99e4140, be_nsuffix = 0x99e4180, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x99fa0d8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9a9a430, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x99e49c8, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x99e4a00, be_next = {stqe_next = 0x9a01590}} cb = {sc_next = 0x0, sc_response = 0x80cc360 <over_back_response>, sc_cleanup = 0, sc_private = 0x9a01120} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #13 0x0807716f in fe_op_search (op=0x9b84828, rs=0xb68e21b4) at search.c:355 entry = (Entry *) 0x0 bd = (BackendDB *) 0x823f260 ---Type <return> to continue, or q <return> to quit--- #14 0x08077a90 in do_search (op=0x9b84828, rs=0xb68e21b4) at search.c:217 base = {bv_len = 59, bv_val = 0x9ab021f "ou=users,ou=einstein industries,dc=ad,dc=eiinetworks,dc=com"} siz = 0 i = 32 #15 0x080752d2 in connection_operation (ctx=0xb68e2228, arg_v=0x9b84828) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0xb68e0e98}, sru_extended = {r_rspoid = 0xb68e0e98 "", r_rspdata = 0x21}, sru_search = {r_entry = 0xb68e0e98, r_attr_flags = 33, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = (Connection *) 0xb70e69e8 memctx = (void *) 0x9b7e0a0 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #16 0x0819d923 in ldap_int_thread_pool_wrapper (xpool=0x99a2f30) at tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x9aae018 ltc_key = {{ltk_key = 0x80be1e0, ltk_data = 0x9b7e0a0, ltk_free = 0x80bdd50 <slap_sl_mem_destroy>}, {ltk_key = 0x825b894, ltk_data = 0x9b4c7e8, ltk_free = 0x8151430 <meta_back_candidates_keyfree>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 30 times>} tid = 3062770576 i = 511 hash = <value optimized out> #17 0x009f2482 in start_thread () from /lib/i686/nosegneg/libpthread.so.0 No symbol table info available. #18 0x00948c8e in clone () from /lib/i686/nosegneg/libc.so.6 No symbol table info available. (gdb)

1 0

Re: (ITS#5604) sbin executable names not recognised on Win32
by h.b.furuseth＠usit.uio.no 22 Jul '08

22 Jul '08

Fixed in HEAD. Please test. -- Hallvard

1 0

(ITS#5623) slapd segfaults on syncrepl provider
by m.gr＠gmx.de 21 Jul '08

21 Jul '08

Full_Name: Matthias Grau Version: 2.3.43 OS: irrelevant URL: Submission from: (NULL) (195.200.70.23) Slapd segfaults on a syncrepl provider. This error occurs when the connections of several synchronous modify operations are not disconnected correctly (e.g. network issues). syncprov.c line 1707: m2 seems to be NULL in this case so m2->mi_next causes the segfault. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1243620448 (LWP 21810)] 0x08148dc3 in syncprov_op_mod (op=0xb6307450, rs=0xb5dfd264) at syncprov.c:1707 1707 for ( m2 = mt->mt_mods; m2->mi_next != mi; (gdb) bt #0 0x08148dc3 in syncprov_op_mod (op=0xb6307450, rs=0xb5dfd264) at syncprov.c:1707 #1 0x080c6184 in overlay_op_walk (op=0xb6307450, rs=0xb5dfd264, which=op_modify, oi=0x825b470, on=0x825b560) at backover.c:640 #2 0x080c65dd in over_op_func (op=0xb6307450, rs=0xb5dfd264, which=op_modify) at backover.c:702 #3 0x08088d1b in fe_op_modify (op=0xb6307450, rs=0xb5dfd264) at modify.c:395 #4 0x08089558 in do_modify (op=0xb6307450, rs=0xb5dfd264) at modify.c:200 #5 0x08071fd2 in connection_operation (ctx=0xb5dfd2d8, arg_v=0xb6307450) at connection.c:1133 #6 0x08159b2a in ldap_int_thread_pool_wrapper (xpool=0x8225330) at tpool.c:478 #7 0xb7cfc34b in start_thread () from /lib/libpthread.so.0 #8 0xb7aea65e in clone () from /lib/libc.so.6 (gdb) print m2 $1 = (modinst *) 0x0

1 0

Re: (ITS#5618) better error messages for syncrepl failure
by henson＠acm.org 19 Jul '08

19 Jul '08

On Sat, 19 Jul 2008, Pierangelo Masarati wrote: > > I recently installed some updates and configuration changes on one of my > > LDAP slaves. Replication broke mysteriously after that. The only thing logged > > was "slapd[30723]: do_syncrepl: rid 001 retrying (9 retries left)" > > What log level? "none". I also changed the level to "-1" and nothing popped out at me. Howard says there should have been some packet dumps that would have included the protocol error, but I must have missed them amoungst all the noise of level -1. A nice error message at "none' would have helped. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson(a)csupomona.edu California State Polytechnic University | Pomona CA 91768

1 0

Re: (ITS#5621) test036 fails
by dieter＠dkluenter.de 19 Jul '08

19 Jul '08

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > >> Hi, >> test036 fails constantly with following error: >> ... >> Using ldapsearch to retrieve all the entries... >> Filtering ldapsearch results... >> Filtering original ldif used to create database... >> Comparing filter output... >> comparison failed - slapd-meta search/modification didn't succeed >> diff -i ldapsearch.flt ldif.flt > diff.out > > I hate to say this, but... works for me, even with -i. OK, I have to accept this. As my local CVS tree is only a weeky update and not a fresh checkout there might be some errors in the test scripts, as -iB works for me, I leave it as is. Please close this its. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

1 0

Re: (ITS#5621) test036 fails
by ando＠sys-net.it 19 Jul '08

19 Jul '08

dieter(a)dkluenter.de wrote: > Hi, > test036 fails constantly with following error: > ... > Using ldapsearch to retrieve all the entries... > Filtering ldapsearch results... > Filtering original ldif used to create database... > Comparing filter output... > comparison failed - slapd-meta search/modification didn't succeed > > diff -i ldapsearch.flt ldif.flt > diff.out I hate to say this, but... works for me, even with -i. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5622) slapo-memberof erroneously using o_dn instead of o_ndn in internal ops
by ando＠sys-net.it 19 Jul '08

19 Jul '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando As spotted by Andrew Bartlett <http://www.openldap.org/lists/openldap-technical/200807/msg00126.html>, slapo-memberof is using the wrong DN to set the operation's identity while performing internal ops. A fix is coming. p.

1 0

Re: (ITS#5618) better error messages for syncrepl failure
by ando＠sys-net.it 19 Jul '08

19 Jul '08

henson(a)acm.org wrote: > I recently installed some updates and configuration changes on one of my > LDAP slaves. Replication broke mysteriously after that. The only thing logged > was "slapd[30723]: do_syncrepl: rid 001 retrying (9 retries left)" What log level? p. > I finally figured out that the search was failing with a protocol error because > derefAliases was set to always, a setting I had just added. It would be useful > if replication failure provided better error messages, something in the logs > indicating that a protocol error had occurred because of an invalid > dereferencing setting would have saved me a lot of time. > > In addition, if it is a protocol error to dereference aliases in the context of > syncrepl, shouldn't the server just ignore that global configuration setting and > just do the right thing? Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5621) test036 fails
by dieter＠dkluenter.de 18 Jul '08

18 Jul '08

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux x86_64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.215.25) >> >> >> Hi, >> test036 fails constantly with following error: >> ... >> Using ldapsearch to retrieve all the entries... >> Filtering ldapsearch results... >> Filtering original ldif used to create database... >> Comparing filter output... >> comparison failed - slapd-meta search/modification didn't succeed Somehow empty lines had been added, diff -iB solved the problem. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

1 0

Re: (ITS#5621) test036 fails
by dieter＠dkluenter.de 18 Jul '08

18 Jul '08

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux x86_64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.215.25) >> >> >> Hi, >> test036 fails constantly with following error: >> ... >> Using ldapsearch to retrieve all the entries... >> Filtering ldapsearch results... >> Filtering original ldif used to create database... >> Comparing filter output... >> comparison failed - slapd-meta search/modification didn't succeed > > If your HEAD snapshot is before this commit, then it's a known issue > and this ITS will be closed. > > http://www.openldap.org/lists/openldap-commit/200807/msg00174.html No, it is a cvs update from last night. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5621) test036 fails
by hyc＠symas.com 18 Jul '08

18 Jul '08

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.215.25) > > > Hi, > test036 fails constantly with following error: > ... > Using ldapsearch to retrieve all the entries... > Filtering ldapsearch results... > Filtering original ldif used to create database... > Comparing filter output... > comparison failed - slapd-meta search/modification didn't succeed If your HEAD snapshot is before this commit, then it's a known issue and this ITS will be closed. http://www.openldap.org/lists/openldap-commit/200807/msg00174.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5621) test036 fails
by dieter＠dkluenter.de 18 Jul '08

18 Jul '08

Full_Name: Dieter Kluenter Version: HEAD OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.215.25) Hi, test036 fails constantly with following error: ... Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... comparison failed - slapd-meta search/modification didn't succeed diff -i ldapsearch.flt ldif.flt > diff.out 87a87,103 > dn: cn=Dorothy Stevens,ou=Alumni Association,ou=People,o=Example,c=US > objectClass: OpenLDAPperson > cn: Dorothy Stevens > cn: Dot Stevens > sn: Stevens > uid: dots > title: Secretary, UM Alumni Association > postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 > seeAlso: cn=All Staff,ou=Groups,o=Example,c=US > drink: Lemonade > homePostalAddress: 377 White St. Apt. 3 $ Anytown, MI 48104 > description: Very tall > facsimileTelephoneNumber: +1 313 555 3223 > telephoneNumber: +1 313 555 3664 > mail: dots(a)mail.alumni.example.com > homePhone: +1 313 555 0454 > 398,415d413 < dn: cn=snevetS yhtoroD,ou=Alumni Association,ou=People,o=Example,c=US < objectClass: OpenLDAPperson < cn: Dorothy Stevens < cn: Dot Stevens < cn: snevetS yhtoroD < sn: Stevens < uid: dots < title: Secretary, UM Alumni Association < postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 < seeAlso: cn=All Staff,ou=Groups,o=Example,c=US < drink: Lemonade < homePostalAddress: 377 White St. Apt. 3 $ Anytown, MI 48104 < description: Very tall < facsimileTelephoneNumber: +1 313 555 3223 < telephoneNumber: +1 313 555 3664 < mail: dots(a)mail.alumni.example.com < homePhone: +1 313 555 0454 < 430d427 -Dieter

1 0

Re: (ITS#5620) Compile problem with Berkeley DB 4.7.25
by hyc＠symas.com 17 Jul '08

17 Jul '08

quanah(a)zimbra.com wrote: > --On Thursday, July 17, 2008 6:19 AM +0000 marco.walther(a)sun.com wrote: > >> Full_Name: Marco Walther >> Version: 2.4.11 >> OS: SunOS 5.11 snv_70b sun4v sparc SUNW,SPARC >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (192.18.43.225) > > No openldap release supports BDB 4.7 yet. There is already a bug filed on > this issue, and it will be addressed in an upcoming release. #5530. This ITS will be closed as a dup of #5530. Hacking the BDB source to expose the private field certainly works for now, but we'll be looking at a hands-off fix later. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5620) Compile problem with Berkeley DB 4.7.25
by quanah＠zimbra.com 17 Jul '08

17 Jul '08

--On Thursday, July 17, 2008 6:19 AM +0000 marco.walther(a)sun.com wrote: > Full_Name: Marco Walther > Version: 2.4.11 > OS: SunOS 5.11 snv_70b sun4v sparc SUNW,SPARC > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.18.43.225) No openldap release supports BDB 4.7 yet. There is already a bug filed on this issue, and it will be addressed in an upcoming release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5620) Compile problem with Berkeley DB 4.7.25
by marco.walther＠sun.com 17 Jul '08

17 Jul '08

Full_Name: Marco Walther Version: 2.4.11 OS: SunOS 5.11 snv_70b sun4v sparc SUNW,SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.18.43.225) The problem is in servers/slapd/back-bdb/cache.c and servers/slapd/back-bdb/init.c The db-4.7.?? moved the lk_handle from the public DB_ENV to a private ENV structure. So it's officially not accessible any more. I'll include a little diff to show the problem. But I don't think my `quick compile' fix is completely correct. I'm more interested in the client libraries than the servers right now. --- init.c.orig Wed Jul 16 22:56:00 2008 +++ init.c Wed Jul 16 23:01:26 2008 @@ -503,9 +503,15 @@ } if ( !quick ) { -#if DB_VERSION_FULL >= 0x04060012 +#if DB_VERSION_FULL >= 0x04070025 + # XXX mw79288 real hack!! + #include "/export/home/marcow/src/db-4.7.25/build_unix/db_int.h" u_int32_t lid; XLOCK_ID(bdb->bi_dbenv, &lid); + __lock_getlocker(bdb->bi_dbenv->env->lk_handle, lid, 0, &bdb->bi_cache.c_locker); +#elsif DB_VERSION_FULL >= 0x04060012 + u_int32_t lid; + XLOCK_ID(bdb->bi_dbenv, &lid); __lock_getlocker(bdb->bi_dbenv->lk_handle, lid, 0, &bdb->bi_cache.c_locker); #else XLOCK_ID(bdb->bi_dbenv, &bdb->bi_cache.c_locker);

1 0

(ITS#5619) slapd configuration option to set LDAP options
by henson＠acm.org 16 Jul '08

16 Jul '08

Full_Name: Paul B. Henson Version: 2.3.40 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.71.248.24) I would like to request some configuration mechanism that would allow slapd to be configured with different LDAP settings. This could be a commandline option, or an extension to the configuration file. My particular situation is that I need to have a different setting for derefAliases for slapd (in order for syncrepl to work) vs the automounter (which needs to dereference aliases to integrate into my directory configuration).

1 0

(ITS#5618) better error messages for syncrepl failure
by henson＠acm.org 16 Jul '08

16 Jul '08

Full_Name: Paul B. Henson Version: 2.3.40 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.71.248.24) I recently installed some updates and configuration changes on one of my LDAP slaves. Replication broke mysteriously after that. The only thing logged was "slapd[30723]: do_syncrepl: rid 001 retrying (9 retries left)" I finally figured out that the search was failing with a protocol error because derefAliases was set to always, a setting I had just added. It would be useful if replication failure provided better error messages, something in the logs indicating that a protocol error had occurred because of an invalid dereferencing setting would have saved me a lot of time. In addition, if it is a protocol error to dereference aliases in the context of syncrepl, shouldn't the server just ignore that global configuration setting and just do the right thing?

1 0

(ITS#5617) N-way multimaster replication problem
by miguel.jinez＠gmail.com 16 Jul '08

16 Jul '08

Full_Name: Miguel Jinez Version: 2.4.10 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.13.96.237) I am running openLdap 2.4.10 I have configurated 2 n-way multimaster(A-B) servers, it works fine when two masters are up. I have a problem in the next situation: 1)-Everything ok 2)-One master(A) dies (is not working). 3)-Adds, updates and DELETES are performed meanwhile in master(B). 4)-Master(B) dies too and master(A) has not been restarted. 5)-Restart master(B) 6)-Restart master(A) 7)-Checking DIT in master(B) = ok 8)-Checking DIT in master(A) adds=ok 9)-Checking DIT in master(A) updates=ok 10)-Checking DIT in master(A) DELETES= Entries are not deleted at synchronization time. Why adds and updates are performed and deletes no? Maybe the reqMod is not loaded in deletes? Thanks fro your atention Migue

1 0

Re: (ITS#5565) slapd crashes due to SIGPIPE
by jwm＠horde.net 16 Jul '08

16 Jul '08

On Fri, Jun 20, 2008 at 01:37:15PM -0700, Howard Chu wrote: > John Morrissey wrote: > > Program received signal SIGABRT, Aborted. > > [Switching to Thread -1963996240 (LWP 22635)] > > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > > This trace resembles ITS#5401, which was only fixed in RE24. You can look > at the patch to syncprov.c there. There's no plan to make another 2.3 > release at the moment. slapd crashed again today due to the same assertion failure; backtrace is below. This was RE23 from 12 June 2008 plus 1.220 and 1.147.2.28 from servers/slapd/overlays/syncprov.c. john GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1212823328 (LWP 30058)] [New Thread -1884124240 (LWP 30065)] [New Thread -1879929936 (LWP 30064)] [New Thread -1875735632 (LWP 30063)] [New Thread -1538978896 (LWP 30062)] Failed to read a valid object file image from memory. 0xb7caa183 in pthread_join () from /lib/tls/libpthread.so.0 [New Thread -1917846608 (LWP 30096)] [New Thread -1931883600 (LWP 30138)] [New Thread -1936077904 (LWP 30139)] [New Thread -1941324880 (LWP 30140)] [New Thread -1953911888 (LWP 30141)] [New Thread -1958106192 (LWP 30142)] [New Thread -1963353168 (LWP 30143)] [New Thread -1968600144 (LWP 30144)] [New Thread -1981187152 (LWP 30145)] [New Thread -1985381456 (LWP 30146)] [New Thread -1990628432 (LWP 30147)] [New Thread -2072011856 (LWP 30444)] [New Thread -2076206160 (LWP 30445)] [New Thread -2080400464 (LWP 30446)] [New Thread -2084594768 (LWP 30447)] [New Thread -2126570576 (LWP 30511)] [New Thread -2130764880 (LWP 30512)] [New Thread 2141117360 (LWP 30522)] [New Thread 2136923056 (LWP 30523)] [New Thread 2132728752 (LWP 30524)] [New Thread 2128534448 (LWP 30525)] [New Thread 2124340144 (LWP 30526)] [New Thread 2120145840 (LWP 30527)] [New Thread 2113846192 (LWP 30528)] [New Thread 1831861168 (LWP 1808)] [New Thread 1826614192 (LWP 1809)] [New Thread 1789918128 (LWP 1821)] [New Thread 1785723824 (LWP 1822)] [New Thread 1781529520 (LWP 1823)] Program received signal SIGABRT, Aborted. [Switching to Thread 1831861168 (LWP 1808)] 0xb7b9a947 in raise () from /lib/tls/libc.so.6 Thread 34 (Thread 1781529520 (LWP 1823)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x95d5eb0, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x55, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0x10c, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x68bfb008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 1781529520 i = 580 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 33 (Thread 1785723824 (LWP 1822)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x849c190, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x56, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0x10d, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x683fa008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 1785723824 i = 644 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 32 (Thread 1789918128 (LWP 1821)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x782c6728, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x57, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0x10b, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x693fc008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 1789918128 i = 708 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 31 (Thread 1826614192 (LWP 1809)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x950a0a8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x54, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0xdb, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x6b4ff008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 1826614192 i = 745 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 30 (Thread 1831861168 (LWP 1808)): #0 0xb7b9a947 in raise () from /lib/tls/libc.so.6 No symbol table info available. #1 0xb7b9c0c9 in abort () from /lib/tls/libc.so.6 No symbol table info available. #2 0xb7b9405f in __assert_fail () from /lib/tls/libc.so.6 No symbol table info available. #3 0x0806bba2 in connection_state_closing (c=0x9032fa68) at /misc/src/net/openldap/servers/slapd/connection.c:765 state = <value optimized out> __PRETTY_FUNCTION__ = "connection_state_closing" #4 0x0807bc34 in send_ldap_ber (conn=0x9032fa68, ber=0x6d2fedac) at /misc/src/net/openldap/servers/slapd/result.c:162 err = 6 sd = 135489725 bytes = <value optimized out> #5 0x0807dd19 in slap_send_search_entry (op=0x6d2fef20, rs=0x6d2ff1cc) at /misc/src/net/openldap/servers/slapd/result.c:1137 a_flags = 0x1 <Address 0x1 out of bounds> berbuf = {buffer = "\002\000\001\000\000\000\000\000ÿÿÿÿ\000\000\000\000\000\000\000\000$\001àl\232\001àlR\021àl\000\000\000\000\000\000\000\0008\036ä\b\000\000\000\0008\036ä\b\000\000\000\000(\235ð·\030\000\000\000(\235ð·\000\000\000\000xò/m\030î/mÜPð·\r\000\000\0008\036ä\b\000\000\000\000ÔYð·\f\000\000\000xò/m8î/mðUð·\fðßlhî/m\f\000\000\000tî/m\001\000\000\000 ï/mÈî/m\231t\f\bhî/m\f\000\000\000\001\000\000\000xò/m8\036ä\blî/mhî/m\206Eð·\001\000\000\000\000\000\000\000csn=,rid=001"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x6d2fedac a = (Attribute *) 0x6 i = 1 j = <value optimized out> rc = <value optimized out> edn = 0x78905d0f "reqStart=20080701154812Z,cn=log" userattrs = 1 acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0} <repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} attrsonly = 0 ad_entry = (AttributeDescription *) 0x814ad90 e_flags = (char **) 0x0 #6 0xb79adeea in syncprov_qtask (ctx=0x6d2ff2c8, arg=0x739526d8) at /misc/src/net/openldap/servers/slapd/overlays/syncprov.c:798 so = (syncops *) 0x6f6396c0 on = (slap_overinst *) 0x819da60 opbuf = {buffer = "ðï/mc\000\000\000xÆ|H\000\000\000\000Ìð/m\006\000\000\000)Š5m\006\000\000\0000Š5m\002\000\000\000\000\000\000\000ÿÿÿÿÿÿÿÿ\\Ø\031\b\000\000\000\000,¥5m\230%Sp.\000\000\0007Š5m", '\0' <repeats 12 times>, "\001", '\0' <repeats 39 times>, "Lð/m\200", '\0' <repeats 11 times>, "\025\000\000\000\023Š5m\025\000\000\000\023Š5m", '\0' <repeats 48 times>, "\001\000\000\000ê¹\001\000hú2\220\002\000\000\000\003\000\000\000\000\000\000\000Èò/m8\036ä\b°Ÿ\023\bconn=113130 op=1", '\0' <repeats 167 times>, ialign = 1831858160, lalign = 1831858160, falign = 3.40312146e+27, dalign = 2.1098264149047192e-312, palign = 0x6d2feff0 "\001"} op = (Operation *) 0x6d2fef20 be = {bd_info = 0x819d960, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x82165e0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79de5c0, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} rc = <value optimized out> #7 0xb7f16eff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x6ff38da8 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8e41e38, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x53, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0xda, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x6c1fe008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 1831861168 i = 583 hash = <value optimized out> #8 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #9 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 29 (Thread 2113846192 (LWP 30528)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x830bf38, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0xb4, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x7aee2008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x51, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2113846192 i = 742 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 28 (Thread 2120145840 (LWP 30527)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x83129a8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x4d, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0xb3, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x7b6e3008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2120145840 i = 615 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 27 (Thread 2124340144 (LWP 30526)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x82df988, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x4c, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0xaf, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x7d2ea008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2124340144 i = 679 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 26 (Thread 2128534448 (LWP 30525)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8403f38, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x4e, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0xb5, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x79ee0008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2128534448 i = 744 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 25 (Thread 2132728752 (LWP 30524)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x83b9228, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0xb1, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x7bee4008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x52, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2132728752 i = 552 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 24 (Thread 2136923056 (LWP 30523)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x83b9250, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0xb2, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x82168f8, ltk_data = 0x50, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x7a6e1008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2136923056 i = 616 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 23 (Thread 2141117360 (LWP 30522)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8421e98, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0xb0, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x7c7e6008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x4f, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2141117360 i = 680 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 22 (Thread -2130764880 (LWP 30512)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x82d1860, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x4a, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0xa1, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x801ef008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2164202416 i = 586 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 21 (Thread -2126570576 (LWP 30511)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x84192f0, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0xa2, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x7f9ee008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x4b, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2168396720 i = 395 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 20 (Thread -2084594768 (LWP 30447)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x87107b58, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x47, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0x9c, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x81bf3008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2210372528 i = 653 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 19 (Thread -2080400464 (LWP 30446)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x884179f8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x48, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0x9a, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x82bf5008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2214566832 i = 717 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 18 (Thread -2076206160 (LWP 30445)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x843c028, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x46, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0x9b, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x823f4008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2218761136 i = 526 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 17 (Thread -2072011856 (LWP 30444)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x83c75a8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x49, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x8218320, ltk_data = 0xa0, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x813f2008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2222955440 i = 590 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 16 (Thread -1990628432 (LWP 30147)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x831b158, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x37, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x88895008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x8218320, ltk_data = 0x99, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2304338864 i = 510 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 15 (Thread -1985381456 (LWP 30146)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db16ac8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x38, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x87bff008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x8218320, ltk_data = 0x97, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2309585840 i = 605 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 14 (Thread -1981187152 (LWP 30145)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8511050, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x90, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x82168f8, ltk_data = 0x39, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x873fe008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2313780144 i = 669 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 13 (Thread -1968600144 (LWP 30144)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db1c248, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x93, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x82168f8, ltk_data = 0x42, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x84ffb008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2326367152 i = 622 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 12 (Thread -1963353168 (LWP 30143)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db10818, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x35, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x89e98008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x8218320, ltk_data = 0x91, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2331614128 i = 718 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 11 (Thread -1958106192 (LWP 30142)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x82796b8, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x8f, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x82168f8, ltk_data = 0x3a, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x867fe008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2336861104 i = 559 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 10 (Thread -1953911888 (LWP 30141)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x84bec58, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x96, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x857fc008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x41, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2341055408 i = 623 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 9 (Thread -1941324880 (LWP 30140)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8511888, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x92, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x82168f8, ltk_data = 0x3c, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x85ffd008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2353642416 i = 576 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 8 (Thread -1936077904 (LWP 30139)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x8db18570, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x33, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x8b89b008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x8218320, ltk_data = 0x95, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2358889392 i = 672 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 7 (Thread -1931883600 (LWP 30138)): #0 0xb7bd6683 in malloc_consolidate () from /lib/tls/libc.so.6 No symbol table info available. #1 0xb7bd8638 in _int_malloc () from /lib/tls/libc.so.6 No symbol table info available. #2 0xb7bda32f in malloc () from /lib/tls/libc.so.6 No symbol table info available. #3 0xb7f050f8 in ber_memalloc_x (s=2265972752, ctx=0x1) at /misc/src/net/openldap/libraries/liblber/memory.c:226 new = (void *) 0x0 #4 0xb7f052c3 in ber_memalloc (s=1032) at /misc/src/net/openldap/libraries/liblber/memory.c:242 No locals. #5 0xb7abdbd1 in __os_malloc_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #6 0xb7a7eb99 in __db_addrem_log_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #7 0xb7a853ca in __db_ditem_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #8 0xb7a2458e in __bam_ditem_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #9 0xb7a23867 in __bam_c_init_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #10 0xb7a2426a in __bam_c_init_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #11 0xb7a7f371 in __db_c_close_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #12 0xb7a78327 in __db_del_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #13 0xb7a888b8 in __db_del_pp_4002 () from /usr/lib/libdb-4.2.so No symbol table info available. #14 0xb79d4e94 in bdb_id2entry_delete (be=0x8cd9bd4c, tid=0x791c1ab0, e=0x6725de90) at /misc/src/net/openldap/servers/slapd/back-bdb/id2entry.c:174 db = (DB *) 0x0 key = {data = 0x8cd9bbac, size = 4, ulen = 0, dlen = 0, doff = 0, flags = 0} rc = 64 nid = 3611697408 #15 0xb79c66fb in bdb_delete (op=0x8cd9be98, rs=0x8cd9c1f4) at /misc/src/net/openldap/servers/slapd/back-bdb/delete.c:407 bdb = (struct bdb_info *) 0x819d478 matched = <value optimized out> pdn = {bv_len = 6, bv_val = 0x66ffbce0 "cn=log"} e = (Entry *) 0x6725de90 p = (Entry *) 0x8217b40 ei = (EntryInfo *) 0x776d9f88 eip = (EntryInfo *) 0x82173c8 manageDSAit = 0 children = (AttributeDescription *) 0x814af20 entry = (AttributeDescription *) 0x814ad90 ltid = (DB_TXN *) 0x74199aa0 lt2 = (DB_TXN *) 0x791c1ab0 opinfo = {boi_bdb = 0x8cd9bd4c, boi_txn = 0x74199aa0, boi_err = 0, boi_locker = 2147551151, boi_acl_cache = 0, boi_locks = 0x0} eid = 2265972752 locker = 2147551151 lock = {off = 282872, ndx = 10, gen = 51539, mode = DB_LOCK_READ} plock = {off = 282584, ndx = 386, gen = 82243, mode = DB_LOCK_READ} num_retries = 0 rc = <value optimized out> preread_ctrl = (LDAPControl **) 0x0 ctrls = {0x0, 0x7316456c, 0x0, 0x6725de90, 0xb79b1640, 0x73164560} num_ctrls = 0 parent_is_glue = <value optimized out> parent_is_leaf = -1931887544 #16 0x080c57e0 in overlay_op_walk (op=0x8cd9be98, rs=0x8cd9c1f4, which=op_delete, oi=0x819d960, on=0x819da60) at /misc/src/net/openldap/servers/slapd/backover.c:650 sc_next = <value optimized out> rc = 32768 #17 0x080c5bde in over_op_func (op=0x8cd9be98, rs=0x8cd9c1f4, which=op_delete) at /misc/src/net/openldap/servers/slapd/backover.c:702 oi = (slap_overinfo *) 0x819d960 on = (slap_overinst *) 0x819da60 be = (BackendDB *) 0x819d370 db = {bd_info = 0xb79de920, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x82165e0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79de5c0, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} cb = {sc_next = 0xb79b9660, sc_response = 0x80c5550 <over_back_response>, sc_cleanup = 0, sc_private = 0x819d960} rc = 64 __PRETTY_FUNCTION__ = "over_op_func" #18 0xb79b4d20 in accesslog_purge (ctx=0x8cd9c2c8, arg=0x819e288) at /misc/src/net/openldap/servers/slapd/overlays/accesslog.c:589 i = 19 li = <value optimized out> conn = {c_struct_state = 0, c_conn_state = 0, c_conn_idx = 0, c_close_reason = 0x0, c_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 4294967295, c_peer_domain = {bv_len = 0, bv_val = 0x80f4a70 ""}, c_peer_name = {bv_len = 0, bv_val = 0x80f4a70 ""}, c_listener = 0x80f5d20, c_sasl_bind_in_progress = 0, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write_cv = {__c_lock = {__status = 0, __spinlock = 0}, __c_waiting = 0x0, __padding = '\0' <repeats 27 times>, __align = 0}, c_currentber = 0x0, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x807ef50 <slap_send_ldap_result>, c_send_search_entry = 0x807c600 <slap_send_search_entry>, c_send_search_reference = 0x807bd00 <slap_send_search_reference>, c_send_ldap_extended = 0, c_send_ldap_intermediate = 0} opbuf = {buffer = "h¿Ù\214J\000\000\000Ô\027~H\000\000\000\000LœÙ\214&\000\000\000\220Œÿf&\000\000\000ÀŒÿf\001\000\000\000\000\000\000\000ÿÿÿÿÿÿÿÿ\000\000\000\000\001\000\000\000\000Œ\023\b|ÂÙ\214\033\000\000\000\fÐ/\207", '\0' <repeats 52 times>, "Ä¿Ù\214", '\0' <repeats 12 times>, "\016\000\000\000àÕ\031\b\016\000\000\000È×\031\b", '\0' <repeats 24 times>, "\214\0050\207\000\000\000\000 \000\000\000ŽÁÙ\214\204ŒÙ\214\000\000\000\000\000\000\000\000ÿÿÿÿDÀÙ\214", '\0' <repeats 12 times>, "ÈÂÙ\214\b\036@\210°Ÿ\023\bconn=-1 op=0", '\0' <repeats 171 times>, ialign = -1931886744, lalign = -1931886744, falign = -3.35493423e-31, dalign = 1.5819520545052892e-312, palign = 0x8cd9bf68 ""} op = (Operation *) 0x8cd9be98 rs = {sr_type = REP_RESULT, sr_tag = 107, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x813bc00, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0xb79b4d70 <log_old_lookup>, sc_cleanup = 0, sc_private = 0x8cd9c230} f = {f_choice = 166, f_un = {f_un_result = -1931885968, f_un_dn = 0x8cd9c270, f_un_desc = 0x8cd9c270, f_un_ava = 0x8cd9c270, f_un_ssa = 0x8cd9c270, f_un_mra = 0x8cd9c270, f_un_complex = 0x8cd9c270}, f_next = 0x0} ava = {aa_desc = 0x8187280, aa_value = {bv_len = 15, bv_val = 0x8cd9c24a "20080702154628Z"}} pd = {slots = 8900, used = 8813, dn = 0x660e4830, ndn = 0x66900018, csn = {bv_len = 32, bv_val = 0x8cd9c1b4 "20080701154629Z#000000#00#000000øÊ2\220èÁÙ\214œvñ·dÐ\023\bšW±\215\bÂÙ\214\036ù\a\bdÐ\023\b"}} timebuf = "20080702154628Z\000Ù\214\213ŒÊ·" csnbuf = "20080701154629Z#000000#00#000000øÊ2\220èÁÙ\214œvñ·dÐ\023\bšW±\215\bÂÙ\214\036ù\a\bdÐ\023\b" old = 1215013588 #19 0xb7f16eff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:478 ctx = (ldap_int_thread_ctx_t *) 0x88419318 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x88401e08, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x94, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x82168f8, ltk_data = 0x45, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x847fa008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2363083696 i = 736 hash = <value optimized out> #20 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #21 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 6 (Thread -1917846608 (LWP 30096)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x831ca20, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x64, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x8cdfe008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x34, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2377120688 i = 743 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 5 (Thread -1538978896 (LWP 30062)): #0 0xb7c3e679 in epoll_wait () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0806a0df in slapd_daemon_task (ptr=0x0) at /misc/src/net/openldap/servers/slapd/daemon.c:2174 active = <value optimized out> l = 4 last_idle_check = 0 ebadf = 0 #2 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #3 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 4 (Thread -1875735632 (LWP 30063)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822e598, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x82168f8, ltk_data = 0x1c, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x8ee27008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x8218320, ltk_data = 0x98, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2419231664 i = 509 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 3 (Thread -1879929936 (LWP 30064)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x86bbc60, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x46, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x8e424008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x36, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2415037360 i = 700 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 2 (Thread -1884124240 (LWP 30065)): #0 0xb7cabc01 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17754 in ldap_pvt_thread_cond_wait (cond=0x814d374, mutex=0x814d35c) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:299 No locals. #2 0xb7f17033 in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /misc/src/net/openldap/libraries/libldap_r/tpool.c:466 ctx = (ldap_int_thread_ctx_t *) 0x0 ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822fb50, ltk_free = 0x80b6f10 <slap_sl_mem_destroy>}, {ltk_key = 0x8218320, ltk_data = 0x54, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0xb79cb800, ltk_data = 0x8dc23008, ltk_free = 0xb79cb8d0 <search_stack_free>}, {ltk_key = 0x82168f8, ltk_data = 0x3b, ltk_free = 0xb79d82e0 <bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>} tid = 2410843056 i = 636 hash = <value optimized out> #3 0xb7ca90bd in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #4 0xb7c3e01e in clone () from /lib/tls/libc.so.6 No symbol table info available. Thread 1 (Thread -1212823328 (LWP 30058)): #0 0xb7caa183 in pthread_join () from /lib/tls/libpthread.so.0 No symbol table info available. #1 0xb7f17894 in ldap_pvt_thread_join (thread=2755988400, thread_return=0x0) at /misc/src/net/openldap/libraries/libldap_r/thr_posix.c:193 No locals. #2 0x08067b06 in slapd_daemon () at /misc/src/net/openldap/servers/slapd/daemon.c:2579 listener_tid = 2755988400 rc = 0 #3 0x0805a309 in main (argc=9, argv=0xbf995694) at /misc/src/net/openldap/servers/slapd/main.c:859 save_errno = <value optimized out> fp = <value optimized out> i = 9 no_detach = 0 rc = 1 urls = 0x8140008 "ldap:/// ldaps:///" username = 0x8140030 "gidNumber" groupname = 0x8140020 "\202>É·°û\231·" sandbox = 0x0 syslogUser = 160 configfile = 0x8140040 "/etc/ldap/slapd.conf.master" configdir = 0x0 serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" #0 0xb7b9a947 in raise () from /lib/tls/libc.so.6 -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

(ITS#5616) Docs: various admin guide corrections
by jclarke＠linagora.org 16 Jul '08

16 Jul '08

Full_Name: Jonathan Clarke Version: OS: URL: http://milopita.phillipoux.net/jonathan-clarke-20080716.patch Submission from: (NULL) (213.41.243.192) Hi, Reading through the admin guide (checked out via CVS), I have come across a few typos and inconsistencies (missing words, chapter references, etc). The patch at the URL below includes some very simple corrections for these. Regards, Jonathan

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by quanah＠zimbra.com 15 Jul '08

15 Jul '08

--On Tuesday, July 15, 2008 6:43 AM +0000 fawadlateef(a)gmail.com wrote: > Thanks for your replies. > > By looking at RFC4533 AND slapo-accesslog I __don't__ think they can > be used against what my contributed overlay can do. > > The overlay actually monitors add/delete/modify operations based on > attributes/dn/classobject and if they matches it triggers event to the > URL (like interrupt). The accesslog DB writes out to the database add/delete/modify events, which logs attributes/dn/objectclasses. You could use any ldap sync listener to react to those, and do whatever it is you choose to have it do. This is exactly what Stanford University has used Net::LDAPapi to do, where it watches for group membership changes, and then performs actions on other enterprise applications based on those changes. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5615) Unix based auth (SASL/External) not working on solaris 10(patch included)
by admin＠dmarkey.com 15 Jul '08

15 Jul '08

Full_Name: David Markey Version: 2.4 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.97.241.103) here's the bug in liblutil/getpeereid.c #if defined( HAVE_GETPEERUCRED ) ucred_t *uc = NULL; if( getpeerucred( s, &uc ) == 0 ) { *euid = ucred_geteuid( uc ); *egid = ucred_getegid( uc ); ucred_free( uc ); } it's missing a "return 0;" after ucred_free. Thanks to Howard for spotting this and fixing it. Its going perfectly now. Tested on Solaris 10 and Nevada X86

1 0

RE: (ITS#5392) Some traces are lost
by emmanuel.duru＠atosorigin.com 15 Jul '08

15 Jul '08

As these traces are the traces generated by Statslog macro, is it possible to replace the definition of Statslog in case LDAP_DEBUG is defined and LDAP_SYSLOG is not, to use lutil_debug instead of fprintf (stderr) ? That is, in slap.h, replace [...] #elif defined(LDAP_DEBUG) #define Statslog( level, fmt, connid, opid, arg1, arg2, arg3 ) \ do { \ if ( ldap_debug & (level) ) \ fprintf( stderr, (fmt), (connid), (opid), (arg1), (arg2), (arg3) );\ } while (0) [...] with [...] #elif defined(LDAP_DEBUG) #define Statslog( level, fmt, connid, opid, arg1, arg2, arg3 ) \ do { \ if ( ldap_debug & (level) ) \ { \ lutil_debug( ldap_debug, (level), (fmt), (connid), (opid), (arg1), (arg2), (arg3) ); \ }\ } while (0) [...]

1 0

Re: (ITS#5584)
by abartlet＠samba.org 15 Jul '08

15 Jul '08

--=-OCQI7+YC0WINty5M6nQu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2008-07-01 at 02:49 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > --=3D-GddVbqVLc61XV3X/kWQ/ > > Content-Type: text/plain > > Content-Transfer-Encoding: quoted-printable > > > > I've uploaded the patch to http://abartlet.net/memberof.patch >=20 > I committed a different patch to HEAD. Please test. I just wanted to note that I have looked at this, but it seems that some other change in the meantime has meant that the invalid DN check is missed - in setting member attributes (I doubt it was ever intentional, but it allowed the test to proceed to this point). I may have to write a validation module on the Samba side for this, until we get this validation in OpenLDAP. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-OCQI7+YC0WINty5M6nQu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBIfJXiz4A8Wyi0NrsRAtHRAJ9fY0s6fkAI0I8OmcQUL6NeHxPuFQCglAQT TlftIPNYEIqc1o1j31dgNF0= =qwa/ -----END PGP SIGNATURE----- --=-OCQI7+YC0WINty5M6nQu--

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by michael＠stroeder.com 15 Jul '08

15 Jul '08

fawadlateef(a)gmail.com wrote: > > By looking at RFC4533 AND slapo-accesslog I __don't__ think they can > be used against what my contributed overlay can do. Judging from your description using syncrepl is __exactly__ what you need. Especially since some HTTP requests might get lost. > Now the thing is: in our case, the web-page is not used to display > modifications to users or on the browser __rather__ it perform some > operations on other enterprise applications based on the event > triggered from LDAP overlay hence polling kind of mechanism can't work > for us. Use syncrepl's refreshAndPersist mode. Also write your sync component in such a fashion that if connection is down for some times you can catch up with changes happened in between. Ciao, Michael.

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by fawadlateef＠gmail.com 15 Jul '08

15 Jul '08

Thanks for your replies. By looking at RFC4533 AND slapo-accesslog I __don't__ think they can be used against what my contributed overlay can do. The overlay actually monitors add/delete/modify operations based on attributes/dn/classobject and if they matches it triggers event to the URL (like interrupt). Now the thing is: in our case, the web-page is not used to display modifications to users or on the browser __rather__ it perform some operations on other enterprise applications based on the event triggered from LDAP overlay hence polling kind of mechanism can't work for us. We are going to use this overlay in our open-source-product "Zivios - Open Source Enterprise Management". Zivios will be used for management of all enterprise applications (like OpenLDAP, Kerberos, Mail-Server, Network Time Server etc) from a single web-based panel, so all modifications done through Zivios on LDAP will be made/reflected on other applications/servers at the same time. Now if somebody perform some operation on OpenLDAP directly (means by skipping Zivios) then Zivios should be triggered for such a change and then it can act on other servers accordingly. Thus event received by Zivios is __not__ for displaying data; rather its for doing some background processing although this overlay can be used to display LDAP operations on web too. Please suggest me someother way which can work on scenario mentioned above if my overlay isn't good enough. Let me know if overlay name or description isn't clear and is creating misundestanding about the functionality of the overlay. -- Fawad Lateef

1 0

Re: (ITS#5614) Ignore invalid search filters
by ando＠sys-net.it 15 Jul '08

15 Jul '08

hyc(a)symas.com wrote: > I don't think ldap_munge_filter() is adequate any more. Note that filter2bv > doesn't use (?=undefined) for unknown attributeTypes or illegal values any > more, it uses (?<attr>=<value>). This change was made to allow the log > messages to show what the actual offending values were. A better strategy here > may be to walk the Filter tree and look for > (f->f_choice&SLAPD_FILTER_UNDEFINED) before making the search request, so that > no retries are needed. That's what the new patch does, for example, for back-meta. However, we still need somehow to "unparse" the filter to allow those substitutions the proxy must honor, like "(?=true)", "(?=false)". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5614) Ignore invalid search filters
by hyc＠symas.com 14 Jul '08

14 Jul '08

ando(a)sys-net.it wrote: > andrew.graham(a)agustawestland.com wrote: > >> In line with the behavious specified in ITS 3785, any invalid search filter >> applied against back-meta will force a query including the search filter >> (!(objectClass=*)). As this filter can result in slow performance for certain >> brands of LDAP server, please provide an option to ignore invalid search filters >> in back-meta. > > A patch is in HEAD for back-ldap& back-meta. Use the "noundeffilter > {true|FALSE}" statement. Please test. p. I don't think ldap_munge_filter() is adequate any more. Note that filter2bv doesn't use (?=undefined) for unknown attributeTypes or illegal values any more, it uses (?<attr>=<value>). This change was made to allow the log messages to show what the actual offending values were. A better strategy here may be to walk the Filter tree and look for (f->f_choice&SLAPD_FILTER_UNDEFINED) before making the search request, so that no retries are needed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by quanah＠zimbra.com 14 Jul '08

14 Jul '08

--On Monday, July 14, 2008 9:04 PM +0000 hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> fawadlateef(a)gmail.com wrote: >> >>> Contributing an overlay which submits modification in LDAP to a >>> web-page through libcurl. >> >> Thanks for the contribution. Without having looked too much into the >> solution you designed, however, I believe you moved too much effort at >> the DSA side. An alternative approach to your problem consists in using >> the RFC4533 LDAP Sync to design a client that is persistently returned >> any change in data matching a search request, letting the client adapt >> the results into the desired form for the web page. The client could be >> easily embedded in a web server, e.g. using the scripting capabilities >> that most web servers have, or even coded using those scripting >> capabilities, provide they support the capability to implement the LDAP >> extensions used by RFC 4533. > > Actually, even without RFC4533, all that's needed is to use > slapo-accesslog and let the web server query the log DB whenever a user > accesses the page. -- Along Pierangelo's answer, I'll note that Net::LDAPapi perl module can be an LDAP sync client, and thus used to drive any number of things based off changes made to an accesslog DB. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by hyc＠symas.com 14 Jul '08

14 Jul '08

ando(a)sys-net.it wrote: > fawadlateef(a)gmail.com wrote: > >> Contributing an overlay which submits modification in LDAP to a web-page through >> libcurl. > > Thanks for the contribution. Without having looked too much into the > solution you designed, however, I believe you moved too much effort at > the DSA side. An alternative approach to your problem consists in using > the RFC4533 LDAP Sync to design a client that is persistently returned > any change in data matching a search request, letting the client adapt > the results into the desired form for the web page. The client could be > easily embedded in a web server, e.g. using the scripting capabilities > that most web servers have, or even coded using those scripting > capabilities, provide they support the capability to implement the LDAP > extensions used by RFC 4533. Actually, even without RFC4533, all that's needed is to use slapo-accesslog and let the web server query the log DB whenever a user accesses the page. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5614) Ignore invalid search filters
by ando＠sys-net.it 14 Jul '08

14 Jul '08

andrew.graham(a)agustawestland.com wrote: > In line with the behavious specified in ITS 3785, any invalid search filter > applied against back-meta will force a query including the search filter > (!(objectClass=*)). As this filter can result in slow performance for certain > brands of LDAP server, please provide an option to ignore invalid search filters > in back-meta. A patch is in HEAD for back-ldap & back-meta. Use the "noundeffilter {true|FALSE}" statement. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by ando＠sys-net.it 14 Jul '08

14 Jul '08

fawadlateef(a)gmail.com wrote: > Contributing an overlay which submits modification in LDAP to a web-page through > libcurl. Thanks for the contribution. Without having looked too much into the solution you designed, however, I believe you moved too much effort at the DSA side. An alternative approach to your problem consists in using the RFC4533 LDAP Sync to design a client that is persistently returned any change in data matching a search request, letting the client adapt the results into the desired form for the web page. The client could be easily embedded in a web server, e.g. using the scripting capabilities that most web servers have, or even coded using those scripting capabilities, provide they support the capability to implement the LDAP extensions used by RFC 4533. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5592) Quarantine in back-meta
by andrew.graham＠agustawestland.com 14 Jul '08

14 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I patched the changes into 2.4.10, quarantine now works perfectly. Thanks for yet another speedy response! Drew Andrew Graham AgustaWestland UK andrew.graham(a)agustawestland.com >>> <ando(a)sys-net.it> 12/07/2008 14:23 >>> andrew.graham(a)agustawestland.com wrote: > The quarantine function in back-meta will permanently disable a target if a > query is received while the quarantine has been imposed. Fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it ----------------------------------- *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

1 0

(ITS#5614) Ignore invalid search filters
by andrew.graham＠agustawestland.com 14 Jul '08

14 Jul '08

Full_Name: Andrew Graham Version: 2.4.10 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.169.32.250) In line with the behavious specified in ITS 3785, any invalid search filter applied against back-meta will force a query including the search filter (!(objectClass=*)). As this filter can result in slow performance for certain brands of LDAP server, please provide an option to ignore invalid search filters in back-meta.

1 0

(ITS#5613) slapd determines hostname by PTR even if host url defined, breaking ServerID
by joe＠julianfamily.org 14 Jul '08

14 Jul '08

Full_Name: Joe Julian Version: 2.4.10 OS: Linux (Fedora 7 distribution) URL: Submission from: (NULL) (68.178.24.202) Description of problem: slapd is called with "-h ldap://ldap1.domain.dom" where ldap1 is a CNAME for the actual server name "moe.domain.dom" and "-h ldap://ldap2.domain.dom" for "curly.domain.dom". The cn=config entries for olcServerID are "1 ldap://ldap1.domain.dom" and "2 ldap://ldap2.domain.dom" In config_generic (bconfig.c) case CFG_SERVERID lud->lud_host is compared with global_host. As the PTR record for moe is moe.domain.dom and not ldap1.domain.dom, moe does not get assigned a serverID. The same is true for curly. Version-Release number of selected component (if applicable): openldap_2.4.8 Steps to Reproduce: 1. configure a server's dns entries for the actual name of the server 2. configure a cname that's different 3. call slapd with "-h": the url referring to the cname of the server Actual results: no serverID defined Expected results: the serverID should be selected (in part) based on the "-h" url configuration matching an olcServerID entry

1 0

(ITS#5612) Contributing An Overlay which Submits Modification in LDAP to a Web-Page!
by fawadlateef＠gmail.com 14 Jul '08

14 Jul '08

Full_Name: Fawad Lateef Version: 2.4.10 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/fawadlateef-contrib-updopstoweb-080714.tgz Submission from: (NULL) (202.133.78.60) Contributing an overlay which submits modification in LDAP to a web-page through libcurl. Description: ------------ This package contains a slapd overlay, updopstoweb, that provides support for monitoring add/modify/delete operations performed on LDAP and sends the information related to operation going to be performed on LDAP to a web-site through libcurl api. It also provides support for specifying an IP address which will not be monitored, e.g. if you want to monitor operations from remote system then you can specify local-host IP and then it will ignore local-host operations. Monitoring of operations is based on dn, attributes and object classes which are provided through entries in slapd.conf file. Web-site URL and IP address for ignoring operations from are also provided to overlay through slapd.conf file. Although all these parameters can be provided at run-time through back-config. The overlay is tested on openldap-2.4.10 although it can work on any version of openldap-2.4 For details please consult README provided in the package

1 0

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by mbackes＠symas.com 14 Jul '08

14 Jul '08

> To further elaborate, even if the virtual DN is set instead of the > real one in c_ndn, the operation fails because ACL checking passes > through bi_entry_get_rw(), which is not provided by slapo-rwm, and > can't be provided according to the current design, since it does not > allow to massage the arguments. As a quick'n'dirty fix, what you > can do is make the proxy database serve both naming contexts, namely > > database ldap > suffix "dc=remote,dc=local" > suffix "dc=remote" This works for getting the query to the right place; thanks! Remapped attributes in the acl obviously don't work, but working around that is straight-forward also. > This is a hack; the real fix requires to redesign the API of > bi_entry_get_rw(), to let it modify the request arguments while > letting the real function do the hard job. Right, okay. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by ando＠sys-net.it 13 Jul '08

13 Jul '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> michael(a)stroeder.com wrote: >>> First this raises the question what to do if filters are not valid in >>> configuration. I'd prefer if slapo-constraint would cause invalidFilter >>> with an appropriate diagnosticMessage pointing to slapo-constraint >>> configuration to be returned instead of silently assuming the attribute >>> value is wrong. >> AFAIK, an invalid filter in the configuration would prevent slapd from >> starting, although right now checks are not that tight. > > ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit)) > > obviously contains an invalid filter. But slapd starts without complaining. OK, this type of error is not caught basically because no real check is done besides parsing the URI. I was more concerned about erroneous filters as a result of constructing the constraint filter. However, I notice that even in case of an incorrect filter, str2filter() will not fail, but rather generate a filter with erroneous terminal filters marked as erroneous, without complaining. Moreover, the internal search will return as successful but likely with no results. This is the expected behavior for a real search. So tracing an incorrect filter is not that obvious. >>> Still it does not work for me. The filter seems to be ok now and returns >>> the correct search result. But still the attribute value "Abteilung 1" >>> is not accepted. >> Can you provide the filter, the relevant data (or an excerpt of it) and >> the operation you're trying to perform? > > I could provide a complete canned config in a personal e-mail if you want. I'll let you know if that's needed. Maybe what you posted below is enough. p. > Just for the ITS: > > ---------------------- excerpt slapd.conf ---------------------- > overlay constraint > constraint_attribute gender regex ^[0129]?$ > constraint_attribute departmentNumber uri > ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit) > constraint_attribute manager uri > ldap:///ou=Managers,ou=schulung,dc=stroeder,dc=local?entryDN?one?(objectClass=inetOrgPerson) > ---------------------- entry to be modified ---------------------- > dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local > cn: Michael Stroeder > givenName: Michael > hasSubordinates: FALSE > objectClass: inetOrgPerson > sn: Stroeder > > ---------------------- modification operation ---------------------- > dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local > changetype: modify > add: departmentNumber > departmentNumber: Abteilung 1 > - > > ---------------------- departments ---------------------- > dn: ou=Departments,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Departments > > dn: ou=Abteilung 1,ou=Departments,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Abteilung 1 > > dn: ou=Abteilung 2,ou=Departments,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Abteilung 2 > > -------------------------------------------------------------- > > Ciao, Michael > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by michael＠stroeder.com 13 Jul '08

13 Jul '08

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> First this raises the question what to do if filters are not valid in >> configuration. I'd prefer if slapo-constraint would cause invalidFilter >> with an appropriate diagnosticMessage pointing to slapo-constraint >> configuration to be returned instead of silently assuming the attribute >> value is wrong. > > AFAIK, an invalid filter in the configuration would prevent slapd from > starting, although right now checks are not that tight. ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit)) obviously contains an invalid filter. But slapd starts without complaining. >> Still it does not work for me. The filter seems to be ok now and returns >> the correct search result. But still the attribute value "Abteilung 1" >> is not accepted. > > Can you provide the filter, the relevant data (or an excerpt of it) and > the operation you're trying to perform? I could provide a complete canned config in a personal e-mail if you want. Just for the ITS: ---------------------- excerpt slapd.conf ---------------------- overlay constraint constraint_attribute gender regex ^[0129]?$ constraint_attribute departmentNumber uri ldap:///ou=Departments,ou=schulung,dc=stroeder,dc=local?ou?one?(objectClass=organizationalUnit) constraint_attribute manager uri ldap:///ou=Managers,ou=schulung,dc=stroeder,dc=local?entryDN?one?(objectClass=inetOrgPerson) ---------------------- entry to be modified ---------------------- dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local cn: Michael Stroeder givenName: Michael hasSubordinates: FALSE objectClass: inetOrgPerson sn: Stroeder ---------------------- modification operation ---------------------- dn: cn=Michael Stroeder,ou=People,ou=schulung,dc=stroeder,dc=local changetype: modify add: departmentNumber departmentNumber: Abteilung 1 - ---------------------- departments ---------------------- dn: ou=Departments,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Departments dn: ou=Abteilung 1,ou=Departments,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Abteilung 1 dn: ou=Abteilung 2,ou=Departments,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Abteilung 2 -------------------------------------------------------------- Ciao, Michael

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by ando＠sys-net.it 12 Jul '08

12 Jul '08

michael(a)stroeder.com wrote: > Pierangelo Masarati wrote: >> michael(a)stroeder.com wrote: >> >>> Looking at the logs slapo-constraint seems to generate a filter which is >>> considered bad by slapd: >>> >>> constraint_violation uri filter = >>> (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) >>> >>> This filter would work and finds the correct entry containing the valid >>> attribute value: >>> (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) >> The overlay assumes you don't put brackets around your filter. This is >> now fixed in HEAD; please test. p. > > First this raises the question what to do if filters are not valid in > configuration. I'd prefer if slapo-constraint would cause invalidFilter > with an appropriate diagnosticMessage pointing to slapo-constraint > configuration to be returned instead of silently assuming the attribute > value is wrong. AFAIK, an invalid filter in the configuration would prevent slapd from starting, although right now checks are not that tight. > Still it does not work for me. The filter seems to be ok now and returns > the correct search result. But still the attribute value "Abteilung 1" > is not accepted. Can you provide the filter, the relevant data (or an excerpt of it) and the operation you're trying to perform? I just checked slapo-constraint, after fixing it, and it seemed to work as expected. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by michael＠stroeder.com 12 Jul '08

12 Jul '08

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: > >> Looking at the logs slapo-constraint seems to generate a filter which is >> considered bad by slapd: >> >> constraint_violation uri filter = >> (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) >> >> This filter would work and finds the correct entry containing the valid >> attribute value: >> (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) > > The overlay assumes you don't put brackets around your filter. This is > now fixed in HEAD; please test. p. First this raises the question what to do if filters are not valid in configuration. I'd prefer if slapo-constraint would cause invalidFilter with an appropriate diagnosticMessage pointing to slapo-constraint configuration to be returned instead of silently assuming the attribute value is wrong. Still it does not work for me. The filter seems to be ok now and returns the correct search result. But still the attribute value "Abteilung 1" is not accepted. Ciao, Michael. --------------------------------- snip --------------------------------- ==> constraint_violation uri filter = (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) put_filter: "(&(objectClass=organizationalUnit)(|(ou=Abteilung 1)))" put_filter: AND put_filter_list "(objectClass=organizationalUnit)(|(ou=Abteilung 1))" put_filter: "(objectClass=organizationalUnit)" put_filter: simple put_simple_filter: "objectClass=organizationalUnit" put_filter: "(|(ou=Abteilung 1))" put_filter: OR put_filter_list "(ou=Abteilung 1)" put_filter: "(ou=Abteilung 1)" put_filter: simple put_simple_filter: "ou=Abteilung 1" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=Departments,ou=schulung,dc=stroeder,dc=local") => hdb_dn2id("ou=Departments,ou=schulung,dc=stroeder,dc=local") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => access_allowed: disclose access to "ou=schulung,dc=stroeder,dc=local" "entry" requested <= root access granted => access_allowed: disclose access granted by manage(=mwrscxd) send_ldap_result: conn=1 op=28 p=3 send_ldap_result: err=10 matched="ou=schulung,dc=stroeder,dc=local" text="" ==> constraint_violation uri rc = 32, found = 0 send_ldap_result: conn=1 op=28 p=3 send_ldap_result: err=19 matched="" text="modify breaks constraint on departmentNumber" send_ldap_response: msgid=29 tag=103 err=19 ber_flush2: 58 bytes to sd 17 conn=1 op=28 RESULT tag=103 err=19 text=modify breaks constraint on departmentNumber

1 0

Re: (ITS#5609) slapo-constraint with typ 'uri' rejects valid attribute values
by ando＠sys-net.it 12 Jul '08

12 Jul '08

michael(a)stroeder.com wrote: > Looking at the logs slapo-constraint seems to generate a filter which is > considered bad by slapd: > > constraint_violation uri filter = > (&((objectClass=organizationalUnit))(|(ou=Abteilung 1))) > > This filter would work and finds the correct entry containing the valid > attribute value: > (&(objectClass=organizationalUnit)(|(ou=Abteilung 1))) The overlay assumes you don't put brackets around your filter. This is now fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5592) Quarantine in back-meta
by ando＠sys-net.it 12 Jul '08

12 Jul '08

andrew.graham(a)agustawestland.com wrote: > The quarantine function in back-meta will permanently disable a target if a > query is received while the quarantine has been imposed. Fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5599) slapd dies on erroneous MOD input
by ando＠sys-net.it 12 Jul '08

12 Jul '08

suomi(a)ayni.com wrote: > Full_Name: suomi hasler > Version: 2.4.8-3 > OS: fedora 9 > URL: http://www.ayni.com/slap-prob.txt > Submission from: (NULL) (194.158.243.162) Note that the current release is 2.4.10, and 2.4.11 is about to be released. I couldn't notice any issue in current code after performing erroneous modifications like the one you indicated. Please recheck with the latest release (the pre-release 2.4 from the CVS would be best). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs