openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

slapd.conf more readable in ITS: -------------------------------------------------------------------------------- include /home/michael/temp/openldap-testbed-its7390/schema/init.schema # Define global ACLs to disable default read access. pidfile /home/michael/temp/openldap-testbed-its7390/run/slapd-1.pid argsfile /home/michael/temp/openldap-testbed-its7390/run/slapd-1.args modulepath /opt/openldap-RE24/libexec/openldap moduleload back_hdb.la moduleload rwm.la # Root DSE: allow anyone to read it access to dn.base="" by * read # Subschema (sub)entry DSE: allow anyone to read it access to dn.base="cn=Subschema" by * read database hdb suffix "dc=example,dc=com" directory /home/michael/temp/openldap-testbed-its7390/db/bv rootdn "uid=diradm,dc=example,dc=com" rootpw testsecret lastmod on # Index-Konfiguration index objectClass eq checkpoint 200 5 # Entries to cache in memory cachesize 1000 # Search results to cache in memory idlcachesize 100 sizelimit -1 # DB_CONFIG parameters dbconfig set_cachesize 0 20000000 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 262144 dbconfig set_lg_max 10485760 dbconfig set_tas_spins 0 access to dn.subtree="dc=example,dc=com" by * write overlay rwm rwm-rewriteEngine on # rewrite map for (uid=foo) with DN of entry as result rwm-rewriteMap slapd uid2dn "ldap:///dc=example,dc=com?entryDN?sub?uid="

1 0

Re: (ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by hyc＠symas.com 14 Sep '12

14 Sep '12

michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------030803020000090707060805 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 7bit > > See slapd.conf attached. What is init.schema? Is it required to reproduce the 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#7388) [PATCH] MozNSS: ignore certdb 'sql:' prefix when checking directory existence
by hyc＠symas.com 14 Sep '12

14 Sep '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120914-moznss-ignore-certdb-sql-p… > Submission from: (NULL) (209.132.186.34) > > > Mozilla NSS certificate database in newer SQL format could not be used with > OpenLDAP, because the 'sql:' prefix is not removed while checking for the > existence of the directory. > > The attached patch resolves this problem. The patch looks syntactically correct. But SQL, seriously? As if TLS handshakes weren't slow enough already, you want to slow them down even further by looking up certs in an SQL database? Aside from questioning the wisdom of such an inefficient approach, there are other philosophical problems with this patch. It seems to be just the latest in a continuing stream of one-off patches. Are we going to get yet another special case patch from you guys when some other new certDB type comes along? This approach is unmaintainable and does nothing to inspire confidence in the quality of thinking going into this code. You're working on a security library. We expect a lot better thought to go into these things. > Steps to reproduce are described in Red Hat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=857373 > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- 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#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

This is a multi-part message in MIME format. --------------030803020000090707060805 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit See slapd.conf attached. --------------030803020000090707060805 Content-Type: text/plain; charset=UTF-8; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.conf" IwojIFNlZSBzbGFwZC5jb25mKDUpIGZvciBkZXRhaWxzIG9uIGNvbmZpZ3VyYXRpb24gb3B0 aW9ucy4KIyBUaGlzIGZpbGUgc2hvdWxkIE5PVCBiZSB3b3JsZCByZWFkYWJsZS4KIwoKaW5j bHVkZQkJL2hvbWUvbWljaGFlbC90ZW1wL29wZW5sZGFwLXRlc3RiZWQtaXRzNzM5MC9zY2hl bWEvaW5pdC5zY2hlbWEKCiMgRGVmaW5lIGdsb2JhbCBBQ0xzIHRvIGRpc2FibGUgZGVmYXVs dCByZWFkIGFjY2Vzcy4KCnBpZGZpbGUJCS9ob21lL21pY2hhZWwvdGVtcC9vcGVubGRhcC10 ZXN0YmVkLWl0czczOTAvcnVuL3NsYXBkLTEucGlkCmFyZ3NmaWxlCS9ob21lL21pY2hhZWwv dGVtcC9vcGVubGRhcC10ZXN0YmVkLWl0czczOTAvcnVuL3NsYXBkLTEuYXJncwoKbW9kdWxl cGF0aAkvb3B0L29wZW5sZGFwLVJFMjQvbGliZXhlYy9vcGVubGRhcAoKIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj CiMgTG9hZCBkeW5hbWljIGJhY2tlbmQgbW9kdWxlczoKIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCm1vZHVsZWxv YWQJYmFja19oZGIubGEKCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojIExvYWQgZHluYW1pYyBvdmVybGF5IG1v ZHVsZXM6CiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIwptb2R1bGVsb2FkCXJ3bS5sYQoKIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMg R2xvYmFsIGFjY2VzcyBjb250cm9sCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKIyBSb290IERTRTogYWxsb3cg YW55b25lIHRvIHJlYWQgaXQKYWNjZXNzIHRvIGRuLmJhc2U9IiIgYnkgKiByZWFkCiMgU3Vi c2NoZW1hIChzdWIpZW50cnkgRFNFOiBhbGxvdyBhbnlvbmUgdG8gcmVhZCBpdAphY2Nlc3Mg dG8gZG4uYmFzZT0iY249U3Vic2NoZW1hIiBieSAqIHJlYWQKCgoKIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMKIyBEYXRlbmJhbmsgZnVlciBOYW1lbnNyYXVtIG91PXNjaHVsdW5nLGRjPXN0cm9lZGVy LGRjPWxvY2FsCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgpkYXRhYmFzZQloZGIKCnN1ZmZpeAkJIm91 PXNjaHVsdW5nLGRjPXN0cm9lZGVyLGRjPWxvY2FsIgpkaXJlY3RvcnkJL2hvbWUvbWljaGFl bC90ZW1wL29wZW5sZGFwLXRlc3RiZWQtaXRzNzM5MC9kYi9idgpyb290ZG4JCSJ1aWQ9ZGly YWRtLG91PXNjaHVsdW5nLGRjPXN0cm9lZGVyLGRjPWxvY2FsIgpyb290cHcJCXRlc3RzZWNy ZXQKbGFzdG1vZAkJb24KCiMgSW5kZXgtS29uZmlndXJhdGlvbgppbmRleCBvYmplY3RDbGFz cwkJZXEKaW5kZXggY24sc24sZGlzcGxheU5hbWUsZ2l2ZW5OYW1lLG1haWwsbyxvdSx0ZWxl cGhvbmVOdW1iZXIsaG9tZVBob25lLG1vYmlsZSBzdWIsZXEKaW5kZXggdWlkLHVpZE51bWJl cixnaWROdW1iZXIsaG9tZURpcmVjdG9yeSxtZW1iZXIsbWFuYWdlcixvd25lcixzZWVBbHNv LGRlcGFydG1lbnROdW1iZXIgZXEKCmNoZWNrcG9pbnQgMjAwIDUKCiMgRW50cmllcyB0byBj YWNoZSBpbiBtZW1vcnkKY2FjaGVzaXplIDEwMDAKIyBTZWFyY2ggcmVzdWx0cyB0byBjYWNo ZSBpbiBtZW1vcnkKaWRsY2FjaGVzaXplIDEwMAoKc2l6ZWxpbWl0CS0xCgojIERCX0NPTkZJ RyBwYXJhbWV0ZXJzCmRiY29uZmlnIHNldF9jYWNoZXNpemUgICAwICAgICAgIDIwMDAwMDAw ICAgICAgICAxCmRiY29uZmlnIHNldF9sZ19yZWdpb25tYXggICAgICAgIDI2MjE0NApkYmNv bmZpZyBzZXRfbGdfYnNpemUgICAgICAgICAgICAyNjIxNDQKZGJjb25maWcgc2V0X2xnX21h eCAgICAgICAgICAgICAgMTA0ODU3NjAKZGJjb25maWcgc2V0X3Rhc19zcGlucyAwCgojIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMgQmVyZWNodGlndW5nZW4gaW0gTmFtZW5zcmF1 bSBvdT1zY2h1bHVuZyxkYz1zdHJvZWRlcixkYz1sb2NhbAojIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjCgphY2Nlc3MgdG8gZG4uc3VidHJlZT0ib3U9c2NodWx1bmcsZGM9c3Ryb2Vk ZXIsZGM9bG9jYWwiCiAgICBieSAqIHdyaXRlCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjCiMgT3ZlcmxheXMgZnVlciBOYW1lbnNyYXVtIG91PXNjaHVsdW5nLGRjPXN0cm9lZGVy LGRjPWxvY2FsCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCm92ZXJsYXkgcndtCnJ3 bS1yZXdyaXRlRW5naW5lIG9uCgojIHJld3JpdGUgbWFwIGZvciAodWlkPWZvbykgd2l0aCBE TiBvZiBlbnRyeSBhcyByZXN1bHQKcndtLXJld3JpdGVNYXAgc2xhcGQgdWlkMmRuICJsZGFw Oi8vL291PXNjaHVsdW5nLGRjPXN0cm9lZGVyLGRjPWxvY2FsP2VudHJ5RE4/c3ViP3VpZD0i Cgo= --------------030803020000090707060805--

1 0

Re: (ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

This is a multi-part message in MIME format. --------------050607060501060102050805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit See bt full attached. --------------050607060501060102050805 Content-Type: text/plain; charset=UTF-8; name="bt_full.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bt_full.txt" #0 0x00007f1699909ab5 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f169990afb6 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f1699944dd3 in __libc_message () from /lib64/libc.so.6 No symbol table info available. #3 0x00007f169994a3b6 in malloc_printerr () from /lib64/libc.so.6 No symbol table info available. #4 0x00007f169ca6fbed in ber_memfree_x (p=0x820778, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #5 0x0000000000462a23 in ch_free (ptr=0x820778) at ch_malloc.c:139 ctx = 0x0 #6 0x00000000004ab8fc in slapd_rw_destroy (private=0x820700) at sasl.c:1093 md = 0x820700 __PRETTY_FUNCTION__ = "slapd_rw_destroy" #7 0x00000000004e5532 in rewrite_builtin_map_free (tmp=0x81e110) at map.c:487 map = 0x81e110 __PRETTY_FUNCTION__ = "rewrite_builtin_map_free" #8 0x00000000004f1cb5 in avl_free (root=0x8205f0, dfree=0x4e54c7 <rewrite_builtin_map_free>) at avl.c:515 nleft = 0 nright = 0 #9 0x00000000004e4645 in rewrite_info_delete (pinfo=0x81f690) at info.c:120 info = 0x820420 __PRETTY_FUNCTION__ = "rewrite_info_delete" #10 0x00007f1696d78e3f in rwm_db_destroy (be=0x81eba0, cr=0x0) at rwm.c:2664 rwmap = 0x81f690 on = 0x820240 rc = 0 #11 0x00000000004cee6e in over_db_destroy (be=0x81eba0, cr=0x0) at backover.c:208 oi = 0x820060 on = 0x820240 next = 0x462a23 bi_orig = 0x820060 rc = 0 #12 0x000000000044e833 in backend_stopdown_one (bd=0x81eba0) at backend.c:438 No locals. #13 0x000000000044e928 in backend_destroy_one (bd=0x81eba0, dynamic=1) at backend.c:452 No locals. #14 0x000000000044ea8e in backend_destroy () at backend.c:491 bd = 0x81eba0 bi = 0x7fff07f1e7b0 #15 0x000000000047a55f in slap_destroy () at init.c:247 rc = 0 #16 0x00000000004d6bd8 in slap_tool_destroy () at slapcommon.c:932 rc = 0 #17 0x00000000004db6c4 in slapschema (argc=3, argv=0x7fff07f1ecf8) at slapschema.c:161 id = 18446744073709551615 rc = 0 progname = 0x518180 "slapschema" conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = { bv_len = 0, bv_val = 0x4f5fd0 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f5fd0 ""}, c_listener = 0x4fdf40, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x453d4f <slap_send_ldap_result>, c_send_search_entry = 0x454a57 <slap_send_search_entry>, c_send_search_reference = 0x456a6e <slap_send_search_reference>, c_send_ldap_extended = 0x4545b6 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x454834 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fff07f1e560, o_tag = 0, o_time = 1347638558, o_tincr = 0, o_bd = 0x81eba0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = { bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = { rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7fff07f1e6a8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = { stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7fff07f1e7b0, oh_msgid = 0, oh_protocol = 0, oh_tid = 139735100856160, oh_threadctx = 0x7f169ced89c0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x75b3e0, oh_counters = 0x75e8e0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7fff07f1e3f0 thrctx = 0x7f169ced89c0 requestBSF = 0 doBSF = 0 __PRETTY_FUNCTION__ = "slapschema" #18 0x0000000000415c6e in main (argc=3, argv=0x7fff07f1ecf8) at main.c:410 i = 5 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 0 waitfds = {1, 32534} g_argc = 3 g_argv = 0x7fff07f1ecf8 configfile = 0x0 configdir = 0x0 serverName = 0x7fff07f20313 "slapschema" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f5a68 "" l = 0 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" --------------050607060501060102050805--

1 0

(ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

Full_Name: Version: 2.4.32 OS: Debian Squeeze URL: Submission from: (NULL) (212.227.35.94) Config with the following lines works as expected but slapschema crashes no matter whether slapd is running or not: -------------------------------------------------------------------------- overlay rwm rwm-rewriteEngine on # rewrite map for (uid=foo) with DN of entry as result rwm-rewriteMap slapd uid2dn "ldap:///ou=um-demail?entryDN?sub?uid=" -------------------------------------------------------------------------- This is self-compiled OpenLDAP 2.4.32 on Debian Squeeze linked against OpenSSL and BDB 4.8.30. Example config will follow. Maybe I even can reproduce on another system and provide gdb output.

1 0

(ITS#7389) [PATCH] MozNSS: load certificates from certdb, fallback to PEM
by jvcelak＠redhat.com 14 Sep '12

14 Sep '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120914-moznss-load-certs-from-cer… Submission from: (NULL) (209.132.186.34) If TLS_CACERT pointed to a PEM file and TLS_CACERTDIR was set to NSS certificate database, the backend assumed that the certificate is always located in the certificate database. This assumption might be wrong. This patch makes the library to try to load the certificate from NSS database and fallback to PEM file if unsuccessfull. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7388) [PATCH] MozNSS: ignore certdb 'sql:' prefix when checking directory existence
by jvcelak＠redhat.com 14 Sep '12

14 Sep '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120914-moznss-ignore-certdb-sql-p… Submission from: (NULL) (209.132.186.34) Mozilla NSS certificate database in newer SQL format could not be used with OpenLDAP, because the 'sql:' prefix is not removed while checking for the existence of the directory. The attached patch resolves this problem. Steps to reproduce are described in Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=857373 The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7387) submit a contribution
by philippe.eychart＠mail.pf 13 Sep '12

13 Sep '12

Full_Name: Philippe EYCHART Version: 2 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.70.54) My work is fully described and available here: http://homepage.gna.org/ldapcppei/miniHowto.en.html Regards. PE

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by marco＠schirrmeister.net 13 Sep '12

13 Sep '12

--Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 12, 2012, at 7:49 PM, hyc(a)symas.com wrote: > Frank.Swasey(a)uvm.edu wrote: >> Full_Name: Francis Swasey >> Version: 2.4.32 >> OS: RHEL6.3 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (132.198.21.181) >>=20 >>=20 >> In exploring converting to back_mdb, I have discovered a problem = which results >> in the following symptoms: >=20 > Thanks for the report, fixed now in git master. I saw it is also merged into the RE24 branch. I tried today the latest commit from the RE24 branch and I did not see = the error anymore in the slapadd tool. Where I noticed the No space left = on device error before. But I'm seeing it now when I run the slapindex. Unfortunately I can't reproduce it with a test dataset that I created. Probably because I have not enough attributes that I could add to index = like on the real server. If I run slapindex a second time, again error. If I run slapindex a third time, no error. The data.mdb grew a little bit during the slapindex runs. =46rom about 710MB to 1,2GB. If I remove a few index options, slapindex runs through without a = problem. The output on the test server looks like below. [root@ds71 ~]# slapadd2.4 -b dc=3Dogilvy,dc=3Dcom -l all_slapcat.ldif=20 _#################### 100.00% eta none elapsed 05m26s spd = 596.0 k/s=20 Closing DB... [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 5051fea8 =3D> mdb_tool_entry_reindex: txn_commit failed: No space left = on device (28) [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 50520b10 =3D> mdb_tool_entry_reindex: txn_commit failed: No space left = on device (28) [root@ds71 ~]#=20 [root@ds71 ~]# slapindex2.4=20 [root@ds71 ~]#=20 Since you wrote ENOSPC can only be happen in 2 places, I thought it's = still related somehow. I'm a little bit clueless right now what else I can provide. If there is something that I can provide, then let me know please and I = try to provide it. -- Marco --Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Sep 12, 2012, at 7:49 PM, <a = href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a> wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><a = href=3D"mailto:Frank.Swasey@uvm.edu">Frank.Swasey(a)uvm.edu</a><span = class=3D"Apple-converted-space"> </span>wrote:<br><blockquote = type=3D"cite">Full_Name: Francis Swasey<br></blockquote><blockquote = type=3D"cite">Version: 2.4.32<br></blockquote><blockquote = type=3D"cite">OS: RHEL6.3 64-bit<br></blockquote><blockquote = type=3D"cite">URL:<span class=3D"Apple-converted-space"> </span><a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote><blockquote type=3D"cite">Submission from: (NULL) = (132.198.21.181)<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">In exploring = converting to back_mdb, I have discovered a problem which = results<br></blockquote><blockquote type=3D"cite">in the following = symptoms:<br></blockquote><br>Thanks for the report, fixed now in git = master.</span></blockquote></div><br><div>I saw it is also merged into = the RE24 branch.</div><div><br></div><div>I tried today the latest = commit from the RE24 branch and I did not see the error anymore in the = slapadd tool. Where I noticed the No space left on device = error before.</div><div>But I'm seeing it now when I run the = slapindex.</div><div><br></div><div>Unfortunately I can't reproduce it = with a test dataset that I created.</div><div>Probably because I have = not enough attributes that I could add to index like on the real = server.</div><div><br></div><div>If I run slapindex a second time, again = error.</div><div>If I run slapindex a third time, no = error.</div><div><br></div><div>The data.mdb grew a little bit during = the slapindex runs.</div><div>=46rom about 710MB to = 1,2GB.</div><div><br></div><div>If I remove a few index options, = slapindex runs through without a problem.</div><div><br></div><div>The = output on the test server looks like below.</div><div><div>[root@ds71 = ~]# slapadd2.4 -b dc=3Dogilvy,dc=3Dcom -l = all_slapcat.ldif </div><div>_#################### 100.00% eta =   none elapsed          05m26s spd 596.0 = k/s </div><div>Closing DB...</div><div>[root@ds71 = ~]# </div><div>[root@ds71 ~]# slapindex2.4 </div><div>5051fea8 = =3D> mdb_tool_entry_reindex: txn_commit failed: No space left on = device (28)</div><div>[root@ds71 ~]# </div><div>[root@ds71 ~]# = slapindex2.4 </div><div>50520b10 =3D> mdb_tool_entry_reindex: = txn_commit failed: No space left on device (28)</div><div>[root@ds71 = ~]# </div><div>[root@ds71 ~]# = slapindex2.4 </div><div>[root@ds71 = ~]# </div></div><div><br></div><div><br></div><div>Since you wrote = ENOSPC can only be happen in 2 places, I thought it's still related = somehow.</div><div>I'm a little bit clueless right now what else I can = provide.</div><div><br></div><div>If there is something that I can = provide, then let me know please and I try to provide = it.</div><div><br></div><div><br></div><div>--</div><div>Marco</div><div><= br></div><div><br></div></body></html>= --Apple-Mail=_D316E30E-F1E5-480E-A47A-F4610B0C33C6--

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