openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

22 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 22 Jul '08

22 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs