openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by hyc＠symas.com 29 Nov '11

29 Nov '11

paul(a)scom.ca wrote: > Full_Name: Paul Kudla > Version: 2.4.23& 2.4.28 > OS: Freebsd 8.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.171.154.78) > > > Simply put openldap will not configure > > How do i get it to find the sql.h file > > checking number of arguments of ctime_r... 2 > checking number of arguments of gethostbyname_r... 6 > checking number of arguments of gethostbyaddr_r... 8 > checking for openlog... yes > checking sql.h usability... no > checking sql.h presence... no > checking for sql.h... no > configure: error: could not locate SQL headers > > installed UnixODBC version unixODBC-2.3.1 > > > [00:28:54] root@ldap /usr/local/src/openldap-2.4.23 > # ll /usr/local/include/sql.h > -rw-r--r-- 1 root wheel 32305 Nov 28 11:58 /usr/local/include/sql.h > > [00:34:18] root@ldap /usr/local/src/openldap-2.4.23 > # > > this issue googles alot without any clear explanation. > > have no problem contributing to the cause - let me know how. Read the INSTALL document. Set the CPPFLAGS variable correctly. No bug here, closing this ITS. > > -- -- 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#7099) slapadd segfaults with back-mdb and slapo-dds
by dieter＠dkluenter.de 29 Nov '11

29 Nov '11

Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) back-mdb tries to read entry databases prior to initialisation, which leeds to segmatation fault output of slapadd -d-1 [...] 4ed4888e slapadd startup: initiated. 4ed4888e backend_startup_one: starting "o=avci,c=de" 4ed4888e mdb_db_open: "o=avci,c=de" 4ed4888e mdb_db_open: database "o=avci,c=de": dbenv_open(/home/dieter/openldap/var/ldap-dds). 4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))" 4ed4888e begin get_filter 4ed4888e AND 4ed4888e begin get_filter_list 4ed4888e begin get_filter 4ed4888e EQUALITY 4ed4888e end get_filter 0 4ed4888e begin get_filter 4ed4888e LE 4ed4888e end get_filter 0 4ed4888e end get_filter_list 4ed4888e end get_filter 0 Speicherzugriffsfehler the appropriate slapo-dds configuration: [...] overlay dds dds-max-ttl 86400 dds-min-ttl 0 dds-default-ttl 3600 dds-interval 1800 dds-tolerance 60 dds-max-dynamicObjects 100 dds-state TRUE [...] -Dieter

1 0

