openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6065) slapcat with sql (postgres) backend
by frederic.bouy＠gmail.com 17 Apr '09

17 Apr '09

Full_Name: Frederic Bouy Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.255.106.203) When running the following command: slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 I get this error message: <==backsql_load_schema_map() ==>backsql_free_db_conn() ==>backsql_close_db_handle(0x8290c18) <==backsql_close_db_handle(0x8290c18) <==backsql_free_db_conn() <==backsql_db_open(): test succeeded, schema map loaded slapcat: database doesn't support necessary operations. ldapsearch is successfull. Do you have any clue on how to solve this issue? Thanks for your help.

1 0

Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 17 Apr '09

17 Apr '09

--0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: multipart/alternative; Boundary="1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841" --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable This is a full Backtrace - about 200 MB of Real Memory available(from 2= GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpthread.a(shr_xpg5.o= ) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread.a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o) No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o) No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a(shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_malloc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at search.c:1013 bdb =3D (struct bdb_info *) 0x20188b98 ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4, scopes=3D0x26379= bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98 rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result =3D 640653996, f= _un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un_ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9aac}, f_next =3D 0= x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_result =3D 640654008, = f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_un_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9ab8}, f_next =3D 0= x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_result =3D 640653972, = f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_un_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a94}, f_next =3D 0= x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 0, f_un_desc = =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra =3D 0x0, f_un_complex =3D = 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D {bv_len =3D 8,= bv_val =3D 0x102dbf2c "r\ef\erral"}} sf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 641440756, f_= un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9bf4}, f_next =3D 0= x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D {bv_len =3D 0, b= v_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x263ba824) at sear= ch.c:578 bdb =3D (struct bdb_info *) 0x20188b98 id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>} scopes =3D {0 <repeats 63759 times>, 641435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 641434656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 641434672, 0, 0, 0, 32,= 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 2567258180, 3490905504, 0= , 641434768, 4030840384, 4112, 0, 4030805596, 4030426872, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 3490902496, 0, 6414348= 00, 4030840384, 58, 22528, 0, 144, 0, 269721729, 269721729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 641434880, 4030840384= , 3490883944, 0, 641434896, 4030840384, 3490889600, 641435752, 641434896,= 4030840384, 3491274292, 0, 0, 641437345, 641437340, 1, 0, 1, 40304311= 12, 4030431112, 641434960, 0, 3490885628, 641435752, 641435008, 4030840384,= 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992, 0, 0, 641435752= , 641435008, 4031927728, 3491274292, 608035800, 641435072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0, 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3491266240, 0= , 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14, 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times>, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 678360812, bv_val = =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"}, e_attrs =3D= 0x3, e_ocflags =3D 641440736, e_bv =3D {bv_len =3D 641440832, bv_val =3D 0xf= 041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc= =3Dsozv \ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 77770, mode =3D DB_LO= CK_READ} opinfo =3D (struct bdb_op_info *) 0x0 ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backover.c:646 func =3D (BI_op_bind **) 0x200012b4 rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 on =3D (slap_overinst *) 0x20189e78 be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\001\000\000\001\001\00= 0 \001", '\0' <repeats 17 times>, "\001", be_flags =3D 2312, be_restricto= ps =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0= , sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}= , be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28, be_schemadn =3D {b= v_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, b= e_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootndn =3D {bv_len =3D 34, bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootpw =3D {bv_len =3D 5, bv_val =3D 0x20187138 "start"}, be_max_deref_depth =3D= 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D= -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide= =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D 0, bv_val =3D= 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20356508, be_pcl_mu= tex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_= cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_next =3D {stqe_next =3D 0x201= 92308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x2001e51c: 0x100d553= c <over_back_response>, sc_cleanup =3D @0x0: 0x1, sc_private =3D 0x20189d= 68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x263ba824) at searc= h.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff "dc=3Dpva,dc=3Ds= ozv \ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c out of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba95c, arg_v=3D0x243= de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, s= r_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, = sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0= x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0= , r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r= _v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 #15 0x1006c848 in connection_read_thread (ctx=3D0x263ba95c, argv=3D0x20= ) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1, arg =3D 0x0, ct= x =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x200c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8 work_list =3D (ldap_int_tpool_plist_t *) 0x200c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_key =3D 0x2001e2ac,= ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x1006b814 <conn_counter_destroy>= }, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, ltk_free =3D @0x2= 001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk_key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D 0x51eadec0,= ltk_free =3D @0x200201fc: 0x1020f550 <bdb_locker_id_free>}, {ltk_= key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0: 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0 i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c "" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpthread.a(shr_xpg5.= o) No symbol table info available. Mit freundlichen Gr=FC=DFen Howard ALLISON Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: howard.allison(a)pva.sozvers.at Internet: www.pensionsversicherung.at -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient you are notified that any dissemination, distribution, use or copying of this communication is strictly prohibited. If you received this message in error, please immediately destroy this message. --------------------------= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> This is a full Backtrace - about 200 MB of Real Mem= ory available(from 2 GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpth= read.a(shr_xpg5.o) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread= .a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o)= No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o)= No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a= (shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_mal= loc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at se= arch.c:1013 bdb =3D (struct bdb_info *) 0x20188b98<= br> ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, = rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4,= scopes=3D0x26379bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98<= br> rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result= =3D 640653996, f_un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un= _ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9a= ac}, f_next =3D 0x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_resul= t =3D 640654008, f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_u= n_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9a= b8}, f_next =3D 0x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_resul= t =3D 640653972, f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_u= n_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a= 94}, f_next =3D 0x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 0, f_un_desc =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra = =3D 0x0, f_un_complex =3D 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D= {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"}}<b= r> sf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 641440756, f_un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_= ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9b= f4}, f_next =3D 0x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D= {bv_len =3D 0, bv_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2= c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x= 263ba824) at search.c:578 bdb =3D (struct bdb_info *) 0x20188b98<= br> id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>= } scopes =3D {0 <repeats 63759 times>, 641= 435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, = 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 6414= 34656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 6414= 34672, 0, 0, 0, 32, 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 25672581= 80, 3490905504, 0, 641434768, 4030840384, 4112, 0, 4030805596, 40304268= 72, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 34909= 02496, 0, 641434800, 4030840384, 58, 22528, 0, 144, 0, 269721729, 26972= 1729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 6414= 34880, 4030840384, 3490883944, 0, 641434896, 4030840384, 3490889600, 64= 1435752, 641434896, 4030840384, 3491274292, 0, 0, 641437345, 641437340, = 1, 0, 1, 4030431112, 4030431112, 641434960, 0, 3490885628, 641435752, 6= 41435008, 4030840384, 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992= , 0, 0, 641435752, 641435008, 4031927728, 3491274292, 608035800, 641435= 072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0,= 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3= 491266240, 0, 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14= , 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times&gt= ;, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 6= 78360812, bv_val =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D = 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers= ,dc=3Dat"}, e_attrs =3D 0x3, e_ocflags =3D 641440736, e_bv =3D {bv= _len =3D 641440832, bv_val =3D 0xf041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e= 94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 7777= 0, mode =3D DB_LOCK_READ} opinfo =3D (struct bdb_op_info *) 0x0<b= r> ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x= 0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs= =3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backove= r.c:646 func =3D (BI_op_bind **) 0x200012b4 = rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D= 0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 = on =3D (slap_overinst *) 0x20189e78 = be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x= 20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\= 001\000\000\001\001\000\001", '\0' <repeats 17 times>, &quot= ;\001", be_flags =3D 2312, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, ss= s_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0,= sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_s= imple_bind =3D 0}, be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28,= be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, b= v_val =3D 0x0}, be_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootndn =3D {bv_len =3D 34,<br= > bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootpw =3D {bv_len =3D 5, bv_val =3D = 0x20187138 "start"}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D= 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_= pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D= 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D = 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20= 356508, be_pcl_mutex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, = 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, b= e_pb =3D 0x0, be_cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_n= ext =3D {stqe_next =3D 0x20192308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x20= 01e51c: 0x100d553c <over_back_response>, sc_cleanup =3D @0x0: 0x1= , sc_private =3D 0x20189d68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x2= 63ba824) at search.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff= "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c ou= t of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba9= 5c, arg_v=3D0x243de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, = sr_msgid =3D 0, sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_r= ef =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D= {r_rspoid =3D 0x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0= , r_attr_flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_= nentries =3D 0, r_v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 = #15 0x1006c848 in connection_read_thread (ctx=3D0x263b= a95c, argv=3D0x20) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1= , arg =3D 0x0, ctx =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D= 0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x2= 00c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8= work_list =3D (ldap_int_tpool_plist_t *) 0x200= c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_ke= y =3D 0x2001e2ac, ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x= 1006b814 <conn_counter_destroy>}, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, = ltk_free =3D @0x2001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk= _key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10= 009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D= 0x51eadec0, ltk_free =3D @0x200201fc: 0x1020f550 <bdb_loc= ker_id_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0= : 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0</fo= nt> i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c &q= uot;" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpt= hread.a(shr_xpg5.o) No symbol table info available. Mit freundlichen Gr=FC=DFen<= b> Howard ALLISON <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"95"><img src=3D"cid:1__=3D4EBBFF08DFA38= 8418f9e8a93d(a)pva.sozvers.at" width=3D"83" height=3D"52"></td><td width=3D= "237" valign=3D"middle">Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: <a href=3D"mailto:howard.allison@pva.sozvers.at"><f= ont size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">howard.allison@= pva.sozvers.at</a><b= r> Internet: <a href=3D"http://www.pensionsversicherung.at/"><fo= nt size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">www.pensionsvers= icherung.at</a></td></tr> </table> -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen = bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the indiv= iduality or entity to which it is addressed and may contain information that is pri= vileged, confidential and exempt from disclosure. If you are not the intended re= cipient you are notified that any dissemination, distribution, use or copying of this c= ommunication is strictly prohibited. If you received this message in error, please imme= diately destroy this message. -------------------------- </body></html>= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841-- --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: image/gif; name="18476766.gif" Content-Disposition: inline; filename="18476766.gif" Content-ID: <1__=4EBBFF08DFA388418f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhUwA0APcAAA4Rm9DR2jw/qpaYw3Z4sx4hoLy9zldZsIGDtTEzpbGyztbe3lBSr6ipyY+R vDg7p2xursnL1UZJqhgaoSosoEFDpsTF1dLT2hganp+iwIaIwmNmqyEpnGxvtnt8vbe40sHC0aap z1VXsklLpoeJuxwfn46QxZmZzF1fsdHS2WxuuTQ3piAjoSotpL6/09zd3kxPrRQXnVVYpmdptoqN vczMzKutzj0/p7i60nFztVRXrHp7tJqdwKqrxlpdskJFrJKUvn+AumJktdfY3LW2zYKFvZKUxqSl xr3F1khLrSQopM3O1igrpGpstpydxNbW1v4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AADYLuB3EgMwABIBAACV8AAAOQA8AAAAAACeAgAAAQAAAIhkWAAgwBUAqAZWAAIAAAC88hIA2Vi0 d9UHAYXk8hIAAgAAACj0EgAc8xIAotfhdxIDMAASAQAAlfAAADkAPAABAAAAEgEAAJXwAAASAzAA SLkVANi1FQAgACAAAAAVACAAIAAAABUARgBlAHIAdABpAGcAAAASAAAAAAD8iOd3AAAAAAAAAADV BwGFiGRYADzzEgDxoeF3EgMwAAIDJwASAQAAlfAAADkAPAAAABMAlfAAAKqHRQASAzAAAgMnAAAB AAAkAAAAOQA8AKEAAACIZFgApPYSABgVOwB3wrR3KAM4AGhWEwAgAQAA2LUVAAAAAAAAAAAA0PMS AJUriHcINoh3/////+DzEgAec+d3AAATAAgAFAAYAQAAbJxIAGibSACJOOh3AAAAAAAAAAAAAAAA AAAAAETaRABsnEgA9MIVAHlWEwB5m0gA/////2hWEwB32EQAbJxIACH5BAEAAFAALAAAAABTADQA QAj/AKEIHEiwoMGDCBMqXMiwYcIhAyRgmEixIgYWD1BosAEiwoUhIIc4hBJBAQ0hK2LE0KFgZMIB Fi22ADEywoyJNA42mWARwcENGDqIJBhgKMMHMZPONFjEYgeDFlpMuJHCIA0nBkEwSTqRREEaSiIk tLB14gAoDWIuLTgkgFu3LpygYMGTKxCEBOomDWIQJgAPLgewyNHQQhAdD1hwpaiycYkEhKGAqHrw QsQJE5QUCeCys+fPoEMvHBKXAGIlJVJjXjyxBIUbKIo0sCDaJQm6rHPr5lrAAMMIRIwyHAJDL9e1 nSFgaFkwAgXMP4QLhGmRCc2BATZcT5hgN/KRRBRT/9wwGgbrB0sKQpgQOWGAG5iPEBwCJEEBFwad xNgdk4XvgQ2UUN0O6RVkgASY+XBBbdJBMcQHNORAwABERNDgQhdYoIAJTVRQgkos6ECDCxfWZuKJ KIL2AQFI8TcRC0wkkMADNNLYAgsCVlTACCRslyJBNuWoWwEuUtSCBB04QZtCCnQgAQ2UfTbEDMZR VIAPMwih5ZZc+pBEWRMl0ASXWpqXlHw/EiTDfot955AQMWRg0BAjVITCQU1RNINwRGDFUBBVKuWj QDSUwMKhK/RgkAuHLklQDxgo4ehACghZUQJiYXeDotx5N6iDKYQaZUFO5AhDiUStwFpOBDkBgAkJ of+glw0osFmRmwsFgEJSgMUaKEUrZDrQERgAwBxCH4h3p0BHPIcZrgPYWmQDBgHxawFeNYcgAGc5 dIRi1DYUbZGXZkpEaiVIEMSnJHWQIw2oNgTCBuGmudASRzTRgkqQsWsvQhd8AEQODDzQQgFEWqRS ai3ccEAOAyhgQbz/VmzxxRhn7FAALjQAxA5CyMAADEmUnIQOKHRQxAAcLaixSwE0kMOX5LLWgg4k BPfyQBc4cYB4uSUggRBBsIyDBREsofTSFuBgwwBFzDBCdy/OcOy/R5hpsxAEEDDDAUnc8MAKZD9w gwQ6COEBEDZMrNAFRARRAQVC/HfiESv8WrN3OBf/iJAFJCCAH2hDdKD33kUuazEB0lZEgbAPgVDE A5itwFlzVFd0g8sEEdFtbQYoYbO/CeW1uUE2WGodVC1MhALnUKTQA8UANq4W6WOxAMNBNGAWn0Ep 3GBRtgMNgKZC5+qG6xIf4OC83wSlNcNBVE5QxEEMJNWeQA4IsZAOnhpEgkXTF2TBcz6x9cABP+l9 vEAo6KBQ5qP3ZfYNDn/qgugYfD4QSAbZweGu16oY2CAhrVMe7hIiBIqU4IALoc5i6iUQIMRgewVp 0UWaYCkjLdAgF0iCcZRgt4P0oIMW2QFbbvCqhPSOIgoAgRKqhKuEKEBrFrEcQvbHGh4YRAcxYALk /wxyk4kQUDC3+lQDEoC/G6wATKwZQYOWkIBfxWAH0gHBvlgAPbxgJgF+MwD4MIAr/exNcQIZgkRi UgFOAWkEE4iBUBxChBnKz3wkmJRAzLg3AhBkV0bKQQkH4oQqxmAGsPNWDH6QSIQMAACIwwABWZQD G1zoAkBo0Q8gGBob3ABWDkkBCBQwABJ4QAU+0IEqdXAAtRWBbS5YQrwiQIMfYEYJORgcii5whCGS JIa0GwlpBiCEBCwMBgPw5css4IQmwKACN4CBEHJQBCMcoQHYxKYTjFCEHAghCSsoQGOYAAMCNOCD O6tMBFygABs4wQRAiGcInBfLRqbznvjMZ4oCAgA7 --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841--

1 0

ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by linamat＠telco.md 17 Apr '09

17 Apr '09

I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. According to ITS#5860 slapd should not allocate more memory than it was specified. In fact I have the same behaviour as it was with previous version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for set_cachesize 300 MB). But slapd process continuosly grows in memory until 32-bit limit then crashes due to unavalable memory resources. I need to mention bdb database size is less then 1 GB. After restart it rapidly consumes 1.5 GB RSS in few minutes and then it grows beyond the limit during 24 hours. The more queries are processing the more memory it eats. I am using this database for logging which size grows. The question is: is it possible to use 32-bit openldap with relatively large database sizes that override 32-bit per-process memory space? My slapd.conf contains: threads 64 concurrency 50 cachesize 200000 dncachesize 400000 idlcachesize 600000 shm_key 10 DB_CONFIG: set_cachesize 0 300097152 1 set_lk_max_locks 1000000 set_lk_max_lockers 1000000 set_lk_max_objects 1000000 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 ls -ls ./openldap-data total 1212876 -rw-r--r-- 1 slapd nobody 640 Apr 17 08:42 DB_CONFIG -rw------- 1 slapd nobody 8 Apr 16 10:50 __db.001 -rw-r--r-- 1 slapd nobody 4096 Apr 16 10:50 alock -rw------- 1 slapd nobody 6053888 Apr 17 09:50 cn.bdb -rw------- 1 slapd nobody 1024000 Apr 17 09:50 dhcpHWAddress.bdb -rw------- 1 slapd nobody 96583680 Apr 17 09:50 dn2id.bdb -rw------- 1 slapd nobody 515637248 Apr 17 09:50 id2entry.bdb -rw------- 1 slapd nobody 1343488 Apr 17 09:50 objectClass.bdb Any help would be much appreciated. Regards, Sergey.

1 0

(ITS#6064) syncrepl.c does not compile ("//" comment)
by h.b.furuseth＠usit.uio.no 16 Apr '09

16 Apr '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard C89 chokes on this comment from syncrepl.c 1.445: // add new syncrepl to end of list (same order as when deleting) Fixing.

1 0

Re: (ITS#6063) Syncrepl replication be_modify failed (18)
by michael＠stroeder.com 16 Apr '09

16 Apr '09

wan(a)ccs.neu.edu wrote: > I've been battling some issues with syncrepl for a while now, and I > can't quite figure out what has gone wrong. > [..] > and am still having issues (now at > 2.4.15) Could you please try 2.4.16 released a couple of days ago? There were four syncrepl-related fixes in this release. Not sure whether one of the fixes really solves your particular problem but please give it a try. Maybe it would also help if you try to get more detailed logs by starting slapd with -d on the console. (You might also need to use -u and/or -g option to use the demon user.) Ciao, Michael.

1 0

Re: (ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by quanah＠zimbra.com 15 Apr '09

15 Apr '09

--On Wednesday, April 15, 2009 5:52 PM +0000 rps2(a)socal.rr.com wrote: > Full_Name: Rick Stevens > Version: 2.4.16 > OS: Fedora 10, x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.200.106.34) > > > Compilation fails when compiling the libraries/liblutil/getpeereid.c > file. Under Fedora 10, one must include the line: > > #define _GNU_SOURCE > > somewhere near the top of the file to ensure the system can pick up the > size of the "ucred" structure. This is a duplicate of ITS#5464 and will be closed. The fix will be in the next release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6063) Syncrepl replication be_modify failed (18)
by wan＠ccs.neu.edu 15 Apr '09

15 Apr '09

Full_Name: Will Nowak Version: 2.4.15 OS: Ubuntu Hardy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.239.45.4) [Creating an ITS issue of the email thread with the same subject] I've been battling some issues with syncrepl for a while now, and I can't quite figure out what has gone wrong. I initially found http://www.openldap.org/lists/openldap-software/200812/msg00040.html which seemed to describe my issue, and it recommended upgrading to openldap 2.4.13. I tried that, and am still having issues (now at 2.4.15). I built the software for ubuntu hardy on i386, available at https://edge.launchpad.net/~compbrain/+archive/ppa/+sourcepub/566951/+listi… The situation involves a master with 3 slaves using syncrepl. A change comes into the master adding a member to a nisNetgroup/groupOfNames hybrid container: dn: cn=friends,ou=netgroup,dc=example,dc=com objectClass: groupOfNames objectClass: nisNetgroup objectClass: top cn: friends member: uid=bobby,ou=people,dc=example,dc=com nisNetgroupTriple: (,bobby,shadow) An incoming add for user james looks like dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com member: uid=james,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) nisNetgroupTriple: (,james,shadow) Up until this point, everything is fine -- all changes made on the master have replicated ok to the slaves. Now, james is not my friend anymore, so he gets removed from the container: dn: cn=friends,ou=netgroup,dc=example,dc=com changetype: modify delete: member - add: member member: uid=bobby,ou=people,dc=example,dc=com - delete: nisNetgroupTriple - add: nisNetgroupTriple nisNetgroupTriple: (,bobby,shadow) At this point, the most recent change gets applied to the master ok, but it does not get replicated to the slaves. They have a be_modify failed in their logs: Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_search (0) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 cn=friends,ou=netgroup,dc=example,dc=com Apr 13 23:05:43 sl1 slapd[30277]: null_callback : error code 0x12 Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify (18) Apr 13 23:05:43 sl1 slapd[30277]: syncrepl_entry: rid=049 be_modify failed

1 0

(ITS#6062) Compile failure in libraries/liblutil/getpeereid.c
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) Compilation fails when compiling the libraries/liblutil/getpeereid.c file. Under Fedora 10, one must include the line: #define _GNU_SOURCE somewhere near the top of the file to ensure the system can pick up the size of the "ucred" structure.

1 0

(ITS#6061) ./configure messups on NDB and Perl backends
by rps2＠socal.rr.com 15 Apr '09

15 Apr '09

Full_Name: Rick Stevens Version: 2.4.16 OS: Fedora 10, x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.200.106.34) The help text in the configure script for OpenLDAP 2.4.16 states: --enable-ndb enable MySQL NDB Cluster backend no|yes|mod [no] ... --enable-perl enable perl backend no|yes|mod [no] Which indicate that, by default, the MySQL Cluster NDB and Perl back-ends will not be built. This is not the case. The system tries to configure those back-ends. The "make depend" completes normally, but the "make" aborts when trying to compile those back-ends. In the case of the Perl back-end, configure does not find the necessary headers and reports that fact, however it does not set flags to block compilation of that module. On a separate identical machine, I did install the items necessary to build those back-ends. However, the system can't find the necessary headers even though they exist. For NDB, one must install the "mysql-devel" RPM. However, the path for finding the headers isn't correct. On Fedora 10, the include path must include "-I/usr/include/mysql/ndb/ndbapi". For Perl, one must install the "perl-devel" RPM, and the path for finding headers must include "-I/usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE".

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 15 Apr '09

15 Apr '09

David wrote: > Yup this works, good work, thanks. > > Seems a tad slow though, do filters like these drastically slow down the > search? It applies some overhead: for each value of each attribute of each entry it needs to check whether the memberOf attr is present; if it is, a berval comparison is needed (compare the length first, and the value in case of match). As usual, it depends on the structure of your data. Also, but this is independent of ACL evaluation, slapo-rwm duplicates each entry as soon as it needs to do some manipulation on it (like massaging the DNs and so). If you notice any significant overhead, you might want to profile the execution of your slapd, to point out what's the actual bottleneck. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs