openldap-bugs February 2012

openldap-bugs@openldap.org

33 participants
146 discussions

(ITS#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com 28 Feb '12

28 Feb '12

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120228-back-ldap-monitoring… Submission from: (NULL) (62.168.56.1) I have prepared some patches to back-ldap (and one to back-monitor) that expose operation and connection monitoring information from a running back-ldap database and I would like to see this or similar functionality included in the OpenLDAP codebase. The url above contains a patchset against HEAD for review. The following things are yet to be resolved: - there is no monitoring of completed operations yet, only operations initiated against the remote database(s). - the binds performed by the ldap_back_default_rebind function are not counted - slapo-chain has not been tested yet - test suite integration: back-ldap looks excluded from the test suite - better connection handling (connections should have stable identifiers) The obligatory license clause follows: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

RE: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by Petteri.Stenius＠ubisecure.com 27 Feb '12

27 Feb '12

Hello, I run into this same issue. However the segfault only happens if the dds overlay is defined before the syncprov overlay in slapd.conf. Br, Petteri Stenius -----Original Message----- From: openldap-bugs-bounces(a)OpenLDAP.org [mailto:openldap-bugs-bounces@OpenLDAP.org] On Behalf Of dieter(a)dkluenter.de Sent: 30. marraskuuta 2011 12:12 To: openldap-its(a)openldap.org Subject: (ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) slapd crashes with segmentation fault on a slapo-dds refresh operation, if syncprov is enabled and configured (gdb) bt #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 #4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:915 #5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:237 #6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:177 #7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60, arg_v=0x7f01d8013530) at connection.c:1138 #8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10) at connection.c:1274 #9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at tpool.c:685 #10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at pthread_create.c:297 #11 0x00007f01f3c1166d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { (gdb) frame 1 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 1793 slap_get_commit_csn( op, &maxcsn, &foundit ); (gdb) frame 2 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 505 rc = op->o_callback->sc_response( op, rs ); (gdb) frame 3 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 580 rc = slap_response_play( op, rs ); (gdb) -Dieter

1 0

Re: (ITS#7181) off by 2 error in --ldif-wrap
by hyc＠symas.com 25 Feb '12

25 Feb '12

Hallvard B Furuseth wrote: > On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> The client option --ldif-wrap=N outputs lines of N+2 columns. >>> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. >> >> Not a bug. See libldap/ldif.c:490. > > That's old an internal matter, exposed as default wrap width 78 > instead of rfc2849's max 76. > > This ITS is about the new --ldif-wrap option. The tools can just > subtract 2 from the input value and otherwise keep the current code. But then the tools will be wrong when we fix the library. > (I do think we should throw away the old bug-compat code and > fix the default 78 to 76, but not in RE24. And I note the bug- > compat comment claims it's off by 1 while it's actually 2:) Sure, I'd like to throw that all out too. But in the meantime, I'd rather not have the tools' functionality change twice over the same issue. (I.e., fix the tools now, then fix the libraries later and have to re-fix the tools.) -- -- 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#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no 24 Feb '12

24 Feb '12

On Sat, 25 Feb 2012 00:19:11 GMT, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> The client option --ldif-wrap=N outputs lines of N+2 columns. >> E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. > > Not a bug. See libldap/ldif.c:490. That's old an internal matter, exposed as default wrap width 78 instead of rfc2849's max 76. This ITS is about the new --ldif-wrap option. The tools can just subtract 2 from the input value and otherwise keep the current code. (I do think we should throw away the old bug-compat code and fix the default 78 to 76, but not in RE24. And I note the bug- compat comment claims it's off by 1 while it's actually 2:) -- Hallvard

1 0

Re: (ITS#7181) off by 2 error in --ldif-wrap
by hyc＠symas.com 24 Feb '12

24 Feb '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.29 > OS: Linux x86_64 > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > The client option --ldif-wrap=N outputs lines of N+2 columns. > E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output. Not a bug. See libldap/ldif.c:490. -- -- 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#7180) libmdb assertion error on slapadd
by quanah＠zimbra.com 24 Feb '12

24 Feb '12

--On Thursday, February 23, 2012 5:42 PM +0000 quanah(a)OpenLDAP.org wrote: >#################### 100.00% eta none elapsed none fast! > slapadd: ../../../libraries/libmdb/mdb.c:3827: mdb_cursor_get: Assertion > `mc' failed. > Aborted This is specifically triggered the flags used with slapadd: /opt/zimbra/openldap/sbin/slapadd -q -w -b '' -F /opt/zimbra/data/ldap/config -cv -l /tmp/ldap.bak Specifically the "-w" flag is what triggers it. No error occurs without -w. Thread 1 (Thread 0x7ffff7fef700 (LWP 25466)): #0 0x00007ffff6372a75 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007ffff63765c0 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007ffff636b941 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x00007ffff38432d0 in mdb_cursor_get (mc=0x0, key=0x7ffff3a53eb0, data=0x7ffff3a53ec0, op=MDB_SET) at ../../../libraries/libmdb/mdb.c:3827 rc = 1301783142 exact = 0 __PRETTY_FUNCTION__ = "mdb_cursor_get" #4 0x00007ffff381c4db in mdb_tool_entry_get_int (be=0x8ff470, id=0, ep=0x7fffffffe568) at tools.c:323 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = { rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = { bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_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}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = { bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} e = 0x0 dn = {bv_len = 0, bv_val = 0x0} ndn = {bv_len = 0, bv_val = 0x0} rc = 32767 __PRETTY_FUNCTION__ = "mdb_tool_entry_get_int" #5 0x00007ffff381c72d in mdb_tool_entry_get (be=0x8ff470, id=0) at tools.c:373 e = 0x0 #6 0x00000000004db69a in slap_tool_update_ctxcsn (progname=0x51a020 "slapadd", sid=18446744073709551615, bvtext=0x7fffffffe6c0) at slapcommon.c:1004 ctxdn = {bv_len = 0, bv_val = 0x8d1c50 ""} ctxcsn_id = 0 ctxcsn_e = 0x75ff68 rc = 0 __PRETTY_FUNCTION__ = "slap_tool_update_ctxcsn" #7 0x00000000004d8ecb in slapadd (argc=10, argv=0x7fffffffea18) at slapadd.c:472 textbuf = '\000' <repeats 255 times> textlen = 256 erec = {e = 0x7ebf68, lineno = 2857, nextline = 2857} bvtext = {bv_len = 256, bv_val = 0x7fffffffe700 ""} thr = 0 id = 73 ldifrc = 0 rc = 0 stat_buf = {st_dev = 64256, st_ino = 1441881, st_nlink = 1, st_mode = 33184, st_uid = 1001, st_gid = 1001, __pad0 = 0, st_rdev = 0, st_size = 115070, st_blksize = 4096, st_blocks = 232, st_atim = {tv_sec = 1330122358, tv_nsec = 391982437}, st_mtim = {tv_sec = 1330122344, tv_nsec = 272000000}, st_ctim = {tv_sec = 1330122346, tv_nsec = 832002048}, __unused = {0, 0, 0}} #8 0x0000000000415910 in main (argc=10, argv=0x7fffffffea18) at main.c:410 i = 0 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 0 waitfds = {3817984, 0} g_argc = 10 g_argv = 0x7fffffffea18 configfile = 0x0 configdir = 0x0 serverName = 0x7fffffffec9d "slapadd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f95e8 "" l = 140737488349422 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" (gdb) -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7181) off by 2 error in --ldif-wrap
by h.b.furuseth＠usit.uio.no 23 Feb '12

23 Feb '12

Full_Name: Hallvard B Furuseth Version: 2.4.29 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard The client option --ldif-wrap=N outputs lines of N+2 columns. E.g. 'ldapsearch -o ldif-wrap=20 ...' gives 22-column output.

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by hyc＠symas.com 23 Feb '12

23 Feb '12

h.b.furuseth(a)usit.uio.no wrote: > On Thu, 23 Feb 2012 20:31:09 GMT, hyc(a)symas.com wrote: >> It seems unnecessary to document ldif-wrap in all of the commands, >> since only ldapsearch actually produces LDIF output. > > No, controls can also request LDIF output. E.g. > ldapmodify -e preread -o ldif-wrap=20 > wraps after column... 22?? New ITS coming up. > OK, in that case I don't see any reason to tweak that part of the patch. -- -- 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#7177) [PATCH] various manpage fixes
by h.b.furuseth＠usit.uio.no 23 Feb '12

23 Feb '12

On Thu, 23 Feb 2012 20:31:09 GMT, hyc(a)symas.com wrote: > It seems unnecessary to document ldif-wrap in all of the commands, > since only ldapsearch actually produces LDIF output. No, controls can also request LDIF output. E.g. ldapmodify -e preread -o ldif-wrap=20 wraps after column... 22?? New ITS coming up. -- Hallvard

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by jvcelak＠redhat.com 23 Feb '12

23 Feb '12

> It seems unnecessary to document ldif-wrap in all of the commands, > since only > ldapsearch actually produces LDIF output. The option isn't relevant > for any of > the others. I know. Feel free to modify the changes as you wish. I just wanted to make the man page consistent across all tools, because the description of "-o" displayed with "ldaptool --help" is always the same. Jan

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2012