(ITS#7098) OpenLDAP crashes when changing OID value in schema definition in cn=config
by nick＠eurobjects.com 29 Nov '11

29 Nov '11

Full_Name: Nikolaos Milas Version: 2.4.26 (LTB RPM) OS: CentOS 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.251.204.222) We use the following schema (among others): DN: cn={5}postfix,cn=schema,cn=config objectClass: olcSchemaConfig cn: {5}postfix olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser' DESC 'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive' DESC 'A flag, for marking the alias as not in use' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount' DESC 'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $ mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $ aliasInactive ) ) olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC 'Virtual account for holding mailing list info' STRUCTURAL MUST ( mailacceptinggeneralid $ maildrop $ cn ) MAY ( owner $ description $ aliasInactive ) ) olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC 'Email account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $ cn ) MAY ( mailacceptinggeneralid $ aliasInactive ) ) olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC 'Mailbox for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY description ) We run: # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange1 where /root/work/schemachange1: dn: cn={5}postfix,cn=schema,cn=config changetype: modify delete: olcAttributeTypes olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - add: olcAttributeTypes olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) This is successful: [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange1 ldap_initialize( ldap://localhost ) Enter LDAP Password: delete olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) add olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) modifying entry "cn={5}postfix,cn=schema,cn=config" modify complete However, then we try to run: # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange2 where /root/work/schemachange2: dn: cn={5}postfix,cn=schema,cn=config changetype: modify delete: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) - add: olcAttributeTypes olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) and this causes an OpenLDAP crash: [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D "cn=admin,cn=config" -f /root/work/schemachange2 ldap_initialize( ldap://localhost ) Enter LDAP Password: delete olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) add olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) modifying entry "cn={5}postfix,cn=schema,cn=config" This hangs, and we interrupt with Ctrl-C. gdb reports: ------------------------------------------- (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42e54940 (LWP 4089)] 0x000000000047ab0c in at_next (at=0x42e51418) at at.c:366 366 *at = LDAP_STAILQ_NEXT(*at,sat_next); (gdb) backtrace full #0 0x000000000047ab0c in at_next (at=0x42e51418) at at.c:366 __PRETTY_FUNCTION__ = "at_next" #1 0x000000000042c816 in config_generic (c=0x42e51610) at bconfig.c:1667 i = 0 at = 0x0 prev = 0x0 i = <value optimized out> __PRETTY_FUNCTION__ = "config_generic" #2 0x00000000004317eb in config_set_vals (Conf=0x81e1e0, c=0x42e51610) at config.c:334 rc = <value optimized out> arg_type = 0 ptr = <value optimized out> #3 0x00000000004355fd in config_parse_add (ct=0x81e1e0, c=0x42e51610, valx=<value optimized out>) at config.c:678 rc = <value optimized out> #4 0x0000000000427fe9 in config_modify_add (ct=0x81e1e0, ca=0x42e51610, ad=<value optimized out>, i=1) at bconfig.c:5420 rc = <value optimized out> #5 0x000000000042a486 in config_modify_internal (op=0x13086920, rs=0x42e53c20) at bconfig.c:5689 a = <value optimized out> colst = 0x131f7f80 dels = <value optimized out> ml = <value optimized out> e = 0x12955548 rc = <value optimized out> oc_at = <value optimized out> s = 0x12d56d48 ct = 0x81e1e0 i = 2 nocs = 2 #6 config_back_modify (op=0x13086920, rs=0x42e53c20) at bconfig.c:5802 cfb = 0x82a640 ce = <value optimized out> last = <value optimized out> ml = <value optimized out> ca = {argc = 19, argv = 0x131f5120, argv_size = 513, line = 0x132030b3 "( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )", tline = 0x13203ce0 "(", fname = 0x587799 "slapd", lineno = 0, log = "olcAttributeTypes: value #1", '\000' <repeats 4096 times>, reply = {err = 0, msg = "\000lcAttributeTypes: Duplicate attributeType: \"1.3.6.1.4.1.25260.1.0\"", '\000' <repeats 188 times>}, depth = 0, valx = 1, values = { v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x0}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 25, ca_op = 0x13086920, be = 0x82c1a0, bi = 0x0, ca_entry = 0x12955548, ca_private = 0x129aeaf0, cleanup = 0, table = Cft_Schema} ---Type <return> to continue, or q <return> to quit--- rdn = {bv_len = 2, bv_val = 0x129dac10 "cn={5}postfix,cn=schema,cn=config"} rad = 0x12903de0 do_pause = 1 #7 0x0000000000452a07 in fe_op_modify (op=0x13086920, rs=0x42e53c20) at modify.c:303 repl_user = <value optimized out> bd = 0x82c1a0 textbuf = "@\270\220\022", '\000' <repeats 12 times>, "@\270\220\022\000\000\000\000\316YE\000\000\000\000\000\260\u01dd\022\000\000\000\000\260[\217\022\000\000\000\000\002\000\000\000\000\000\000\000\262\u01dd\022\000\000\000\000\001\000\000\000\000\000\000\000\261\u01dd\022\000\000\000\000\003\000\000\000\000\000\000\000\260\u01dd\022\000\000\000\000\260\000\000\000\000\000\000\000\060~\037\023", '\000' <repeats 20 times>, " u\037\023", '\000' <repeats 12 times>"\360, \271\220\022\000\000\000\000 ", '\000' <repeats 15 times>, "\023$E\000\000\000\000\000\300\312\005\023\000\000\000\000\000\001\000\000\000\000\000\000\320:\345B\000\000\000\000@<\345B\000\000\000\000 i\b\023\000\000\000\000\001\000\000\000\000\000\000\000Xi\b\023\000\000\000\000Hi\b\023\000\000\000\000\300\312\005\023\000\000\000\000\311"... #8 0x0000000000453172 in do_modify (op=0x13086920, rs=0x42e53c20) at modify.c:177 dn = {bv_len = 33, bv_val = 0x13202669 "cn={5}postfix,cn=schema,cn=config"} textbuf = "\327k\b\023", '\000' <repeats 52 times>"\273, (\207?9\000\000\000\000\000\037\023", '\000' <repeats 16 times>, "\001\000\000\000\260\200\037\023", '\000' <repeats 12 times>"\211, \331\000@9", '\000' <repeats 11 times>"\365, \377\377\377\377\377\377\377oy\037\023\000\000\000\000\b\000\000\000\000\000\000\000H:\265?9\000\000\000\251oW", '\000' <repeats 13 times>"\361, \001\000\000\000\000\000\000\333\001\000\000\000\000\000\000@\000\000\000\000\000\000\000H:\265?9\000\000\000\020<\345B", '\000' <repeats 12 times>, "!\000\000\000\000\000\000\000\023\000\000\000\000\000\000\000v\277H\000\000\000\000\000\020o\030\023\000\000\000\000\200g\270\022\000\000\000" tmp = 0x0 #9 0x000000000043b965 in connection_operation (ctx=0x42e53d70, arg_v=<value optimized out>) at connection.c:1138 rc = <value optimized out> cancel = <value optimized out> op = 0x13086920 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = { r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x12b86780 memctx = 0x1305cac0 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043bf3f in connection_read_thread (ctx=0x42e53d70, argv=<value optimized out>) at connection.c:1274 s = 31 #11 0x000000000054d68c in ldap_int_thread_pool_wrapper (xpool=0x12907380) at tpool.c:685 task = 0x12e1b240 work_list = <value optimized out> ctx = {ltu_id = 1122322752, ltu_key = {{ltk_key = 0x43a8d0, ltk_data = 0x1305c9b0, ltk_free = 0x43a9a0 <conn_counter_destroy>}, {ltk_key = 0x48c440, ltk_data = 0x1305cac0, ltk_free = 0x48c320 <slap_sl_mem_destroy>}, {ltk_key = 0x12b25e30, ltk_data = 0x1305cce0, ltk_free = 0x4e0010 <bdb_reader_free>}, {ltk_key = 0x44e220, ltk_data = 0x0, ltk_free = 0x44e000 <slap_op_q_destroy>}, {ltk_key = 0x0, ---Type <return> to continue, or q <return> to quit--- ltk_data = 0x131f5120, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = <value optimized out> keyslot = 976 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x000000394000673d in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x000000393f8d44bd in clone () from /lib64/libc.so.6 No symbol table info available. -------------------------------------------

1 0

Re: (ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by quanah＠zimbra.com 28 Nov '11

28 Nov '11

--On Tuesday, November 29, 2011 12:35 AM +0000 paul(a)scom.ca wrote: > this issue googles alot without any clear explanation. Read your config.log file that is generated to see why it doesn't like the sql.h file. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by paul＠scom.ca 28 Nov '11

28 Nov '11

Full_Name: Paul Kudla Version: 2.4.23 & 2.4.28 OS: Freebsd 8.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.171.154.78) Simply put openldap will not configure How do i get it to find the sql.h file checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking for openlog... yes checking sql.h usability... no checking sql.h presence... no checking for sql.h... no configure: error: could not locate SQL headers installed UnixODBC version unixODBC-2.3.1 [00:28:54] root@ldap /usr/local/src/openldap-2.4.23 # ll /usr/local/include/sql.h -rw-r--r-- 1 root wheel 32305 Nov 28 11:58 /usr/local/include/sql.h [00:34:18] root@ldap /usr/local/src/openldap-2.4.23 # this issue googles alot without any clear explanation. have no problem contributing to the cause - let me know how.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah＠zimbra.com 25 Nov '11

25 Nov '11

--On Friday, November 25, 2011 10:15 AM +0000 michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> hyc(a)symas.com wrote: >>>>> You don't have to teach me anything in the testing field. >>>> >>>> Clearly I *do* need to, based on the completely useless content-free >>>> emails you've posted so far. >>> >>> Maybe then you should learn to read. The cause was already mentioned in >>> a message before. I did not expect that you are not able to generate >>> test data not in tree order yourself. >> >> You're assuming I've been sitting on my ass waiting for your followups. > > Well, and you assume that I have endless spare times tracking down bugs. I > don't. Especially at the current moment. Hi Michael, No one assumed any such thing. All that was every requested from you was information that only you had. The information on how exactly to reproduce this issue that you found, because no one else was able to reproduce with the information you had provided. Now that you finally provided the requisite information, someone *else* was able to track down and fix the actual bug. It is very unfortunate that you find requests for information to be so tedious. Having to continually request basic information from you is also quite tedious. If you could just provide the requisite information up front, then entire situations like this could be entirely avoided. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 25 Nov '11

25 Nov '11

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> hyc(a)symas.com wrote: >>>> You don't have to teach me anything in the testing field. >>> >>> Clearly I *do* need to, based on the completely useless content-free emails >>> you've posted so far. >> >> Maybe then you should learn to read. The cause was already mentioned in a >> message before. I did not expect that you are not able to generate test data >> not in tree order yourself. > > You're assuming I've been sitting on my ass waiting for your followups. Well, and you assume that I have endless spare times tracking down bugs. I don't. Especially at the current moment. Ciao, Michael.

1 0

Re: (ITS#7096) Make depend error on redhat 6 with OpenLDAP 2.3.43
by h.b.furuseth＠usit.uio.no 25 Nov '11

25 Nov '11

llx88217(a)126.com writes: > Version: OpenLDAP 2.3.43 > In file included from slurp.h:53, > from ri.c:45: > ../../include/ldap_pvt_thread.h:64:7: error: missing binary operator before > token "(" OpenLDAP 2.3 is not under development, please check bugs against the latest release before reporting. This one is ITS#5824, fixed in by commit debfd2d796fd47481e077dff97fb38b21b030af7 in the Git repository. -- Hallvard

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 25 Nov '11

25 Nov '11

michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >>> You don't have to teach me anything in the testing field. >> >> Clearly I *do* need to, based on the completely useless content-free emails >> you've posted so far. > > Maybe then you should learn to read. The cause was already mentioned in a > message before. I did not expect that you are not able to generate test data > not in tree order yourself. You're assuming I've been sitting on my ass waiting for your followups. I fed a number of unordered LDIFs into slapadd and the problem never surfaced. -- -- 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#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 25 Nov '11

25 Nov '11

hyc(a)symas.com wrote: >> You don't have to teach me anything in the testing field. > > Clearly I *do* need to, based on the completely useless content-free emails > you've posted so far. Maybe then you should learn to read. The cause was already mentioned in a message before. I did not expect that you are not able to generate test data not in tree order yourself. Ciao, Michael.

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