- openldap-bugs - openldap.org

(ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 29 Nov '11

29 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.15.82) As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a dynamicObject entry. But slapo-dds always returns the same value for entryTTL (last refreshTTL). Another server implementation returns decreasing values for entryTTL which would be IMO the correct behaviour.

1 0

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

Re: (ITS#7090) back-mdb produces wrong slapcat output
by masarati＠aero.polimi.it 25 Nov '11

25 Nov '11

On 11/25/2011 09:31 AM, hyc(a)symas.com wrote: > this and the typos in back-sql On a related note, I merely found those typos by building back-sql statically, as it wouldn't allow slapd to start. I haven't tested its functionality yet. Sorry for this, too busy. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

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

25 Nov '11

Michael Ströder wrote: > Howard Chu wrote: >> One crucial step in isolating the problem would be to determine if the error >> actually occurs during slapadd or slapcat. > > I revise my statement that data looks ok via LDAP. Messing up the data seems > to happen during slapadd if the LDIF is not in tree order (as already > suspected in a former posting which was not read I guess). > > Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is > in tree order while in data1.ldif subordinate entries come before their > superior entries (which is what slapcat sometimes produce). Interestingly enough, my results differed from yours. Also the results differed depending on whether I slapadd'd the bare LDIF, or an LDIF with all operational attributes included. But this is now fixed in git master. Given this and the typos in back-sql it appears we should scratch 2.4.27 and push a new release. > These entries > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Groups > > dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 > > get mixed into that: > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > hasSubordinates: TRUE > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 -- -- 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 hyc＠symas.com 24 Nov '11

24 Nov '11

Michael Ströder wrote: > Howard Chu wrote: >> One crucial step in isolating the problem would be to determine if the error >> actually occurs during slapadd or slapcat. > > I revise my statement that data looks ok via LDAP. Messing up the data seems > to happen during slapadd if the LDIF is not in tree order (as already > suspected in a former posting which was not read I guess). > > Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is > in tree order while in data1.ldif subordinate entries come before their > superior entries (which is what slapcat sometimes produce). > > These entries > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > objectClass: organizationalUnit > ou: Groups > > dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 > > get mixed into that: > > dn: ou=Groups,ou=schulung,dc=stroeder,dc=local > cn: slapd-1 > hasSubordinates: TRUE > objectClass: applicationProcess > objectClass: simpleSecurityObject > userPassword: pw_slapd1 > >> Bug-hunting takes systematic, methodical testing. You can't just go changing >> revisions willy-nilly. > > 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. > Again: Your arrogant attitude does not help at all. It solely frustrates > people who are trying to help even if they don't have much spare time left. The only person copping an attitude here is you. I'm simply asking you for information that would help point to the problem; you're choosing to ignore my questions until I make a point of re-asking. Thank you for the test data. -- -- 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#7096) Make depend error on redhat 6 with OpenLDAP 2.3.43
by llx88217＠126.com 24 Nov '11

24 Nov '11

Full_Name: llx Version: OpenLDAP 2.3.43 OS: redhat 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.37.47.42) configuration is successfully, and run "make depend" this error prompt: In file included from slurp.h:53, from ri.c:45: ../../include/ldap_pvt_thread.h:64:7: error: missing binary operator before token "("

1 0

(ITS#7095) Make depend error on redhat 6 with OpenLDAP 2.3.43
by llx88217＠126.com 24 Nov '11

24 Nov '11

Full_Name: llx Version: OpenLDAP 2.3.43 OS: redhat 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.37.47.42) configuration is successfully, and run "make depend" this error prompt: In file included from slurp.h:53, from ri.c:45: ../../include/ldap_pvt_thread.h:64:7: error: missing binary operator before token "("

1 0

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

24 Nov '11

This is a multi-part message in MIME format. --------------000109050706000504040005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Howard Chu wrote: > One crucial step in isolating the problem would be to determine if the error > actually occurs during slapadd or slapcat. I revise my statement that data looks ok via LDAP. Messing up the data seems to happen during slapadd if the LDIF is not in tree order (as already suspected in a former posting which was not read I guess). Try to slapadd data1.ldif and data2.ldif in the tar.gz attached. data2.ldif is in tree order while in data1.ldif subordinate entries come before their superior entries (which is what slapcat sometimes produce). These entries dn: ou=Groups,ou=schulung,dc=stroeder,dc=local objectClass: organizationalUnit ou: Groups dn: cn=slapd-1,ou=Systemkonten,ou=schulung,dc=stroeder,dc=local cn: slapd-1 objectClass: applicationProcess objectClass: simpleSecurityObject userPassword: pw_slapd1 get mixed into that: dn: ou=Groups,ou=schulung,dc=stroeder,dc=local cn: slapd-1 hasSubordinates: TRUE objectClass: applicationProcess objectClass: simpleSecurityObject userPassword: pw_slapd1 > Bug-hunting takes systematic, methodical testing. You can't just go changing > revisions willy-nilly. You don't have to teach me anything in the testing field. Again: Your arrogant attitude does not help at all. It solely frustrates people who are trying to help even if they don't have much spare time left. Get real. How many people do you think are really testing such a wide range of OpenLDAP functionality like me? How many people you expect to thoroughly test back-mdb within the next six months even if released in 2.4.27? How many people do you expect to really dive into such problems? Most people will just use another backend or another LDAP server. Ciao, Michael. --------------000109050706000504040005 Content-Type: application/x-gzip; name="openldap-testbed-its7090.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="openldap-testbed-its7090.tar.gz" H4sICIz/zU4CA29wZW5sZGFwLXRlc3RiZWQtaXRzNzA5MC50YXIA7RxrU9tIkq/Wr5gzuSvI MrY0elPl2mKBJOwR4DDZy2ZzlRppRrYuep1GWiCP/349ku2YsAQwNsrdaqggeaTpnn53D+2k GU8iRjNccFF4nOGwELbqqv215Q0Vhq2q9dUyqqtm1NfJWNM0y9J12zYsaw0e2pa+hsy1Rxil KGiO0Foc+mPKo2+8x3Ox9n830pvkH4siTznjeS9iYfBg+VsTef+R/IlBpPwJMUybaATkb1ua tYbUVv4rHyzZRmXIBjNxb6Xl4JWkVd4If1xGZTLaYv5g9gLcR6lPIwXWbaPZQiX1/s39Yjei QmyjMOHFcT46AUBpoviA5WXNYDScvi9gcvZBsvcEVp6nOQCVyii4n/NCUdba0YT9M1pQ7eG2 P7P/m/0/sWxz6v8twzLB/i2L2K39P5b932roVyw7zUc0CT/QIkwTGr1KwkJJy200haAoE5An aRT6Ib+DH7kL+Cm0GXgR0SzFWSbnL7eWj2/ii75CXLnKWlPu7SjrZVexU99Py6S4OinCOIv4 kPtlHhaXx9WjbzjICUPuuJe7EF+BqgH7ScVphjUJengpCh6/T5OCJ7ejkl5/svgrqrMMmFph PclTnwtxbwZk5+8q0NpX2yQP2SZZ2TbJTEz329tdpDUPcYbmeZ6W2ZLUoYY1Y/QOi8OkAn1X JJLDM4Oql19FPJKAjoMjGoOhxTz2eL6orU13ecor4d1rn1PMD1H6azAW1Mjp/r/BKGWV8V+G xQJXJPTEeKX1n6XP6j+T2FX+b5pqG/8fY6z/pe+FSV+MFeX4ZP/ocG/n5N3J6f6zg9eDbj/N iv5MQU73idFVDo93dw53j4+eHTyHF8ZpzPsTzvVBwbP+TfrUVZR1hDBDfpoE4WgLuF6I+jfZ on60RfOR2Cpy6vMtcZn46K2iPPn41ZY+96PQ4xfc71d6Ce/cDPILuIz673kh6rfHqCu3t93v q73qZ5uotobkXAiTfyXPJE1wmVAFd5IuuNxEGTyqDV2kEk+3xpNMQsrkpXqynCYB9ccAPfk4 x8/PNVU9SY7SeP4/9VA4hDAQ0gjXxUDPo++XW/9rmq2Rmf2bNvgJQqAqaO3/fzP/h+WlX5Q5 jY5vWcaTIr989epgbxuZRFcN6jmYebaDDdOzMA14gE3NtlQ94KpvcwXSXVqkuZDRr04PWJhT Ft8hoMqV/CyEqFnQONtGBNRO04ihOqplkjf1VnaHR18/6RFTMx33zXqtq+uTfzCUOAVzCPki 26mWXn5jOyuuoRYSkaebKg1Uim3CPGxAkMYUSnfsceJ5nmk5hq82IiJd6ojTlIgevQ6tjG0e 6WLiNAgllHEHU1uj2LADB7uqE2DH1AmxWeBrtCFxOoatG02Jc+lV9ELCcbjlOk7gYdvQVGxQ 1cOOTQkOgkCngW4xkFQjwjEsoqlqI8L5To5ethF7/ssH9uIo+lX/OWI7g8FNIp4imJOrTTSu ux44TebbYHSahz3iWNgnhLuO5hsBNRqRq6m7rqU2ZXQrPhNZyAQDyj1mUw3rKtOxASkp9igh WFUNnRHuUdWhjYjK0mxbJY2IajmHgWSVB4OwyRcQvMjF2H/+j4sbTfM6njnRWx61mWuCbbqu jw3XIphybmPuqnZgOwELVK8Z0ZtQNmnNiv77OmC9Iu7LxcRNuW/brqphn/sWNixmYk+HYGsS zTRVz4Dao5lga6uW65KmnPIKTpAXcsS2Y1IbYiPmasBkaUixo9kq5EK+5ZrAIth7M+JxDNdw mrLG5ZzCy7kVH8jfIPQrGObEzXSDM0cHayQW1CXc0bEbOCYONIuCIri2x5uJu6B0rmo1Je4/ wZ8z7qkokJ1ZDg84NhymQZRmPkRpSNW4ZgVWoAdcs7VGFMXVbEd9/AJ2Bf0f5PH7P6rzX9n/ Ybbnv23/x3fX/7GyPovvuLHkMToW2jaTJbeZtP0fbf/Hw+K/t7SvANyn/9+0Zf+/qZuk7f9v 9u//s16EVed/lqrP8j/TUHWZ/9l62//zOP0/yjoaco6+iHvD3ERBmiPGCxpGAqXJpMEGKjMZ GFCayYvowcqzcShQEEawfpyWEUNHx2fI4wgcPXyACopRL+Lwpuz+GfpjHkNVgWgpAHqOjkH3 ZHcP3gvBB4ZeKeEqYeJHJeOdzvX2oz4v/NmM7FABeH0/zXmvvl9grQiThVfL7zhAyMyq7zhM gQChezyAR2gUpR6N0M7uoUBFilgoJDOA8oCWUVFxR6ZpEO97ipKFTPIRcN+9p6qfl8nETmG5 IlueKhiLgZDLFVlnlhHPaDH+Iy5M26+ms0Dtgwcw7DAFVrDLhMKekSfbtRKG6p2I7WWgqGFF gKYjwb+LmdeL6JJ2X/eiTaSd0RxicyHz+iUAV9ajdBTx33kkbTCpbA1go6rJTSnGUocEshRB RYQhbc/yNBNI5lciGKjKejUPL0UxGp6dHu/v7Z/2do9fLonwU34OGSlHw53hIQoZTwrIT6Wq 7x2czT4vhw1o//XZ/unRziFKfwf6ITW9QHtpTMME1W13Ci2L8QegdcQvMgWh7ihkSSlTscHG byp2//XD5tu3P5TXJrcgT8s4z6HiYfKeXwB/IfmV9xJkV8KadAz2b0vcfvxRlN6PG3/bmMvZ Bhn4mIuduhzb3IAdHNU7eEI2N0ZfPmmbm1WP5E4UoZj7YwGGIDiT7leGnoM9MAhRoEKeAKHz sBiDqtUZ9TXSZeK88RvFH3bwmy9UbrBwBMaPY2Z+8kFJq5ukiOJPWQR8/ASaBr9HQtAs3HwI +RI9kNNdkpY9rw2r9pTSDABttCStOk3TAu0N96EIi6L0HNHkMgXPDSpceWeofyZopf9OelIi g24XeZfoafWGjGqlV3t+tAHUb1angvcGCdyewZkHvwQyp2zco1B6eDR5j4ISLEhWEInIaRnf fvyzrE0o8kxREtwB/6soogyC8KLT6d62ga7CwhzsKc0v7xXbAEkOAmYJ4LjHWWu3WpWddzof h8MXO58LUsZj8tIL7KNfDn/65/hnd4+/eJ2fx7+eFHo+FAqYeQERptOB7AU4fZAwfoH/Pp8z QWoBc2jOLXQ6/D/AgvADj8I4LDpYW5qwr8r9Jw6sGxewlWTEExTGTYj+ihZ80X9aFLkYzB9l gLtBUv+rOreyi3ufNnTR4PziOpwFzgO6tRFOQAkeBfOgn6LBhXLVmMEBFDkHe75dxZZBZxV9 V0DpU3QELktpv3r7Z/7+rywMGjj/qf//B9O07Pb8px3taEc72tGOdrSjHe1oRzuWOf4LOFpf UgBQAAA= --------------000109050706000504040005--

1 0

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

23 Nov '11

Howard Chu wrote: > This would imply that the error is isolated to slapcat. Since you claim the > problem did not occur in an earlier revision, Well, that's not sure anymore since I could simply not have observed it before because the slapcat'ed LDIF was always in tree order. Not sure. As said. The difference in data1 (messes up) and data2 (works) is that data2 is in tree-order. Ciao, Michael.

1 0

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

23 Nov '11

michael(a)stroeder.com wrote: > I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with > *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... You still haven't answered this first question: > If you revert the code to an older commit, does it produce the same result? Since you haven't provided steps to reproduce the error, all we can do is rely on you to triage the problem. One crucial step in isolating the problem would be to determine if the error actually occurs during slapadd or slapcat. If you knew that the problem did not occur in a previous revision, then by slapadd'ing the LDIF with that known good revision, and then slapcat'ing with both the known revision and the later revision, would reveal whether the error is actually stored in the database, or whether it's a bug in how slapcat reads out the database. > Also LDAP access to the entries mixed in slapcat output is completely ok. This would imply that the error is isolated to slapcat. Since you claim the problem did not occur in an earlier revision, it might be easy to run thru the commit logs and find the cause of the problem. But without your confirmation of these guesses, we still have nothing to go on. Since we have nothing to go on, and therefore could take no steps to address this issue, it should come as no surprise to you that testing an even later revision than the one you originally reported against still shows the bug occurring. Bug-hunting takes systematic, methodical testing. You can't just go changing revisions willy-nilly. -- -- 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 quanah＠zimbra.com 23 Nov '11

23 Nov '11

--On Wednesday, November 23, 2011 11:16 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> --On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder >> <michael(a)stroeder.com> wrote: >> >>> No way. >> >> Then it is unlikely this will get fixed until you can provide a dummy >> data set that triggers the issue. > > As said I'll try to provide test data. But what strikes me is that your > statement sounds like I'm the only one who's interested in getting this > fixed. I never said nor implied any such thing. I simply pointed out that until you can provide test data that reproduces the problem, it is unlikely this bug will be fixed. Not for lack of willingness for it to be fixed, but because *you* are the only person seeing it, and *you* are the only person with a data set that causes the issue. Thus it is up to *you* to provide such data to the project, or describe it in such a way that someone in the project can reproduce it. Again, this is why I keep an NDA with Symas. It allows me to provide them data necessary for such reproductions. I've managed to hit all sorts of odd ball edge cases over the years that no one else could produce. What I didn't do is expect the project to be able to figure out with a bare minimum of detail what was going wrong. --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 23 Nov '11

23 Nov '11

Quanah Gibson-Mount wrote: > --On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >> No way. > > Then it is unlikely this will get fixed until you can provide a dummy data set > that triggers the issue. As said I'll try to provide test data. But what strikes me is that your statement sounds like I'm the only one who's interested in getting this fixed. Ciao, Michael.

1 0

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

23 Nov '11

--On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > No way. Then it is unlikely this will get fixed until you can provide a dummy data set that triggers the issue. Personally this is why I keep an NDA with Symas. --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 23 Nov '11

23 Nov '11

Quanah Gibson-Mount wrote: > --On Wednesday, November 23, 2011 9:48 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >>> Can you provide these two data sets? >> >> As said in my first posting: This is private address book data. So nope. > > Can you provide it outside of the ITS system in a private manner to Howard? No way. Ciao, Michael.

1 0

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

23 Nov '11

--On Wednesday, November 23, 2011 9:48 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: >> Can you provide these two data sets? > > As said in my first posting: This is private address book data. So nope. Can you provide it outside of the ITS system in a private manner to Howard? That is going to be the easiest way to get this resolved. --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 23 Nov '11

23 Nov '11

Quanah Gibson-Mount wrote: > --On Wednesday, November 23, 2011 8:18 PM +0000 michael(a)stroeder.com wrote: > >> I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with >> *nearly* the same data (data2) and the bug does not seem to happen again. >> Hmm... >> >> But with the old last good backup LDIF (data1) the bug happens again. > > I'm trying to comprehend what you're saying here... So is this correct? > > You have two data sets, data1 and data2. You get can reproduce the issue > using dataset data1, and you have no issues using dataset data2. Yes. And the obvious difference is the order of superior and subordinate entries which get mixed with other superior entries as described in my last posting. > Can you provide these two data sets? As said in my first posting: This is private address book data. So nope. Ciao, Michael.

1 0

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

23 Nov '11

--On Wednesday, November 23, 2011 8:18 PM +0000 michael(a)stroeder.com wrote: > I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with > *nearly* the same data (data2) and the bug does not seem to happen again. > Hmm... > > But with the old last good backup LDIF (data1) the bug happens again. I'm trying to comprehend what you're saying here... So is this correct? You have two data sets, data1 and data2. You get can reproduce the issue using dataset data1, and you have no issues using dataset data2. Can you provide these two data sets? --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 23 Nov '11

23 Nov '11

I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... But with the old last good backup LDIF (data1) the bug happens again. I noticed that in data1 the entries which were mixed up later in slapcat output were in the order (example data) dn: cn=John Doe,o=Company dn: o=Company whereas later in data2 there was exported: dn: o=Company dn: cn=John Doe,o=Company I will try to provide a test LDIF if necessary but I'm in a hurry now. Please note that I'm talking about LDIF files which were all generated by slapcat and therefore are assumed to be valid input for restoring with slapadd. Also LDAP access to the entries mixed in slapcat output is completely ok. Ciao, Michael.

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by h.b.furuseth＠usit.uio.no 23 Nov '11

23 Nov '11

draft-behera-ldap-password-policy: - Says this should be supported via attribute SubtreeSpecification in the pwdPolicy subentry. I think OpenLDAP does not support this attribute, it accepts it but does not do anything. - Leaves room to make the requested behavior configurable in cn=config, or for that matter make it the default: The draft mostly says ppolicy applies to "user entries". Browsing it quicly, I don't see it define what that means, nor consider the existence of non-user entries. A config attribute could define that. I don't know if anyone will bother to implement this (patches welcome) but I don't see a formal problem with whether it could/should be done. -- Hallvard

1 0

Re: (ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by michael＠stroeder.com 23 Nov '11

23 Nov '11

It seems to work with git master fadb48a723756ac0111731f7650f7da1a23c12a3 So you can close this ITS. If any issue is in the RE24 I will file new ITS. Ciao, Michael.

1 0

Re: (ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by quanah＠zimbra.com 22 Nov '11

22 Nov '11

--On Monday, November 21, 2011 10:35 AM +0000 michael(a)stroeder.com wrote: > Full_Name: > Version: git master 9845c030ab1b569d9943c885cd6db876c535758d > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.128.253.198) > > > test000 works with bdb and mdb but not hdb > > $ ./run -b hdb test000 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test000-rootdse for hdb... > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 66: kill: (5333) - No such process > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>>> Test failed > So what do you see in the generated log 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#7094) slapd ciphersuite TLS_RSA_3DES_EDE_CBC_SHA1 not usable with GnuTLS
by quanah＠OpenLDAP.org 22 Nov '11

22 Nov '11

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As reported in the debian bug tracker at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648056 If slapd is set to use the TLS_RSA_3DES_EDE_CBC_SHA1 cipher suite, it fails to start up, even though gnuTLS reports it as supported.

1 0

ITS#7059 UTF8StringNormalize issue
by hyc＠symas.com 22 Nov '11

22 Nov '11

As Ralf Haferkamp noted, the real bug was introduced with postalAddressNormalize which was released in 2.4.10, so nothing earlier than that is affected. Also, this bug had no effect on most Linux installs because glibc malloc always allocates at least 16 bytes. The bug was only detected because I was running valgrind to check for leaks; there was no known crash related to this bug. -- -- 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#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by michael＠stroeder.com 21 Nov '11

21 Nov '11

Noël Köthe wrote: >> noel debian.org wrote: >>> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute >>> to DN's which don't have a userPassword attribute and cannot get >>> one. > >> Hmm, this is somewhat debatable. I'm not sure. But I also don't see any >> harm in the current behaviour. It's surely the client configuration >> which needs to > > :( > >> be fixed. > > In my case the behaviour is pollution my data with unneeded and unwanted > data in ous which I want to prevent. I don't have control over the > clients so sadly I cannot fix the source of the problem (the requests). > The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there > is a userPassword: attribute ( when using pwdAttribute: userPassword). Is > there any chance that the behaviour is accepted as a problem? Maybe you got me wrong: I don't have a really strong opinion on that (nor am I the one who decides on this). The question is: What should the pwdFailureTime exactly mean? I understand what's your personal opinion on that and I somewhat support it. But there might be corner-cases where the current behaviour makes sense. Ciao, Michael.

1 0

(ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by michael＠stroeder.com 21 Nov '11

21 Nov '11

Full_Name: Version: git master 9845c030ab1b569d9943c885cd6db876c535758d OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.253.198) test000 works with bdb and mdb but not hdb $ ./run -b hdb test000 Cleaning up test run directory leftover from previous run. Running ./scripts/test000-rootdse for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: line 66: kill: (5333) - No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by noel＠debian.org 21 Nov '11

21 Nov '11

--=-OBICNroNT6O1Nc+JWJc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Michael, >noel debian.org wrote: >> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to D= N's >> which don't have a userPassword attribute and cannot get one. > Hmm, this is somewhat debatable. I'm not sure. But I also don't see any h= arm > in the current behaviour. It's surely the client configuration which need= s to :( > be fixed. In my case the behaviour is pollution my data with unneeded and unwanted data in ous which I want to prevent. I don't have control over the clients so sadly I cannot fix the source of the problem (the requests). The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there is a userPassword: attribute ( when using pwdAttribute: userPassword). Is there any chance that the behaviour is accepted as a problem? --=20 No=C3=ABl K=C3=B6the <noel debian.org> Debian GNU/Linux, www.debian.org --=-OBICNroNT6O1Nc+JWJc8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk7KFRUACgkQ9/DnDzB9Vu2a8QCfdLgeqXZE6hgK5wy2Tk+bZCAZ vMYAnA9UHtRGoukZcJ/KtvxHDZECFP6d =91QP -----END PGP SIGNATURE----- --=-OBICNroNT6O1Nc+JWJc8--

1 0

Re: (ITS#7092) Please re-open #6548 - Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 19 Nov '11

19 Nov '11

online(a)mark.ziesemer.com wrote: > Full_Name: Mark A. Ziesemer > Version: 2.4.2 2.4.2 would have been an early alpha or beta release. Bug reports filed against such a release at this point are worthless. > OS: Ubuntu Linux 11.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.156.254.191) > Please re-open http://www.openldap.org/its/index.cgi/Incoming?id=6548 . This is > listed as a confirmed issue for Ubuntu at > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/594840 , affecting at > least 12 users - and there is no evidence to show that this is an issue specific > to Ubuntu. > > Please also refer to and at least acknowledge the unaddressed comments left in > response to #6548, which includes a report from a Debian user as well. > To clarify, this appears to be an issue with the libldap client library provided > by OpenLDAP itself (2.4.25), and not the slapd daemon. Some comments simply aren't worth addressing. Inserting sleeps is never the correct solution. A new patch for slapd is in git master, please test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7092) Please re-open #6548 - Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 19 Nov '11

19 Nov '11

Full_Name: Mark A. Ziesemer Version: 2.4.2 OS: Ubuntu Linux 11.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.156.254.191) Please re-open http://www.openldap.org/its/index.cgi/Incoming?id=6548 . This is listed as a confirmed issue for Ubuntu at https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/594840 , affecting at least 12 users - and there is no evidence to show that this is an issue specific to Ubuntu. Please also refer to and at least acknowledge the unaddressed comments left in response to #6548, which includes a report from a Debian user as well. To clarify, this appears to be an issue with the libldap client library provided by OpenLDAP itself (2.4.25), and not the slapd daemon.

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 18 Nov '11

18 Nov '11

hans.moser(a)ofd-z.niedersachsen.de wrote: > Howard, > > Howard Chu schrieb (17.11.2011 23:54 Uhr): >> Marc Patermann wrote: > >>> Howard Chu schrieb (01.11.2011 18:39 Uhr): >>> >>>> Also, this script just performs sync searches, what do you use to >>>> generate the writes? >>> you mean the write which kills the server? >>> It just one simple mod of an object which I made in Apache Directory >>> Studio. >> >> I'm unable to reproduce this crash. I have your slapd.conf and test >> data, I have run 80-some instances of your script as you've described. > I ran 80 instances of each of the three script, where each script > replicates one database, so 240 instances of the script in total. OK. After starting 240 instances and performing the modify, I saw a SEGV due to syncprov. I've patched this in git master, please test. It runs OK for me now. > >> While the initial sync search is running I perform a modify of the base >> entry of the subordinate database. Everything continues to run. I've >> also waited for all of the initial refresh traffic to finish first, and >> then perform the modify, and still no crash. >> >> To be more clear - do you perform your modify while the sync searches >> are still refreshing, or after all of the refreshes have completed? > IIRC it does not make any difference, but I definitly crashed the server > while at least one database still replicated. > >> Do you run the clients on the same host as slapd, or on a remote machine? > I had slapd one one machine and the script on another one. > > > Marc > > > -- -- 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#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 17 Nov '11

17 Nov '11

Howard, Howard Chu schrieb (17.11.2011 23:54 Uhr): > Marc Patermann wrote: >> Howard Chu schrieb (01.11.2011 18:39 Uhr): >> >>> Also, this script just performs sync searches, what do you use to >>> generate the writes? >> you mean the write which kills the server? >> It just one simple mod of an object which I made in Apache Directory >> Studio. > > I'm unable to reproduce this crash. I have your slapd.conf and test > data, I have run 80-some instances of your script as you've described. I ran 80 instances of each of the three script, where each script replicates one database, so 240 instances of the script in total. > While the initial sync search is running I perform a modify of the base > entry of the subordinate database. Everything continues to run. I've > also waited for all of the initial refresh traffic to finish first, and > then perform the modify, and still no crash. > > To be more clear - do you perform your modify while the sync searches > are still refreshing, or after all of the refreshes have completed? IIRC it does not make any difference, but I definitly crashed the server while at least one database still replicated. > Do you run the clients on the same host as slapd, or on a remote machine? I had slapd one one machine and the script on another one. Marc

1 0

Re: (ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by hyc＠symas.com 17 Nov '11

17 Nov '11

hyc(a)symas.com wrote: > >>> > The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, > back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for > assertion failure, if op->o_do_not_cache flag is set and there is no valid > binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI > for the remote AD Windows box is such a case. > <<< > > So it sounds like this assert only triggers because you have an invalid > configuration. I don't believe your patch is the correct solution if that's > the only error case. I've committed an alternate fix, turning the assert into an error return. Please test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by hyc＠symas.com 17 Nov '11

17 Nov '11

tedcheng(a)symas.com wrote: > The following patch fixed the issue: > > Index: servers/slapd/back-ldap/bind.c > =================================================================== > RCS file: /var/CVSROOT/ldap24/servers/slapd/back-ldap/bind.c,v > retrieving revision 1.12 > retrieving revision 1.13 > diff -u -u -r1.12 -r1.13 > --- servers/slapd/back-ldap/bind.c 28 Jul 2011 09:31:34 -0000 1.12 > +++ servers/slapd/back-ldap/bind.c 17 Nov 2011 21:35:46 -0000 1.13 > @@ -2056,7 +2056,7 @@ > struct berval ndn; > int dobind = 0; > > - if ( op->o_conn == NULL || op->o_do_not_cache ) { > + if ( op->o_conn == NULL ) { > goto done; > } > In your original post you state: >>> The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for assertion failure, if op->o_do_not_cache flag is set and there is no valid binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI for the remote AD Windows box is such a case. <<< So it sounds like this assert only triggers because you have an invalid configuration. I don't believe your patch is the correct solution if that's the only error case. -- -- 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#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by tedcheng＠symas.com 17 Nov '11

17 Nov '11

The following patch fixed the issue: Index: servers/slapd/back-ldap/bind.c =================================================================== RCS file: /var/CVSROOT/ldap24/servers/slapd/back-ldap/bind.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -u -r1.12 -r1.13 --- servers/slapd/back-ldap/bind.c 28 Jul 2011 09:31:34 -0000 1.12 +++ servers/slapd/back-ldap/bind.c 17 Nov 2011 21:35:46 -0000 1.13 @@ -2056,7 +2056,7 @@ struct berval ndn; int dobind = 0; - if ( op->o_conn == NULL || op->o_do_not_cache ) { + if ( op->o_conn == NULL ) { goto done; } Ted C. Cheng Symas Corporation

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 17 Nov '11

17 Nov '11

hyc(a)symas.com wrote: > Marc Patermann wrote: >> Howard, >> >> Howard Chu schrieb (01.11.2011 18:39 Uhr): >> >>> Also, this script just performs sync searches, what do you use to >>> generate the writes? >> you mean the write which kills the server? >> It just one simple mod of an object which I made in Apache Directory Studio. > > I'm unable to reproduce this crash. I have your slapd.conf and test data, I > have run 80-some instances of your script as you've described. While the > initial sync search is running I perform a modify of the base entry of the > subordinate database. Everything continues to run. I've also waited for all of > the initial refresh traffic to finish first, and then perform the modify, and > still no crash. > > To be more clear - do you perform your modify while the sync searches are > still refreshing, or after all of the refreshes have completed? > > Do you run the clients on the same host as slapd, or on a remote machine? By the way... Your backtrace shows a crash down a code path that only gets executed when an operation is abandoned. None of the steps you've outlined ever cause an abandon or connection close to occur, so again, we can't duplicate the problem. -- -- 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#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 17 Nov '11

17 Nov '11

Marc Patermann wrote: > Howard, > > Howard Chu schrieb (01.11.2011 18:39 Uhr): > >> Also, this script just performs sync searches, what do you use to >> generate the writes? > you mean the write which kills the server? > It just one simple mod of an object which I made in Apache Directory Studio. I'm unable to reproduce this crash. I have your slapd.conf and test data, I have run 80-some instances of your script as you've described. While the initial sync search is running I perform a modify of the base entry of the subordinate database. Everything continues to run. I've also waited for all of the initial refresh traffic to finish first, and then perform the modify, and still no crash. To be more clear - do you perform your modify while the sync searches are still refreshing, or after all of the refreshes have completed? Do you run the clients on the same host as slapd, or on a remote machine? -- -- 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 16 Nov '11

16 Nov '11

hyc(a)symas.com wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> What git commit ID? >> >> As said in former times: Before reporting an ITS I *always* do git pull >> checking whether there was something committed after the tested build. If >> there was a new commit I always retest. > > Please just answer the questions. Bear in mind that there is a propagation > delay between the writable git-master and the public mirror. fe1659fc5b01530401174cef3f381ce56918476f Ciao, Michael.

1 0

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

16 Nov '11

Michael Ströder wrote: > Howard Chu wrote: >> What git commit ID? > > As said in former times: Before reporting an ITS I *always* do git pull > checking whether there was something committed after the tested build. If > there was a new commit I always retest. Please just answer the questions. Bear in mind that there is a propagation delay between the writable git-master and the public mirror. I always have good reasons for asking for the information that I ask for. Second-guessing me is not going to get problems solved faster. -- -- 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#7085) mutex lockup issue
by hayashis＠indiana.edu 16 Nov '11

16 Nov '11

--0015174c117a5169be04b1e058e5 Content-Type: text/plain; charset=ISO-8859-1 Quanah, We have compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 hours into our testing in similar manner to what I have reported earlier. I believe this issue still occurs on the latest version. However, when I used gdb, I didn't notice the mutex locked threads like I did with OpenLDAP 2.4.22. Following is from locked 2.4.26 slapd server. (gdb) info thread 14 Thread 0x418dd940 (LWP 13814) 0x00000037aa4d48a8 in epoll_wait () from /lib64/libc.so.6 13 Thread 0x420de940 (LWP 13815) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 12 Thread 0x428df940 (LWP 13816) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 11 Thread 0x430e0940 (LWP 13843) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x438e1940 (LWP 13855) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9 Thread 0x440e2940 (LWP 13856) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x448e3940 (LWP 13857) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x450e4940 (LWP 13858) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x458e5940 (LWP 13859) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x460e6940 (LWP 13860) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x468e7940 (LWP 2007) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x470e8940 (LWP 2008) 0x00000037aa4cd722 in select () from /lib64/libc.so.6 2 Thread 0x478e9940 (LWP 2009) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x2ac6ccfdc930 (LWP 13805) 0x00000037aac07b35 in pthread_join () from /lib64/libpthread.so.0 (gdb) thread 3 [Switching to thread 3 (Thread 0x470e8940 (LWP 2008))]#0 0x00000037aa4cd722 in select () from /lib64/libc.so.6 (gdb) bt #0 0x00000037aa4cd722 in select () from /lib64/libc.so.6 #1 0x000000000054ece5 in ?? () #2 0x000000000054aa15 in ?? () #3 0x0000000000557637 in ?? () #4 0x0000000000557c11 in ?? () #5 0x00000000004b2d93 in ?? () #6 0x00000000004e9d7c in ?? () #7 0x00000037aac0673d in start_thread () from /lib64/libpthread.so.0 #8 0x00000037aa4d44bd in clone () from /lib64/libc.so.6 It looks like it's waiting on select() on thread 3 which never get fired when I access it using ldapsearch command. I ran strace on ldapsearch (on a client machine) and following is what I see at the end of the log.. $ strace ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=WT2,o=grid "(&(objectClass=GlueLocation)(GlueLocationName=TIMESTAMP))" .... write(1, "\n", 1 ) = 1 write(3, "0l\2\1\2cg\4\26mds-vo-name=WT2,o=grid\n"..., 110) = 110 poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1 Not sure if this strace is useful or not.. but after this, ldapsearch never returned. Thanks, Soichi On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.eduwrote: > > Full_Name: Soichi Hayashi >> Version: 2.4.22 >> > > OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a > current release (2.4.26). This report will not be investigated unless you > can reproduce it with a current release of OpenLDAP. You also fail to note > what BDB release you are using, and whether or not it has all the relevant > patches applied to it. If you have a broken policy of only using vendor > provided packages, then you will need to send a bug report to RedHat, as it > is their job to maintain their vendor packages. > > > Thanks! > > --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 > --0015174c117a5169be04b1e058e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Quanah,</div><div><br></div><div>We have compiled OpenLDAP 2.4.26 with= BDB 5.2.36. The OpenLDAP locked up 4 hours into our testing in similar man= ner to what I have reported earlier. I believe this issue still occurs on t= he latest version.</div> <div><br></div><div>However, when I used gdb, I didn't notice the mutex= locked threads like I did with OpenLDAP 2.4.22.</div><div><br></div><div>F= ollowing is from locked 2.4.26 slapd server.</div><div><br></div><div>(gdb)= info thread</div> <div>=A0 14 Thread 0x418dd940 (LWP 13814) =A00x00000037aa4d48a8 in epoll_wa= it () from /lib64/libc.so.6</div><div>=A0 13 Thread 0x420de940 (LWP 13815) = =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libp= thread.so.0</div> <div>=A0 12 Thread 0x428df940 (LWP 13816) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 11 Thre= ad 0x430e0940 (LWP 13843) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC= _2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 10 Thread 0x438e1940 (LWP 13855) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 9 Threa= d 0x440e2940 (LWP 13856) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_= 2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 8 Thread 0x448e3940 (LWP 13857) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 7 Thread= 0x450e4940 (LWP 13858) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 6 Thread 0x458e5940 (LWP 13859) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 5 Thread= 0x460e6940 (LWP 13860) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 4 Thread 0x468e7940 (LWP 2007) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 3 Thread = 0x470e8940 (LWP 2008) =A00x00000037aa4cd722 in select () from /lib64/libc.s= o.6</div> <div>=A0 2 Thread 0x478e9940 (LWP 2009) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>* 1 Thread 0x= 2ac6ccfdc930 (LWP 13805) =A00x00000037aac07b35 in pthread_join () from /lib= 64/libpthread.so.0</div> <div>(gdb) thread 3</div><div>[Switching to thread 3 (Thread 0x470e8940 (LW= P 2008))]#0 =A00x00000037aa4cd722 in select () from /lib64/libc.so.6</div><= div>(gdb) bt</div><div>#0 =A00x00000037aa4cd722 in select () from /lib64/li= bc.so.6</div> <div>#1 =A00x000000000054ece5 in ?? ()</div><div>#2 =A00x000000000054aa15 i= n ?? ()</div><div>#3 =A00x0000000000557637 in ?? ()</div><div>#4 =A00x00000= 00000557c11 in ?? ()</div><div>#5 =A00x00000000004b2d93 in ?? ()</div><div>= #6 =A00x00000000004e9d7c in ?? ()</div> <div>#7 =A00x00000037aac0673d in start_thread () from /lib64/libpthread.so.= 0</div><div>#8 =A00x00000037aa4d44bd in clone () from /lib64/libc.so.6</div= ><div><br></div><div>It looks like it's waiting on select() on thread 3= which never get fired when I access it using ldapsearch command.=A0</div> <div><br></div><div>I ran strace on ldapsearch (on a client machine) and fo= llowing is what I see at the end of the log..</div><div><br></div><div>$ st= race ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=3DWT2,o=3Dg= rid "(&(objectClass=3DGlueLocation)(GlueLocationName=3DTIMESTAMP))= "</div> <div><br></div><div>....</div><div>write(1, "\n", 1</div><div>) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 1</div><div>write(3, "= 0l\2\1\2cg\4\26mds-vo-name=3DWT2,o=3Dgrid\n"..., 110) =3D 110</div><di= v>poll([{fd=3D3, events=3DPOLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1</div> <div><br></div><div>Not sure if this strace is useful or not.. but after th= is, ldapsearch never returned.</div><div><br></div><div>Thanks,</div><div>S= oichi</div><div><br></div><br><div class=3D"gmail_quote">On Wed, Nov 9, 201= 1 at 1:13 PM, Quanah Gibson-Mount <span dir=3D"ltr"><<a href=3D"mailto:q= uanah(a)zimbra.com">quanah(a)zimbra.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">--On Wednesday, November 09, 2011 2:01 PM += 0000 <a href=3D"mailto:hayashis@indiana.edu" target=3D"_blank">hayashis@ind= iana.edu</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Soichi Hayashi<br> Version: 2.4.22<br> </blockquote> <br> OpenLDAP 2.4.22 is quite old, and had various known issues. =A0Please use a= current release (2.4.26). =A0This report will not be investigated unless y= ou can reproduce it with a current release of OpenLDAP. =A0You also fail to= note what BDB release you are using, and whether or not it has all the rel= evant patches applied to it. =A0If you have a broken policy of only using v= endor provided packages, then you will need to send a bug report to RedHat,= as it is their job to maintain their vendor packages.<br> <br> <br> Thanks!<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> --Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Sr. Member of Technical Staff<br> Zimbra, Inc<br> A Division of VMware, Inc.<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </font></span></blockquote></div><br> --0015174c117a5169be04b1e058e5--

1 0

(ITS#7091) Limit ppolicy_forward_updates
by michael＠stroeder.com 16 Nov '11

16 Nov '11

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.25.215) This is a feature request: It should be possible to limit effect of ppolicy_forward_updates to certain events like. Maybe just a list of attributes which should be forwarded to a provider. Rationale: To reduce the load on the provide one might want to only forward lockouts to the provider and not each login failure.

1 0

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

16 Nov '11

Howard Chu wrote: > What git commit ID? As said in former times: Before reporting an ITS I *always* do git pull checking whether there was something committed after the tested build. If there was a new commit I always retest. Ciao, Michael.

1 0

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

16 Nov '11

hyc(a)symas.com wrote: >> slapcat with back-mdb mixes entry data in the LDIF output. The entry affected >> had a DN of another entry while retrieving the same entry via LDAP worked >> correctly. I observed this for one entry of several hundred entries. >> >> I currently can't provide test data because this was my private address book >> data. But it was reproducable with slapadd-ed data from an older clean backup >> LDIF file. The last correct backup file I have slapcating with back-mdb is of >> 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad >> happened at that time. >> >> Will try to reproduce with other data but be warned to keep an eye on that. > > What platform, what version, 32 or 64 bit? What git commit ID? openSUSE Linux 11.4 x86_64 > If you revert > the code to an older commit, does it produce the same result? I know that such a report is not sufficient for you to start fixing it. But sometimes it's not possible to report it more precisely. As said I will try to reproduce with non-private data. It was too late to do more testing yesterday. > I've slapcat'd a 5 million entry back-hdb database and loaded it into > back-mdb. Then slapcat'd that result; it is exactly identical to the original. > Using both RE24 pulled a couple minutes ago, and git master built November > 1st. There have been no functional changes to the code in a while, purely > cosmetic changes. Maybe it's dependent on the sort of data? The errornous entry contains attribute jpegPhoto of size 7317 bytes. Ciao, Michael.

1 0

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

15 Nov '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 pulled from git > OS: > URL: > Submission from: (NULL) (84.163.26.40) > > > slapcat with back-mdb mixes entry data in the LDIF output. The entry affected > had a DN of another entry while retrieving the same entry via LDAP worked > correctly. I observed this for one entry of several hundred entries. > > I currently can't provide test data because this was my private address book > data. But it was reproducable with slapadd-ed data from an older clean backup > LDIF file. The last correct backup file I have slapcating with back-mdb is of > 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad > happened at that time. > > Will try to reproduce with other data but be warned to keep an eye on that. What platform, what version, 32 or 64 bit? What git commit ID? If you revert the code to an older commit, does it produce the same result? I've slapcat'd a 5 million entry back-hdb database and loaded it into back-mdb. Then slapcat'd that result; it is exactly identical to the original. Using both RE24 pulled a couple minutes ago, and git master built November 1st. There have been no functional changes to the code in a while, purely cosmetic changes. -- -- 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#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 15 Nov '11

15 Nov '11

Full_Name: Michael Ströder Version: RE24 pulled from git OS: URL: Submission from: (NULL) (84.163.26.40) slapcat with back-mdb mixes entry data in the LDIF output. The entry affected had a DN of another entry while retrieving the same entry via LDAP worked correctly. I observed this for one entry of several hundred entries. I currently can't provide test data because this was my private address book data. But it was reproducable with slapadd-ed data from an older clean backup LDIF file. The last correct backup file I have slapcating with back-mdb is of 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad happened at that time. Will try to reproduce with other data but be warned to keep an eye on that.

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by michael＠stroeder.com 15 Nov '11

15 Nov '11

noel(a)debian.org wrote: > IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's > which don't have a userPassword attribute and cannot get one. Hmm, this is somewhat debatable. I'm not sure. But I also don't see any harm in the current behaviour. It's surely the client configuration which needs to be fixed. Ciao, Michael.

1 0

(ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by noel＠debian.org 15 Nov '11

15 Nov '11

Full_Name: Noel Köthe Version: 2.4.25 OS: Debian GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.187.103.39) Hello, using the ppolicy overlay with no special options: slapd.conf ... overlay ppolicy ppolicy_default "cn=ppolicy,dc=domain,dc=lan" ppolicy_use_lockout ... cn=ppolicy,dc=domain,dc=lan objectClass: top objectClass: device objectClass: pwdPolicy objectClass: pwdPolicyChecker cn: ppolicy pwdMaxAge: 2592000 pwdExpireWarning: 3600 pwdMaxFailure: 5 pwdLockout: TRUE pwdMustChange: TRUE pwdMinLength: 6 pwdSafeModify: FALSE pwdAttribute: userPassword I'm scanning the LDAP data for PWDFAILURETIME attributes from time to time and found the following ou with this attribute (slapcat output): dn: ou=test,dc=domain,dc=lan objectClass: organizationalUnit ou: test structuralObjectClass: organizationalUnit entryUUID: ad5a6bc6-8a9c-1030-810d-db1b7d10e7b5 creatorsName: cn=admin,dc=domain,dc=lan createTimestamp: 20111014104028Z PWDFAILURETIME: 20111115101034Z PWDFAILURETIME: 20111115101036Z PWDFAILURETIME: 20111115101039Z PWDFAILURETIME: 20111115111624Z PWDFAILURETIME: 20111115111629Z PWDACCOUNTLOCKEDTIME: 20111115111629Z entryCSN: 20111115111629.327963Z#000000#000#000000 modifiersName: cn=admin,dc=domain,dc=lan modifyTimestamp: 20111115111629Z The PWDFAILURETIME on an organizationalUnit were created by: $ ldapsearch -x -W -D ou=test,dc=domain,dc=lan Enter LDAP Password: ldap_bind: Invalid credentials (49) IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's which don't have a userPassword attribute and cannot get one. Do you aggree? Thanks for your answer. Regards Noel Köthe

1 0

Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by michael＠stroeder.com 11 Nov '11

11 Nov '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Hmm, after 12 iterations slapd instances are blocked: > > I believe I've reproduced this once. It looks like the background indexing > task was running and preventing a replicated cn=config change from completing. > Possibly a call to pausecheck() should be added in the indexer task, but the > more serious issue is that the indexer was re-indexing the same entry (entry > #1) over and over again, instead of progressing thru the DB. Still trying to > reproduce this to see what happened. It never seems to happen with > optimization disabled. Hmm, my build script has CFLAGS="-g -O0" Ciao, Michael.

1 0

Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by hyc＠symas.com 10 Nov '11

10 Nov '11

michael(a)stroeder.com wrote: > Hmm, after 12 iterations slapd instances are blocked: I believe I've reproduced this once. It looks like the background indexing task was running and preventing a replicated cn=config change from completing. Possibly a call to pausecheck() should be added in the indexer task, but the more serious issue is that the indexer was re-indexing the same entry (entry #1) over and over again, instead of progressing thru the DB. Still trying to reproduce this to see what happened. It never seems to happen with optimization disabled. > > Cleaning up test run directory from this run. > Running 12 of 100 iterations > running defines.sh > Initializing server configurations... > Starting server 1 on TCP/IP port 9011... > Using ldapsearch to check that server 1 is running... > Inserting syncprov overlay on server 1... > Starting server 2 on TCP/IP port 9012... > Using ldapsearch to check that server 2 is running... > Configuring syncrepl on server 2... > Starting server 3 on TCP/IP port 9013... > Using ldapsearch to check that server 3 is running... > Configuring syncrepl on server 3... > Starting server 4 on TCP/IP port 9014... > Using ldapsearch to check that server 4 is running... > Configuring syncrepl on server 4... > Adding schema and databases on server 1... > Using ldapadd to populate server 1... > Waiting 15 seconds for syncrepl to receive changes... > Using ldapsearch to read config from server 1... > Using ldapsearch to read config from server 2... > Using ldapsearch to read config from server 3... > [..hangs..] > > > -- -- 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#7087) test050-syncrepl-multimaster failed for mdb
by hyc＠symas.com 10 Nov '11

10 Nov '11

michael(a)stroeder.com wrote: > Hmm, after 12 iterations slapd instances are blocked: Need a gdb trace from the hung slapd. > > Cleaning up test run directory from this run. > Running 12 of 100 iterations > running defines.sh > Initializing server configurations... > Starting server 1 on TCP/IP port 9011... > Using ldapsearch to check that server 1 is running... > Inserting syncprov overlay on server 1... > Starting server 2 on TCP/IP port 9012... > Using ldapsearch to check that server 2 is running... > Configuring syncrepl on server 2... > Starting server 3 on TCP/IP port 9013... > Using ldapsearch to check that server 3 is running... > Configuring syncrepl on server 3... > Starting server 4 on TCP/IP port 9014... > Using ldapsearch to check that server 4 is running... > Configuring syncrepl on server 4... > Adding schema and databases on server 1... > Using ldapadd to populate server 1... > Waiting 15 seconds for syncrepl to receive changes... > Using ldapsearch to read config from server 1... > Using ldapsearch to read config from server 2... > Using ldapsearch to read config from server 3... > [..hangs..] > > > -- -- 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#7088) slapo-accesslog makes OpenLDAP hang
by michael＠stroeder.com 10 Nov '11

10 Nov '11

raphael.ouazana(a)linagora.com wrote: > When using the following overlays: > - refint > - memberof > - ppolicy > - synprov > - accesslog Order of overlays is significant. I have a very similar setup running 2.4.26 but with this order at the end of all overlays: [..] accesslog syncprov Ciao, Michael.

1 0

(ITS#7088) slapo-accesslog makes OpenLDAP hang
by raphael.ouazana＠linagora.com 10 Nov '11

10 Nov '11

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) When using the following overlays: - refint - memberof - ppolicy - synprov - accesslog OpenLDAP hangs. Here is the backtrace: (gdb) thread apply all bt Thread 5 (Thread 0x3355bb70 (LWP 11959)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb7420c16 in epoll_wait () at ../sysdeps/unix/syscall-template.S:82 #2 0x080639fb in slapd_daemon_task (ptr=0x0) at daemon.c:2528 #3 0xb76aed31 in start_thread (arg=0x3355bb70) at pthread_create.c:304 #4 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 4 (Thread 0x3315ab70 (LWP 11960)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76b2a5c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x081b3fae in ldap_int_thread_pool_wrapper (xpool=0x98a1b60) at tpool.c:672 #3 0xb76aed31 in start_thread (arg=0x3315ab70) at pthread_create.c:304 #4 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 3 (Thread 0x32d59b70 (LWP 11961)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76b2a5c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x081b2a1c in ldap_pvt_thread_rmutex_lock (rmutex=0x992c0e0, owner=852859760) at rmutex.c:129 #3 0x081629c6 in accesslog_op_mod (op=0x9997840, rs=0x32d590fc) at accesslog.c:1889 #4 0x080d50e9 in overlay_op_walk (op=0x9997840, rs=0x32d590fc, which=op_add, oi=0x992bdd0, on=0x992bfa8) at backover.c:661 #5 0x080d52d2 in over_op_func (op=0x9997840, rs=0x32d590fc, which=op_add) at backover.c:723 #6 0x080702f6 in fe_op_add (op=0x9997840, rs=0x32d590fc) at add.c:334 #7 0x0807125f in do_add (op=0x9997840, rs=0x32d590fc) at add.c:194 #8 0x080692ee in connection_operation (ctx=0x32d591fc, arg_v=0x9997840) at connection.c:1138 #9 0x08069c6a in connection_read_thread (ctx=0x32d591fc, argv=0x10) at connection.c:1274 #10 0x081b3f56 in ldap_int_thread_pool_wrapper (xpool=0x98a1b60) at tpool.c:685 #11 0xb76aed31 in start_thread (arg=0x32d59b70) at pthread_create.c:304 #12 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 2 (Thread 0x31f55b70 (LWP 11996)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76b2a5c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x081b3fae in ldap_int_thread_pool_wrapper (xpool=0x98a1b60) at tpool.c:672 #3 0xb76aed31 in start_thread (arg=0x31f55b70) at pthread_create.c:304 #4 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 1 (Thread 0xb73326c0 (LWP 11954)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76afe2c in pthread_join (threadid=861256560, thread_return=0x0) at pthread_join.c:89 #2 0x080666de in slapd_daemon () at daemon.c:2922 #3 0x0804def9 in main (argc=7, argv=0xbfb125d4) at main.c:983 Regards, Raphaêl Ouazana.

1 0

RE: (ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com 10 Nov '11

10 Nov '11

apologies, I just checked master and can see that a fix was put in on 1st Nov. ---------------------------------------- > Date: Thu, 10 Nov 2011 14:36:11 +0000 > From: ctcard(a)hotmail.com > To: openldap-its(a)openldap.org > Subject: RE: (ITS#7061) Only return requested attrs in sssvlv response > > > Is anyone looking at this? > > ---------------------------------------- > > Date: Tue, 11 Oct 2011 13:58:55 +0000 > > From: ctcard(a)hotmail.com > > To: openldap-its(a)openldap.org > > Subject: (ITS#7061) Only return requested attrs in sssvlv response > > > > Full_Name: Chris Card > > Version: 2.4.26 + patch > > OS: Centos 5.4 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (91.194.158.133) > > > > > > There was a fix put into master on 18 Jul 2011 with subject "Only return > > requested attrs in sssvlv response" SHA: > > 8eecc9a017584ea0b56b25f0e4750e3b16929de6. > > > > I have patched openldap 2.4.26 with all the fixes to sssvlv.c, but there is > > still an issue with the attributes returned in an sssvlv response. > > > > On the first sssvlv request only the requested attributes are returned, but on > > subsequent sssvlv requests using the vlv context returned by the first requests, > > all the attributes are returned. > > > > > > >

1 0

RE: (ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com 10 Nov '11

10 Nov '11

Is anyone looking at this? ---------------------------------------- > Date: Tue, 11 Oct 2011 13:58:55 +0000 > From: ctcard(a)hotmail.com > To: openldap-its(a)openldap.org > Subject: (ITS#7061) Only return requested attrs in sssvlv response > > Full_Name: Chris Card > Version: 2.4.26 + patch > OS: Centos 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.194.158.133) > > > There was a fix put into master on 18 Jul 2011 with subject "Only return > requested attrs in sssvlv response" SHA: > 8eecc9a017584ea0b56b25f0e4750e3b16929de6. > > I have patched openldap 2.4.26 with all the fixes to sssvlv.c, but there is > still an issue with the attributes returned in an sssvlv response. > > On the first sssvlv request only the requested attributes are returned, but on > subsequent sssvlv requests using the vlv context returned by the first requests, > all the attributes are returned. > >

1 0

Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by michael＠stroeder.com 10 Nov '11

10 Nov '11

Hmm, after 12 iterations slapd instances are blocked: Cleaning up test run directory from this run. Running 12 of 100 iterations running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Inserting syncprov overlay on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Configuring syncrepl on server 2... Starting server 3 on TCP/IP port 9013... Using ldapsearch to check that server 3 is running... Configuring syncrepl on server 3... Starting server 4 on TCP/IP port 9014... Using ldapsearch to check that server 4 is running... Configuring syncrepl on server 4... Adding schema and databases on server 1... Using ldapadd to populate server 1... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read config from server 1... Using ldapsearch to read config from server 2... Using ldapsearch to read config from server 3... [..hangs..]

1 0

Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by michael＠stroeder.com 10 Nov '11

10 Nov '11

Download testrun/ here: http://www.stroeder.com/temp/openldap-its7087-testrun.tar.gz

1 0

(ITS#7087) test050-syncrepl-multimaster failed for mdb
by michael＠stroeder.com 10 Nov '11

10 Nov '11

Full_Name: Version: RE24 from git OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.253.233) This is also a test which only fails occasionally. testrun/ follows... >>>>> Starting test050-syncrepl-multimaster for mdb... running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Inserting syncprov overlay on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Configuring syncrepl on server 2... Starting server 3 on TCP/IP port 9013... Using ldapsearch to check that server 3 is running... Configuring syncrepl on server 3... Starting server 4 on TCP/IP port 9014... Using ldapsearch to check that server 4 is running... Configuring syncrepl on server 4... Adding schema and databases on server 1... Using ldapadd to populate server 1... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read config from server 1... Using ldapsearch to read config from server 2... Using ldapsearch to read config from server 3... Using ldapsearch to read config from server 4... Comparing retrieved configs from server 1 and server 2... Comparing retrieved configs from server 1 and server 3... Comparing retrieved configs from server 1 and server 4... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Using ldapsearch to read all the entries from server 3... Using ldapsearch to read all the entries from server 4... Comparing retrieved entries from server 1 and server 2... Comparing retrieved entries from server 1 and server 3... test failed - server 1 and server 3 databases differ >>>>> test050-syncrepl-multimaster failed for mdb (exit 1) make[2]: *** [mdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#7086) typofix for ldapmodify man page
by quanah＠zimbra.com 09 Nov '11

09 Nov '11

--On Wednesday, November 09, 2011 8:02 PM +0000 schmiddy(a)gmail.com wrote: > Full_Name: Josh Kupershmidt > Version: git head > OS: OS X > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (165.212.186.27) > > > Here is a typofix for the ldapmodify man page, replacing "where" with > "were" in the description of the "-S" option: Thanks, this is fixed. --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#7086) typofix for ldapmodify man page
by schmiddy＠gmail.com 09 Nov '11

09 Nov '11

Full_Name: Josh Kupershmidt Version: git head OS: OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (165.212.186.27) Here is a typofix for the ldapmodify man page, replacing "where" with "were" in the description of the "-S" option: diff --git a/doc/man/man1/ldapmodify.1 b/doc/man/man1/ldapmodify.1 index 0268012..84296e8 100644 --- a/doc/man/man1/ldapmodify.1 +++ b/doc/man/man1/ldapmodify.1 @@ -144,7 +144,7 @@ will continue with modifications. The default is to exit after reporting an error. .TP .BI \-S \ file -Add or change records which where skipped due to an error are written to \fIfile\fP +Add or change records which were skipped due to an error are written to \fIfile\fP and the error message returned by the server is added as a comment. Most useful in conjunction with \fB\-c\fP. .TP

1 0

Re: (ITS#7085) mutex lockup issue
by quanah＠zimbra.com 09 Nov '11

09 Nov '11

--On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.edu wrote: > Full_Name: Soichi Hayashi > Version: 2.4.22 OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a current release (2.4.26). This report will not be investigated unless you can reproduce it with a current release of OpenLDAP. You also fail to note what BDB release you are using, and whether or not it has all the relevant patches applied to it. If you have a broken policy of only using vendor provided packages, then you will need to send a bug report to RedHat, as it is their job to maintain their vendor packages. Thanks! --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#7074) back-ldap module compilation issue with gcc 4.6.1
by stephane.paquot＠gmail.com 09 Nov '11

09 Nov '11

--90e6ba613518beaf2904b14dee12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard, Compilation is fine and module back-ldap is fully operational with the workaround you have suggested. Many thanks to you. 2011/10/29 <openldap-its(a)openldap.org> > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7074. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7074) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#7074) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D7074 > > Please remember to retain your issue tracking number (ITS#7074) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --=20 _________________________________ St=E9phane PAQUOT stephane.paquot(a)gmail.com Site web : http://www.sqlpac.com/ --90e6ba613518beaf2904b14dee12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Howard,</div><div><br></div><div>Compilation is fine and module bac= k-ldap is fully operational with the workaround you have suggested.</div><d= iv><br></div><div>Many thanks to you.</div><div><br></div><br><div class=3D= "gmail_quote"> 2011/10/29 <span dir=3D"ltr"><<a href=3D"mailto:openldap-its@openldap.o= rg">openldap-its(a)openldap.org</a>></span><br><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex;"> <br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your<br> report has been assigned the tracking number ITS#7074.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers. =A0They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message. =A0Note that<br> any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#7074)<br> in the subject will automatically be attached to the issue report.<br> <br> =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a>?subject=3D(ITS#7074)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D7074" tar= get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D7074</a><br> <br> Please remember to retain your issue tracking number (ITS#7074)<br> on any further messages you send to us regarding this report. =A0If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla= nk">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>____________= _____________________<br><br>St=E9phane PAQUOT<br><br><a href=3D"mailto:ste= phane.paquot(a)gmail.com">stephane.paquot(a)gmail.com</a><br>Site web : <a href= =3D"http://www.sqlpac.com/">http://www.sqlpac.com/</a><br> <br> --90e6ba613518beaf2904b14dee12--

1 0

(ITS#7085) mutex lockup issue
by hayashis＠indiana.edu 09 Nov '11

09 Nov '11

Full_Name: Soichi Hayashi Version: 2.4.22 OS: RHEL 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.137.202.79) When a large number of ldap update requests collides with large number of ldap search queries, mutex on BDB linked to OpenLDAP deadlocks. Following is the gdb output when this deadlocks occurs. (gdb) info threads 13 Thread 0x40a73940 (LWP 18767) 0x00000037aa4d48a8 in epoll_wait () from /lib64/libc.so.6 12 Thread 0x41cbe940 (LWP 18768) 0x00000037aa4cd722 in select () from /lib64/libc.so.6 11 Thread 0x424bf940 (LWP 18769) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x42cc0940 (LWP 19203) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9 Thread 0x41274940 (LWP 19212) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x434c1940 (LWP 19213) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x43cc2940 (LWP 19214) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x444c3940 (LWP 19215) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x44cc4940 (LWP 19216) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x454c5940 (LWP 19217) 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 3 Thread 0x45cc6940 (LWP 19218) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x464c7940 (LWP 19219) 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 * 1 Thread 0x2ad9964071e0 (LWP 18752) 0x00000037aac07b35 in pthread_join () from /lib64/libpthread.so.0 (gdb) thread 2 [Switching to thread 2 (Thread 0x464c7940 (LWP 19219))]#0 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 #1 0x0000003f22c2b963 in __db_pthread_mutex_lock_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #2 0x0000003f22d1e2dc in __memp_fget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #3 0x0000003f22c46a8f in __bam_search_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #4 0x0000003f22c34649 in ?? () from /usr/lib64/libslapd24_db-4.8.so #5 0x0000003f22c3534b in ?? () from /usr/lib64/libslapd24_db-4.8.so #6 0x0000003f22cd4bbf in __dbc_iput_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #7 0x0000003f22cd536f in __dbc_put_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #8 0x0000003f22cdca0f in __dbc_put_pp_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #9 0x00000000004c9d7e in bdb_idl_insert_key () #10 0x00000000004cbcb2 in bdb_key_change () (gdb) thread 4 [Switching to thread 4 (Thread 0x454c5940 (LWP 19217))]#0 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 #1 0x0000003f22c2b754 in __db_pthread_mutex_readlock_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #2 0x0000003f22d1e5fc in __memp_fget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #3 0x0000003f22cd3df9 in __dbc_iget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #4 0x0000003f22cdd43a in __dbc_get_pp_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #5 0x00000000004ca6d0 in bdb_idl_fetch_key () #6 0x00000000004cbd75 in bdb_key_read () In above case, thread 2 and thread 4 are deadlocked. The deadlock occurs within 2 - 8 hours after we start testing LDAP server on our BDII services. Meanwhile, OpenLDAP version 2.3 does not cause this deadlock, but it causes a gradual CPU usage increase until the performance degrades to the point where we need to restart the server. Is there anyway you could fix the deadlock issue on v2.4, or CPU usage issue on v2.3? Thanks, Soichi Hayashi

1 0

(ITS#7084) Password Modify Extended Operation to set pwdReset: TRUE
by michael＠stroeder.com 08 Nov '11

08 Nov '11

Full_Name: Version: OS: URL: Submission from: (NULL) (192.166.104.102) Feature Request: The Password Modify Extended Operation should set pwdReset: TRUE if the accompanying password policy specifies pwdMustChange: TRUE. Section 8.2.7 of http://tools.ietf.org/html/draft-behera-ldap-password-policy-09#section-8.2 says: If the value the pwdMustChange is TRUE and the modification is performed by a password administrator, then the pwdReset attribute is set to TRUE. Otherwise, the pwdReset is removed from the user's entry if it exists. So the question is how to determine whether the modification is performed by a password administrator. There could be an attribute in the password policy entry with values like authzTo/authzFrom to specify the set of password admins.

1 0

Re: (ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms
by h.b.furuseth＠usit.uio.no 07 Nov '11

07 Nov '11

Thank you. I've committed your fix. verbs_to_mask() adds bits to an existing mask. > (...) I'm not sure why this only > manifests on 64-bit architectures, as my reduced test case (can > provide if necessary) also fails on 32-bit architectures. Probably just a coincidence: There happens to be a 0 on the stack where the compiler puts the m variable on on your 32-bit hosts. -- Hallvard

1 0

(ITS#7083) Broken verb_to_mask() calls
by h.b.furuseth＠usit.uio.no 07 Nov '11

07 Nov '11

Full_Name: Hallvard B Furuseth Version: 2.3-2.4.26 OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard slapd/bconfig.c and contrib:smbk5pwd.c use verb_to_mask() as if it returned a bitmask instead of an index. This affects delete operations of restrict, allows, disallows, requires, syslog loglevel, and smbk5pwd modules.

1 0

(ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms
by zanchey＠ucc.gu.uwa.edu.au 07 Nov '11

07 Nov '11

Full_Name: David Adam Version: 2.4.23 OS: Debian URL: http://www.openldap.org/lists/openldap-technical/201111/msg00034.html Submission from: (NULL) (2001:44b8:6112:bc00:6ef0:49ff:fe74:26c4) On 64-bit machines using the contributed smbk5pwd overlay, the smbk5pwd module insists on trying to load all the Kerberos configuration regardless, even if smbk5PwdEnable is set to 'samba'. I suspect this has something to do with the call to verbs_to_mask() in smbk5pwd_cf_func (under the case PC_SMB_ENABLE) - my very basic printf() debugging shows that m is set correctly on 32-bit architectures but on 64-bit architectures returns a varying and strangely-numbered value (4511419, -1407332384, 353253328 in subsequent runs). The problem goes away if the m variable is initialised to 0 before the call to verbs_to_mask(). Most of the calls to verbs_to_mask() in the rest of the source initialise the fourth variable to 0 before calling. Either smbk5pwd also needs to do this, or the verbs_to_mask function needs to initialise the variable before use. I'm not sure why this only manifests on 64-bit architectures, as my reduced test case (can provide if necessary) also fails on 32-bit architectures.

1 0

Re: (ITS#7081) test020-proxycache failed for bdb
by hyc＠symas.com 04 Nov '11

04 Nov '11

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.128.242.48) > > > Seems there's a regression in HEAD's slapo-pcache possibly due to the recent > commits. Thanks for the report, fixed in master. > >>>>>> Starting test020-proxycache for bdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > Query 4: filter:(sn=Doe*) attrs:cn sn title uid > Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid > Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid > Query 7: filter:(mail=*) attrs:cn sn title uid > Query 8: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 9: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 10: filter:(|(cn=All Staff)(sn=All Staff)) attrs:sn cn title uid > undefinedAttr > Query 1 not cacheable > Query 2 cacheable > Query 3 cacheable > Query 4 cacheable > Query 5 cacheable > Query 6 cacheable > Query 7 not cacheable > Query 8 cacheable > Query 9 cacheable > Query 10 cacheable > Successfully verified cacheability > Query 11: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid > Query 12: filter:(sn=Smith) attrs:cn sn title uid > Query 13: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid > Query 14: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid > Query 15: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 16: filter:(uid=b*) attrs:mail > ldapsearch should have failed! >>>>>> test020-proxycache failed for bdb > (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/tests' > make: *** [test] Error 2 > m > > -- -- 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#7081) test020-proxycache failed for bdb
by michael＠stroeder.com 04 Nov '11

04 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.242.48) Seems there's a regression in HEAD's slapo-pcache possibly due to the recent commits. >>>>> Starting test020-proxycache for bdb... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: filter:(sn=Jon) attrs:all (expect nothing) Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid Query 3: filter:(sn=Smith*) attrs:cn sn uid Query 4: filter:(sn=Doe*) attrs:cn sn title uid Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid Query 7: filter:(mail=*) attrs:cn sn title uid Query 8: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 9: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 10: filter:(|(cn=All Staff)(sn=All Staff)) attrs:sn cn title uid undefinedAttr Query 1 not cacheable Query 2 cacheable Query 3 cacheable Query 4 cacheable Query 5 cacheable Query 6 cacheable Query 7 not cacheable Query 8 cacheable Query 9 cacheable Query 10 cacheable Successfully verified cacheability Query 11: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid Query 12: filter:(sn=Smith) attrs:cn sn title uid Query 13: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid Query 14: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid Query 15: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 16: filter:(uid=b*) attrs:mail ldapsearch should have failed! >>>>> test020-proxycache failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/tests' make: *** [test] Error 2 m

1 0

(ITS#7080) post read control in back-config
by michael＠stroeder.com 03 Nov '11

03 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.60.140) back-config should support the post read control so that applications can determine the possibly renumbered DN after adding/modifying an entry

1 0

(ITS#7079) back-mdb
by hyc＠OpenLDAP.org 03 Nov '11

03 Nov '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc back-mdb is working well in master, should be added to RE24 and marked Experimental.

1 0

(ITS#7078) slapadd should be pipelined
by hyc＠OpenLDAP.org 03 Nov '11

03 Nov '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc When using slapadd -q and tool-threads is > 1, slapadd should use a separate thread for reading/parsing the input LDIF, to allow it to run concurrently with the backend add operation. Already implemented in master.

1 0

(ITS#7077) olcMirrorMode implicit change not seen in cn=config
by christopher_wood＠pobox.com 03 Nov '11

03 Nov '11

Full_Name: Christopher Wood Version: 2.4.26 OS: Debian 6 (Squeeze) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.206.227.67) Quoth Howard Chu: "There's a bit of a glitch here; when you modify the olcSyncrepl attribute, it is internally a delete followed by an add. When the delete occurs, the olcMirrorMode flag is implicitly turned off. (Because it is only allowed to be On for a database that is being replicated.) When the add occurs, the flag is not automatically turned back on. "The solution is to set it explicitly in your LDAPModify request." http://www.openldap.org/lists/openldap-technical/201109/msg00010.html The issue is that when this implicit flag toggle happens, the directory still reports that olcMirrorMode is TRUE. Assuming starting with a working MMR pair, this reproduces the issue: $ ldapmodify -x -w password -D 'cn=config' -h ldapmm1 dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: password2 - replace: olcSyncrepl olcSyncrepl: rid=1 provider=ldap://ldapmm1 binddn="cn=config" bindmethod=simple credentials=password2 searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 olcSyncrepl: rid=2 provider=ldap://ldapmm2 binddn="cn=config" bindmethod=simple credentials=password2 searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 modifying entry "olcDatabase={0}config,cn=config" dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: password3 modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral $ ldapsearch -x -w password2 -D 'cn=config' -b 'olcDatabase={0}config,cn=config' -s base -h ldapmm1 '' 'olcMirrorMode' # extended LDIF # # LDAPv3 # base <olcDatabase={0}config,cn=config> with scope baseObject # filter: (objectclass=*) # requesting: olcMirrorMode # # {0}config, config dn: olcDatabase={0}config,cn=config olcMirrorMode: TRUE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

1 0

Re: (ITS#6981) slapd crashes when using sssvlv and pcache overlays
by hyc＠symas.com 02 Nov '11

02 Nov '11

h.b.furuseth(a)usit.uio.no wrote: > Though the original case is now fixed in master, this simpler test > case crashes in the same way. It forces REP_ENTRY_MUSTRELEASE to be > set, since the current fix is to restore OpenLDAP 2.4.23's behavior of > not flushing the entry otherwise. But 2.4.23 also crashes with this: > > $ cat<<EOF>its6981.conf > include servers/slapd/schema/core.schema > database bdb > suffix o=test > rootdn o=test > directory its6981/a > > overlay pcache > pcache bdb 10000 1 50 100 > pcacheAttrset 0 * + > pcacheTemplate (objectClass=) 0 60 > pcacheTemplate (o=) 0 60 > pcache-directory its6981/b > EOF > > $ mkdir -p its6981/a its6981/b; rm -f its6981/?/* > $ servers/slapd/slapd -Tadd -f its6981.conf<<EOF > dn: o=test > objectclass: organization > o: test > EOF > > $ servers/slapd/slapd -f its6981.conf -d0 -h ldap://localhost:3890/& > $ clients/tools/ldapsearch -LLLxh localhost:3890 -b o=test '(o=test)' > > > It doesn't seem to make sense for code to assume sr_entry persists > past the point it'd be flushed if REP_ENTRY_MUSTRELEASE is set. > That's why this change snuck into ITS#6758 (SlapyReply usage). > Probably we should put the flush back someday - after checking better > than I did last time. > OK, the flush is back to where it was in 2.4.26. pcache.c has been reorganized again, taking ITS#5112 into account. REP_RESULT handling is still in pcache_op_cleanup (as #5112 requires) but REP_SEARCH is back in op_response (where it used to be, before the #5112 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#6981) slapd crashes when using sssvlv and pcache overlays
by h.b.furuseth＠usit.uio.no 02 Nov '11

02 Nov '11

Though the original case is now fixed in master, this simpler test case crashes in the same way. It forces REP_ENTRY_MUSTRELEASE to be set, since the current fix is to restore OpenLDAP 2.4.23's behavior of not flushing the entry otherwise. But 2.4.23 also crashes with this: $ cat <<EOF >its6981.conf include servers/slapd/schema/core.schema database bdb suffix o=test rootdn o=test directory its6981/a overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * + pcacheTemplate (objectClass=) 0 60 pcacheTemplate (o=) 0 60 pcache-directory its6981/b EOF $ mkdir -p its6981/a its6981/b; rm -f its6981/?/* $ servers/slapd/slapd -Tadd -f its6981.conf <<EOF dn: o=test objectclass: organization o: test EOF $ servers/slapd/slapd -f its6981.conf -d0 -h ldap://localhost:3890/ & $ clients/tools/ldapsearch -LLLxh localhost:3890 -b o=test '(o=test)' It doesn't seem to make sense for code to assume sr_entry persists past the point it'd be flushed if REP_ENTRY_MUSTRELEASE is set. That's why this change snuck into ITS#6758 (SlapyReply usage). Probably we should put the flush back someday - after checking better than I did last time. -- Hallvard

1 0

(ITS#7076) Duplicate result messages on entry/searchref error
by h.b.furuseth＠usit.uio.no 01 Nov '11

01 Nov '11

Full_Name: Hallvard B Furuseth Version: all OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard If slap_send_search_entry() or slap_send_search_reference() fail, the client receives two responses. These functions should not send_ldap_error(). Their caller does that. Only tested with slap_send_search_entry(), by replacing the first 'if ( rc == -1 )' with 'if ( 1 )'.

1 0

Re: (ITS#7074) back-ldap module compilation issue with gcc 4.6.1
by hyc＠symas.com 01 Nov '11

01 Nov '11

stephane.paquot(a)gmail.com wrote: > Full_Name: Stéphane PAQUOT > Version: 2.4.26 > OS: Windows (MingW) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.194.186.14) > > > Hi > > I am actually compiling backend modules for openldap 2.4.26 with MingW (gcc > version 4.6.1, GNU make 3.81, GNU libtool 2.4, GNU automake 1.11.1, GNU autoconf > 2.68. > An issue occurs when compiling back-ldap module. > > The GNU tools used are the following : > host-triplet: i686-pc-mingw32 > shell: /bin/sh > compiler: gcc > compiler flags: -O3 -s -mms-bitfields -march=i386 -mtune=i686 > linker: c:/mingw/mingw32/bin/ld.exe (gnu? yes) > libtool: (GNU libtool) 2.4 > automake: automake (GNU automake) 1.11.1 > autoconf: autoconf (GNU Autoconf) 2.68 > > The command line to compile openldap 2.4.26 is the following > > ./configure --prefix=/software/openldap \ > --enable-slapd \ > --enable-modules \ > --enable-rewrite \ > --enable-bdb=mod \ > --enable-hdb=mod \ > --enable-ldap=mod \ > --enable-sql=mod \ > --enable-monitor=mod \ > --enable-accesslog=mod \ > --enable-auditlog=mod \ > --enable-rwm=mod \ > --enable-syncprov=mod \ > --with-odbc=odbc32 \ > --with-tls=openssl \ > --without-cyrus-sasl > > Here are the compilation flags : > CPPFLAGS="-I/software/openssl/include > -I/software/berkeleydb/berkeleydb-5.2/include" > LDFLAGS="-I/software/openssl/lib -I/software/berkeleydb/berkeleydb-5.2/lib" > LIBS="-lodbc32 -lws2_32" > > All backends modules and overlays compile fine but when compiling backend > back-ldap as a module, the following compile error occurs : error: initializer > element is not constant. > > $ make > /bin/sh ../../../libtool --tag=disable-static --mode=compile gcc -g -O2 > -std=c89 > -I../../../include -I../../../include -I.. -I./.. > -I/software/openssl/i > nclude -I/software/berkeleydb/berkeleydb-5.2/include -DSLAPD_IMPORT -c > chain.c > > gcc -g -O2 -std=c89 -I../../../include -I../../../include -I.. -I./.. > -I/softwa > re/openssl/include -I/software/berkeleydb/berkeleydb-5.2/include -DSLAPD_IMPORT > -c chain.c -DDLL_EXPORT -DPIC -o .libs/chain.o > chain.c:1273:3: error: initializer element is not constant > chain.c:1273:3: error: (near initialization for 'chainocs[1].co_table') > make: *** [chain.lo] Error 1 > > gcc 4.6.1 complains about > > static ConfigOCs chainocs[] = { > { "( OLcfgOvOc:3.1 " > "NAME 'olcChainConfig' " > "DESC 'Chain configuration' " > "SUP olcOverlayConfig " > "MAY ( " > #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR > "olcChainingBehavior $ " > #endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */ > "olcChainCacheURI $ " > "olcChainMaxReferralDepth $ " > "olcChainReturnError " > ") )", > Cft_Overlay, chaincfg, NULL, chain_cfadd }, > { "( OLcfgOvOc:3.2 " > "NAME 'olcChainDatabase' " > "DESC 'Chain remote server configuration' " > "AUXILIARY )", > Cft_Misc, olcDatabaseDummy, chain_ldadd > #ifdef SLAP_CONFIG_DELETE > , NULL, chain_lddel > #endif > }, > { NULL, 0, NULL} > }; > > I try to solve this problem but I'm a little stuck. When back-ldap is not > compiled as a module, no problem, slapd compiles fine with this backend > back-ldap. This type of problem seems to crop up regularly with Windows modules; the Windows linker is too stupid to figure out how to reference a data symbol from a different binary. In this case you can fix it by making a local copy of the definition of olcDatabaseDummy (which is in slapd/bconfig.c) and use the local copy in this table instead of the original. -- -- 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#7062) writes from lost connections not increasing contextCSN
by hyc＠symas.com 01 Nov '11

01 Nov '11

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4.26 > OS: any > URL: > Submission from: (NULL) (75.244.124.114) > > > If a client connects and writes, e.g. ADDs entries, then disconnects > before seeing the result, the writes are stored in the database but do > not increment contextCSN. This is an obvious consequence of the fact that checks for abandoned ops are performed before any response callbacks are invoked. The main op might have completed but no overlay code will run, so syncprov never gets a chance to update itself. (See result.c send_ldap_response()) The fix is less obvious. Probably we should only bypass the callbacks if rs->sr_err == SLAPD_ABANDON, meaning that the operation itself was actually aborted. -- -- 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#7075) back-perl initialization broken
by h.b.furuseth＠usit.uio.no 31 Oct '11

31 Oct '11

Full_Name: Hallvard B Furuseth Version: 2.4.17-2.4.26 OS: URL: http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/151… Submission from: (NULL) (193.71.61.60) Submitted by: hallvard back-perl initialization broken PERL_SYS_INIT3() is called with wrong arguments. Introduced by ITS#5658. Fixing it to do the same as the Perl main program, but I can not test it on a system where these params are used so it is relevant - e.g. Windows. - arg 3 (env) is NULL, but Perl:proto.h requires non-NULL. Fixing to use PERL_SYS_INIT() instead. That also affects Perl versions before 5.6. 5.6 introduced INIT3, INIT is older. The alternative would be to pass &(char **environ) to PERL_SYS_INIT3(), but who knows what Perl does with the environment. Seems simpler to avoid it. - PERL_SYS_INIT/INIT3() can change their arguments. back-perl passed the changed argc but not the changed argv to perl_parse(). Fixing to pass both the changed argc and the changed argv. - arg 2 is passed char *(*argv)[3]. Fixing to pass as a char ***argv: char *embedding[] = { "", "-e", "0", NULL }, **argv = embedding; char ***old = (char ***) &embedding, ***corrected = &argv; 'old' is how the address was passed, 'new' is how it should be passed. 'old' holds the address of the embedding array, but it should hold the address of a variable which holds that address. See comp.lang.perl.misc discussion "PERL_SYS_INIT()" from Oct 31 2011.

1 0

Re: (ITS#7072) caseIgnoreMatch equals regular capital I with dotted capital I
by hyc＠symas.com 31 Oct '11

31 Oct '11

Frank.Meisschaert(a)UGent.be wrote: > Full_Name: Frank Meisschaert > Version: 2.4.26 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (157.193.44.200) > > > When I try to add the names "İsmail" (original, with dotted capital I) and > "Ismail" (transcribed, regular capital I) to an entry using ldapmodify: > > dn: ... > changetype: modify > replace: givenName > givenName: Ismail > givenName:: xLBzbWFpbA== > - > > I get the error: > > ldap_modify: Type or value exists (20) > additional info: givenName: value #0 provided more than once > > The lowercase version of dotted and regular capital I is regular i which > explains this error. However according to unicode case folding the dotted > capital I should be mapped to 0069 0307 (i, combining dot above) which would > make Ismail andİsmail different when compared case-insensitively as I > would expect. Apparently our liblunicode implementation doesn't use the CaseFolding data. I believe that means our implementation corresponds to the "Simple" case folding rules. They're valid, just not doing what you want in this case. So it appears that this is an enhancement request. I don't believe this request warrants a very high priority. Looking at the Unicode charts, I-with-dot-above is the only character where the two case folding alternatives actually makes a difference. -- -- 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#7074) back-ldap module compilation issue with gcc 4.6.1
by stephane.paquot＠gmail.com 29 Oct '11

29 Oct '11

Full_Name: Stéphane PAQUOT Version: 2.4.26 OS: Windows (MingW) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.194.186.14) Hi I am actually compiling backend modules for openldap 2.4.26 with MingW (gcc version 4.6.1, GNU make 3.81, GNU libtool 2.4, GNU automake 1.11.1, GNU autoconf 2.68. An issue occurs when compiling back-ldap module. The GNU tools used are the following : host-triplet: i686-pc-mingw32 shell: /bin/sh compiler: gcc compiler flags: -O3 -s -mms-bitfields -march=i386 -mtune=i686 linker: c:/mingw/mingw32/bin/ld.exe (gnu? yes) libtool: (GNU libtool) 2.4 automake: automake (GNU automake) 1.11.1 autoconf: autoconf (GNU Autoconf) 2.68 The command line to compile openldap 2.4.26 is the following ./configure --prefix=/software/openldap \ --enable-slapd \ --enable-modules \ --enable-rewrite \ --enable-bdb=mod \ --enable-hdb=mod \ --enable-ldap=mod \ --enable-sql=mod \ --enable-monitor=mod \ --enable-accesslog=mod \ --enable-auditlog=mod \ --enable-rwm=mod \ --enable-syncprov=mod \ --with-odbc=odbc32 \ --with-tls=openssl \ --without-cyrus-sasl Here are the compilation flags : CPPFLAGS="-I/software/openssl/include -I/software/berkeleydb/berkeleydb-5.2/include" LDFLAGS="-I/software/openssl/lib -I/software/berkeleydb/berkeleydb-5.2/lib" LIBS="-lodbc32 -lws2_32" All backends modules and overlays compile fine but when compiling backend back-ldap as a module, the following compile error occurs : error: initializer element is not constant. $ make /bin/sh ../../../libtool --tag=disable-static --mode=compile gcc -g -O2 -std=c89 -I../../../include -I../../../include -I.. -I./.. -I/software/openssl/i nclude -I/software/berkeleydb/berkeleydb-5.2/include -DSLAPD_IMPORT -c chain.c gcc -g -O2 -std=c89 -I../../../include -I../../../include -I.. -I./.. -I/softwa re/openssl/include -I/software/berkeleydb/berkeleydb-5.2/include -DSLAPD_IMPORT -c chain.c -DDLL_EXPORT -DPIC -o .libs/chain.o chain.c:1273:3: error: initializer element is not constant chain.c:1273:3: error: (near initialization for 'chainocs[1].co_table') make: *** [chain.lo] Error 1 gcc 4.6.1 complains about static ConfigOCs chainocs[] = { { "( OLcfgOvOc:3.1 " "NAME 'olcChainConfig' " "DESC 'Chain configuration' " "SUP olcOverlayConfig " "MAY ( " #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR "olcChainingBehavior $ " #endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */ "olcChainCacheURI $ " "olcChainMaxReferralDepth $ " "olcChainReturnError " ") )", Cft_Overlay, chaincfg, NULL, chain_cfadd }, { "( OLcfgOvOc:3.2 " "NAME 'olcChainDatabase' " "DESC 'Chain remote server configuration' " "AUXILIARY )", Cft_Misc, olcDatabaseDummy, chain_ldadd #ifdef SLAP_CONFIG_DELETE , NULL, chain_lddel #endif }, { NULL, 0, NULL} }; I try to solve this problem but I'm a little stuck. When back-ldap is not compiled as a module, no problem, slapd compiles fine with this backend back-ldap. Best regards and many thanks to you. Stéphane PAQUOT Database Administrator (Sybase, Oracle, MS SQL Server, MySQL). France, Paris.

1 0

Re: (ITS#7010) Deadlock in Producer/Consumer Nodes
by ghola＠rebelbase.com 28 Oct '11

28 Oct '11

Here is the data requested from the most recent lock-up. Default locking region information: 14 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 160 Number of lock object partitions 27 Number of current locks 682 Maximum number of locks at any one time 5 Maximum number of locks in any one bucket 0 Maximum number of locks stolen by for an empty partition 0 Maximum number of locks stolen for any one partition 63 Number of current lockers 63 Maximum number of lockers at any one time 21 Number of current lock objects 377 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 13M Total number of locks requested (13581842) 13M Total number of locks released (13581804) 0 Total number of locks upgraded 13 Total number of locks downgraded 6 Lock requests not available due to conflicts, for which we waited 1 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 808KB The size of the lock region 15280 The number of partition locks that required waiting (0%) 10921 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 4742 The number of locker allocations that required waiting (0%) 0 The number of region locks that required waiting (0%) 3 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aeb3285c000 Region address 0x2aeb3285c138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 327 allocations, 0 failures, 0 frees, 1 longest Allocations by power-of-two sizes: 1KB 322 2KB 0 4KB 0 8KB 0 16KB 1 32KB 2 64KB 0 128KB 1 256KB 1 512KB 0 1024KB 0 REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 262177 Lock region region mutex [0/450861 0% 15746/47187942583984] 1031 locker table size 1031 object table size 952 obj_off 122400 locker_off 1 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=22 locks held 1 write locks 0 pid/thread 7123/47021676422512 priority 100 1 READ 1 HELD id2entry.bdb handle 0 2 dd=21 locks held 1 write locks 0 pid/thread 7123/47021676422512 priority 100 2 READ 1 HELD dn2id.bdb handle 0 3 dd=20 locks held 0 write locks 0 pid/thread 7123/47021676422512 priority 100 4 dd=16 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 4 READ 1 HELD entryUUID.bdb handle 0 5 dd=15 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 5 READ 1 HELD modifyTimestamp.bdb handle 0 6 dd=12 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 6 READ 1 HELD cn.bdb handle 0 7 dd=11 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 7 READ 1 HELD givenName.bdb handle 0 8 dd=10 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 8 READ 1 HELD sn.bdb handle 0 9 dd= 9 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 9 READ 1 HELD objectClass.bdb handle 0 a dd= 6 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 a READ 1 HELD uid.bdb handle 0 b dd= 5 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 b READ 1 HELD uidNumber.bdb handle 0 c dd= 4 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 c READ 1 HELD gidNumber.bdb handle 0 d dd= 3 locks held 1 write locks 0 pid/thread 7123/1121872192 priority 100 d READ 1 HELD sambaSID.bdb handle 0 e dd= 2 locks held 1 write locks 0 pid/thread 7123/1121872192 priority 100 e READ 1 HELD sambaPrimaryGroupSID.bdb handle 0 80000380 dd=14 locks held 0 write locks 0 pid/thread 7123/1121872192 priority 100 80000381 dd=13 locks held 0 write locks 0 pid/thread 7123/1092884800 priority 100 80000003 dd=19 locks held 0 write locks 0 pid/thread 7123/47021676422512 priority 100 80000004 dd=18 locks held 0 write locks 0 pid/thread 7123/47021676422512 priority 100 80000005 dd=17 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 80000005 READ 1 HELD 0x3dc78 len: 9 data: a2b007000000000000 80000938 dd= 8 locks held 0 write locks 0 pid/thread 7123/1138657600 priority 100 80000939 dd= 7 locks held 0 write locks 0 pid/thread 7123/1130264896 priority 100 80048a47 dd= 1 locks held 0 write locks 0 pid/thread 7123/1147050304 priority 100 800dc266 dd= 0 locks held 11 write locks 5 pid/thread 7123/1138657600 priority 100 800dc266 WRITE 1 WAIT 0x3dc78 len: 9 data: a2b007000000000000 800dc266 READ 2 HELD dn2id.bdb page 11658 800dc266 WRITE 4 HELD dn2id.bdb page 11658 800dc266 READ 2 HELD objectClass.bdb page 115 800dc266 WRITE 2 HELD objectClass.bdb page 115 800dc266 READ 1 HELD objectClass.bdb page 3 800dc266 READ 1 HELD entryUUID.bdb page 2839 800dc266 WRITE 2 HELD entryUUID.bdb page 2839 800dc266 READ 1 HELD modifyTimestamp.bdb page 3168 800dc266 WRITE 2 HELD modifyTimestamp.bdb page 3168 800dc266 WRITE 3 HELD id2entry.bdb page 14475 800dc266 READ 1 HELD 0x36718 len: 9 data: 9cb007000000000000 800dc268 dd= 0 locks held 0 write locks 0 pid/thread 7123/1163835712 priority 100 800dc269 dd= 0 locks held 0 write locks 0 pid/thread 7123/1155443008 priority 100 800dc26a dd= 0 locks held 0 write locks 0 pid/thread 7123/1172228416 priority 100 800dc26b dd= 0 locks held 0 write locks 0 pid/thread 7123/1180621120 priority 100 800dc26c dd= 0 locks held 0 write locks 0 pid/thread 7123/1189013824 priority 100 800dc26d dd= 0 locks held 0 write locks 0 pid/thread 7123/1197406528 priority 100 800dc26e dd= 0 locks held 0 write locks 0 pid/thread 7123/1205799232 priority 100 800dc26f dd= 0 locks held 0 write locks 0 pid/thread 7123/1214191936 priority 100 800dc270 dd= 0 locks held 0 write locks 0 pid/thread 7123/1222584640 priority 100 800dc271 dd= 0 locks held 0 write locks 0 pid/thread 7123/1230977344 priority 100 800dc272 dd= 0 locks held 0 write locks 0 pid/thread 7123/1239370048 priority 100 800dc273 dd= 0 locks held 0 write locks 0 pid/thread 7123/1247762752 priority 100 800dc274 dd= 0 locks held 0 write locks 0 pid/thread 7123/1256155456 priority 100 800dc275 dd= 0 locks held 0 write locks 0 pid/thread 7123/1264548160 priority 100 800dc276 dd= 0 locks held 0 write locks 0 pid/thread 7123/1272940864 priority 100 800dc277 dd= 0 locks held 0 write locks 0 pid/thread 7123/1289726272 priority 100 800dc278 dd= 0 locks held 0 write locks 0 pid/thread 7123/1281333568 priority 100 800dc279 dd= 0 locks held 0 write locks 0 pid/thread 7123/1298118976 priority 100 800dc27a dd= 0 locks held 0 write locks 0 pid/thread 7123/1306511680 priority 100 800dc27b dd= 0 locks held 0 write locks 0 pid/thread 7123/1314904384 priority 100 800dc27c dd= 0 locks held 0 write locks 0 pid/thread 7123/1331689792 priority 100 800dc27d dd= 0 locks held 0 write locks 0 pid/thread 7123/1340082496 priority 100 800dc27e dd= 0 locks held 0 write locks 0 pid/thread 7123/1348475200 priority 100 800dc27f dd= 0 locks held 0 write locks 0 pid/thread 7123/1356867904 priority 100 800dc280 dd= 0 locks held 0 write locks 0 pid/thread 7123/1365260608 priority 100 800dc281 dd= 0 locks held 0 write locks 0 pid/thread 7123/1373653312 priority 100 800dc282 dd= 0 locks held 0 write locks 0 pid/thread 7123/1382046016 priority 100 800dc283 dd= 0 locks held 0 write locks 0 pid/thread 7123/1390438720 priority 100 800dc284 dd= 0 locks held 0 write locks 0 pid/thread 7123/1407224128 priority 100 800dc285 dd= 0 locks held 0 write locks 0 pid/thread 7123/1398831424 priority 100 800dc286 dd= 0 locks held 0 write locks 0 pid/thread 7123/1415616832 priority 100 800dc287 dd= 0 locks held 0 write locks 0 pid/thread 7123/1424009536 priority 100 800dc288 dd= 0 locks held 0 write locks 0 pid/thread 7123/1432402240 priority 100 800dc289 dd= 0 locks held 0 write locks 0 pid/thread 7123/1440794944 priority 100 800dc28a dd= 0 locks held 0 write locks 0 pid/thread 7123/1449187648 priority 100 800dc28b dd= 0 locks held 0 write locks 0 pid/thread 7123/1457580352 priority 100 800dc28c dd= 0 locks held 0 write locks 0 pid/thread 7123/1474365760 priority 100 800dc28d dd= 0 locks held 0 write locks 0 pid/thread 7123/1465973056 priority 100 800dc28e dd= 0 locks held 0 write locks 0 pid/thread 7123/1482758464 priority 100 800dc28e READ 1 WAIT dn2id.bdb page 11658 800dc28f dd= 0 locks held 0 write locks 0 pid/thread 7123/1491151168 priority 100 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 800dc266 READ 2 HELD objectClass.bdb page 115 800dc266 WRITE 2 HELD objectClass.bdb page 115 800dc266 WRITE 3 HELD id2entry.bdb page 14475 4 READ 1 HELD entryUUID.bdb handle 0 1 READ 1 HELD id2entry.bdb handle 0 b READ 1 HELD uidNumber.bdb handle 0 80000005 READ 1 HELD 0x3dc78 len: 9 data: a2b007000000000000 800dc266 WRITE 1 WAIT 0x3dc78 len: 9 data: a2b007000000000000 e READ 1 HELD sambaPrimaryGroupSID.bdb handle 0 2 READ 1 HELD dn2id.bdb handle 0 800dc266 READ 1 HELD entryUUID.bdb page 2839 800dc266 WRITE 2 HELD entryUUID.bdb page 2839 a READ 1 HELD uid.bdb handle 0 6 READ 1 HELD cn.bdb handle 0 800dc266 READ 1 HELD 0x36718 len: 9 data: 9cb007000000000000 800dc266 READ 1 HELD modifyTimestamp.bdb page 3168 800dc266 WRITE 2 HELD modifyTimestamp.bdb page 3168 d READ 1 HELD sambaSID.bdb handle 0 c READ 1 HELD gidNumber.bdb handle 0 5 READ 1 HELD modifyTimestamp.bdb handle 0 8 READ 1 HELD sn.bdb handle 0 7 READ 1 HELD givenName.bdb handle 0 800dc266 READ 1 HELD objectClass.bdb page 3 9 READ 1 HELD objectClass.bdb handle 0 800dc266 READ 2 HELD dn2id.bdb page 11658 800dc266 WRITE 4 HELD dn2id.bdb page 11658 800dc28e READ 1 WAIT dn2id.bdb page 11658

1 0

(ITS#7073) zero-length entries should be allowed
by hyc＠OpenLDAP.org 27 Oct '11

27 Oct '11

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc entry_header() rejects "entries" that have zero attributes. As it turns out, overlays like pcache and translucent can create such entries in their normal operation. With back-bdb/hdb, such entries will work OK while slapd is running, because they're in the entry cache. But after a restart, such entries can't be read back from the DB because they're considered invalid by entry_header(). Already fixed in master, entry_header() now allows zero length entries.

1 0

(ITS#7072) caseIgnoreMatch equals regular capital I with dotted capital I
by Frank.Meisschaert＠UGent.be 27 Oct '11

27 Oct '11

Full_Name: Frank Meisschaert Version: 2.4.26 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (157.193.44.200) When I try to add the names "İsmail" (original, with dotted capital I) and "Ismail" (transcribed, regular capital I) to an entry using ldapmodify: dn: ... changetype: modify replace: givenName givenName: Ismail givenName:: xLBzbWFpbA== - I get the error: ldap_modify: Type or value exists (20) additional info: givenName: value #0 provided more than once The lowercase version of dotted and regular capital I is regular i which explains this error. However according to unicode case folding the dotted capital I should be mapped to 0069 0307 (i, combining dot above) which would make Ismail and İsmail different when compared case-insensitively as I would expect.

1 0

Re: (ITS#7054) Please drop support to FreeBSD 1.x
by d＠delphij.net 24 Oct '11

24 Oct '11

Just a headsup -- libtool 2.4.2 should have the required changes to support FreeBSD 10.x. Cheers, -- Xin LI <delphij(a)delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die

1 0

Re: (ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL
by massimo.gravino＠pd.infn.it 24 Oct '11

24 Oct '11

On Mon, 24 Oct 2011, jvcelak(a)redhat.com wrote: > I believe this is a bug in Mozilla NSS and not in OpenLDAP. I have > successfully reproduced on Fedora. > > If you are interested in some details from my investigation, check: > https://bugzilla.redhat.com/show_bug.cgi?id=748394 > > -- > Jan V?el?k > Base Operating Systems Brno > Red Hat Inc. Thank you very much, I'll follow the discussion about this bug at bugzilla.redhat.com Best regards, Massimo Gravino System Administrator National Institute of Nuclear Physics - Padova (Italy)

1 0

Re: (ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL
by jvcelak＠redhat.com 24 Oct '11

24 Oct '11

I believe this is a bug in Mozilla NSS and not in OpenLDAP. I have successfully reproduced on Fedora. If you are interested in some details from my investigation, check: https://bugzilla.redhat.com/show_bug.cgi?id=748394 -- Jan Vèelák Base Operating Systems Brno Red Hat Inc.

1 0

Re: (ITS#7067) openldap not properly starting
by masarati＠aero.polimi.it 24 Oct '11

24 Oct '11

On 10/24/2011 07:18 AM, sanjiv.singh(a)impetus.co.in wrote: > --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > How can I redirect to openldap-technical mailing list ? > Not getting any link for this . Subscribe to openldap-technical <http://www.openldap.org/lists/mm/listinfo/openldap-technical>; post your message to <mailto:openldap-technical@openldap.org> -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7067) openldap not properly starting
by sanjiv.singh＠impetus.co.in 23 Oct '11

23 Oct '11

--_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How can I redirect to openldap-technical mailing list ? Not getting any link for this . Regards, Sanjiv Singh ________________________________ New Impetus webcast on-demand 'Big Data Technologies for Social Media Analy= tics' available at http://bit.ly/nFdet0. Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style>  </style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <pre>How can I redirect to openldap-technical mailing list ?</pre> <p class=3D"MsoNormal">Not getting any  link for this .</p> <p class=3D"MsoNormal"> </p> <p class=3D"MsoNormal"><span style=3D"font-size:7.5pt; font-family:"Ta= homa","sans-serif"; color:gray">Regards,</span></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt; font-family:&quo= t;Arial","sans-serif"">Sanjiv Singh</span></b><span style=3D= "font-size:7.5pt; font-family:"Tahoma","sans-serif"; co= lor:gray"> </span></p> <p class=3D"MsoNormal"> </p> <p class=3D"MsoNormal"> </p> </div> <br> <hr> <font face=3D"Verdana" color=3D"Gray" size=3D"1"><br> New Impetus webcast on-demand ‘Big Data Technologies for Social Media= Analytics’ available at http://bit.ly/nFdet0. <br> <br> Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling <br> <br> <br> NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference.<br> </font> </body> </html> --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_--

1 0

Re: (ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Reproduced in master by trying to change olcSaslHost: config_modify_internal() does this with a == NULL: 5827 a->a_flags |= SLAP_ATTR_IXADD; jeffreyc(a)ucsc.edu writes: > To guarantee the removal of an attribute when I don't know if the attribute > exists already or not I often employ the following LDIF: > > ============== > dn: cn=config > changeType: modify > replace: attrToDelete > attrToDelete: dummy > - > delete: attrToDelete > ============== You can use this instead: dn: cn=config changeType: modify replace: attrToDelete - -- Hallvard

1 0

Re: (ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

I wrote: > slap_send_search_entry() does not always free/release the entry and > call slap_cleanup_play() on error. > > slap_send_search_reference() calls slap_cleanup_play(), but does not > always free/release the entry. > > I expect both functions always should do both, but don't know enough > myself to be sure. > > Resolution needed for ITS#6758 (SlapReply) - who should be responsible > for clearing out the entry? Nobody else were picking this up, and it was making back-monitor hang in ITS#7053. So I've made result.c always clean up. The code is still inconsistent: slap_send_search_entry() may flush the entry either before or after slap_cleanup_play(), while slap_send_search_reference() always flushes first. If anyone feels that should be regularized, feel free. I'm leaving it alone for now. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Fixed in master, dup of ITS#6763. Thank you for the simple test case. The '-z 10' identified the problem. slap_send_search_entry() did not call rs_flush_entry() when sizeLimitExceeded. I have not traced exactly what happened, but I expect this means some back-monitor entry kept its locks. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

This is still an issue also in HEAD.

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

But just for the records... Finally I managed to reproduce this with OpenLDAP's ldapsearch command-line tool. The bound entity needs read access to cn=monitor. Try this more than one time: ldapsearch -x -H ldapi://%2Ftmp%2Fopenldap-socket -b "cn=monitor" -z 10 -s one "(objectClass=*)" cn objectclass Do this as many times as you have threads configured and slapd becomes completely unresponsive and has to be stopped by kill -9. This was tested on my local install under openSUSE 11.4 but also on an installation running on HP-UX (64 bit build). Both running 2.4.26. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs