- openldap-bugs - openldap.org

Re: (ITS#8156) triggering MDB_PAGE_FULL
by sergej.jurecko＠gmail.com 28 May '15

28 May '15

--089e0160aab816893f05171d9e22 Content-Type: text/plain; charset=UTF-8 Thank you for the explanation. Sergej On Wed, May 27, 2015 at 10:32 AM, Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > On 27/05/15 09:00, sergej.jurecko(a)gmail.com wrote: > >> Using a dupsort and writing a large value (which is still bellow >> maxkeysize) >> will result in MDB_PAGE_FULL. >> (...) >> maxkeysize=10000 >> > > Too big MDB_MAXKEYSIZE. Its doc says: > "Keys and MDB_DUPSORT data items must fit on a node in a regular page." > > But the doc should clarify that MDB_MAXKEYSIZE can be set big enough > to break lmdb. > > Or mdb_env_open() can fail if the computed me_maxkey would be smaller. > > Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that, > and then fail if the page size would be unsupported. (MIN_PAGESIZE > can be computed at compile time, with some ugly macros.) > > lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=0. > Some time ago, that was 1/3 of the size you could reasonably use > (to allow 1 key + sub-page with 2 dupsort values), so it could make > sense to define MDB_MAXKEYSIZE above the safe max. Today lmdb > uses a sub-DB at once if a sub-page would be too small, though. > So I don't see much need to support maxkeysize > safe max. > --089e0160aab816893f05171d9e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Thank you for the explanation. <br><br><br></div>Serg= ej<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On We= d, May 27, 2015 at 10:32 AM, Hallvard Breien Furuseth <span dir=3D"ltr">&lt= ;<a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth= @usit.uio.no</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27/= 05/15 09:00, <a href=3D"mailto:sergej.jurecko@gmail.com" target=3D"_blank">= sergej.jurecko(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Using a dupsort and writing a large value (which is still bellow=C2=A0 maxk= eysize)<br> will result in MDB_PAGE_FULL.<br> (...)<br> maxkeysize=3D10000<br> </blockquote> <br> Too big MDB_MAXKEYSIZE.=C2=A0 Its doc says:<br> "Keys and MDB_DUPSORT data items must fit on a node in a regular page.= "<br> <br> But the doc should clarify that MDB_MAXKEYSIZE can be set big enough<br> to break lmdb.<br> <br> Or mdb_env_open() can fail if the computed me_maxkey would be smaller.<br> <br> Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that,<br> and then fail if the page size would be unsupported.=C2=A0 (MIN_PAGESIZE<br= > can be computed at compile time, with some ugly macros.)<br> <br> lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=3D0.<br> Some time ago, that was 1/3 of the size you could reasonably use<br> (to allow 1 key + sub-page with 2 dupsort values), so it could make<br> sense to define MDB_MAXKEYSIZE above the safe max.=C2=A0 Today lmdb<br> uses a sub-DB at once if a sub-page would be too small, though.<br> So I don't see much need to support maxkeysize > safe max.<br> </blockquote></div><br></div> --089e0160aab816893f05171d9e22--

1 0

(ITS#8157) txn can be useless after mdb_txn_renew()
by h.b.furuseth＠usit.uio.no 27 May '15

27 May '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.14 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_txn_renew() may initialize txn halfway and then fail. After that, it refuses to work even when it should have succeeded, since the txn looks active (mt_dbxs != NULL). Fixing.

1 0

Re: (ITS#8156) triggering MDB_PAGE_FULL
by h.b.furuseth＠usit.uio.no 27 May '15

27 May '15

On 27/05/15 10:33, h.b.furuseth(a)usit.uio.no wrote: > (blah...) > So I don't see much need to support maxkeysize > safe max. Sorry, I should I said there's no need to recommend changing MDB_MAXKEYSIZE as anything else than 0, except if you need to make sure old liblmdb versions can use the database. I don't want to restart the discussion about which errors to catch yet again.

1 0

Re: (ITS#8156) triggering MDB_PAGE_FULL
by h.b.furuseth＠usit.uio.no 27 May '15

27 May '15

On 27/05/15 09:00, sergej.jurecko(a)gmail.com wrote: > Using a dupsort and writing a large value (which is still bellow maxkeysize) > will result in MDB_PAGE_FULL. > (...) > maxkeysize=10000 Too big MDB_MAXKEYSIZE. Its doc says: "Keys and MDB_DUPSORT data items must fit on a node in a regular page." But the doc should clarify that MDB_MAXKEYSIZE can be set big enough to break lmdb. Or mdb_env_open() can fail if the computed me_maxkey would be smaller. Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that, and then fail if the page size would be unsupported. (MIN_PAGESIZE can be computed at compile time, with some ugly macros.) lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=0. Some time ago, that was 1/3 of the size you could reasonably use (to allow 1 key + sub-page with 2 dupsort values), so it could make sense to define MDB_MAXKEYSIZE above the safe max. Today lmdb uses a sub-DB at once if a sub-page would be too small, though. So I don't see much need to support maxkeysize > safe max.

1 0

(ITS#8156) triggering MDB_PAGE_FULL
by sergej.jurecko＠gmail.com 27 May '15

27 May '15

Full_Name: Sergej Jurecko Version: lmdb latest OS: osx 10.9.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.189.172.218) Using a dupsort and writing a large value (which is still bellow maxkeysize) will result in MDB_PAGE_FULL. Program here: http://pastebin.com/Mu6bp1DR Compiling with: gcc pagefull.c mdb.c midl.c -g -DMDB_MAXKEYSIZE=10000 -o pagefull Running ./pagefull maxkeysize=10000 writing keysize=12, datasize=4063 Cursor put eror=-30786

1 0

(ITS#8155) add support for cacertdir with gnutls
by ryan＠openldap.org 27 May '15

27 May '15

Full_Name: Ryan Tandy Version: OS: URL: Submission from: (NULL) (142.31.146.2) Submitted by: ryan GnuTLS recently (3.3.6) finally added an API for adding a directory of CA files: http://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fcertificate… https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certif… Haven't actually tried it yet, but I think it should allow us to implement cacertdir. Just filing this for tracking right now, patch to come later.

1 0

(ITS#8154) sizeLimit/timeLimit are described as Multi-value in slapd-config man page
by elecharny＠apache.org 26 May '15

26 May '15

Full_Name: Emmanuel Lecharny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.190.108.22) The slapd-config man page says that we can store the sizeLimit and timeLimit values as multiple values, when they are single value attributes (at least they should be...) : olcTimeLimit: time[.{soft|hard}]=<integer> [...] Specify the maximum number of seconds (in real time) slapd will spend answering a search request. The default time limit is 3600. Use unlimited to specify no limits. The second format allows a fine grain setting of the time limits. Extra args can be added ***in the same value or as additional values***. See olcLimits for an explanation of the different flags.

1 0

(ITS#8153) olcTimeLimit should be Single Value
by elecharny＠apache.org 26 May '15

26 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.190.108.22) The olcTimeLimit is not declared as Single Value : { "timelimit", "limit", 2, 0, 0, ARG_MAY_DB|ARG_MAGIC, &config_timelimit, "( OLcfgGlAt:67 NAME 'olcTimeLimit' " "SYNTAX OMsDirectoryString ) when we have olcSizeLimit declared as : { "sizelimit", "limit", 2, 0, 0, ARG_MAY_DB|ARG_MAGIC, &config_sizelimit, "( OLcfgGlAt:60 NAME 'olcSizeLimit' " "SYNTAX OMsDirectoryString SINGLE-VALUE ) There is a missing "SINGLE-VALUE" in file bconfig.c, on line 660.

1 0

ITS#8088 slapd man pages
by hyc＠symas.com 21 May '15

21 May '15

Closing this as a dup of #7548. -- -- 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#7548 Split man pages
by hyc＠symas.com 21 May '15

21 May '15

This patch cannot be accepted because it uses Makefile directives ".if " etc. that are not portable across different versions of Make. -- -- 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#8151) test062 sporadically seg faults
by hyc＠symas.com 21 May '15

21 May '15

michael(a)stroeder.com wrote: > Full_Name: > Version: git master 66ab6bafa8e290d842f68e683e3cd3ee63f513be > OS: openSUSE Linux x86_64 > URL: > Submission from: (NULL) (84.178.24.246) > > > test062 in git master sometimes seg faults with hdb and mdb. config delete support is still WIP. Tests in master are known to fail from time to time, do not file ITSs for these. -- -- 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#8152) mt_flags & MDB_TXN_ERROR is never reset when MDB_MAP_FULL occurs
by dw＠botanicus.net 21 May '15

21 May '15

--047d7bd6b9e4604df2051695f2ab Content-Type: text/plain; charset=UTF-8 Confirmed fixed in mdb.RE/0.9 @ github.com --047d7bd6b9e4604df2051695f2ab Content-Type: text/html; charset=UTF-8 <div dir="ltr">Confirmed fixed in mdb.RE/0.9 @ <a href="http://github.com">github.com</a><br></div> --047d7bd6b9e4604df2051695f2ab--

1 0

(ITS#8152) mt_flags & MDB_TXN_ERROR is never reset when MDB_MAP_FULL occurs
by dw＠botanicus.net 21 May '15

21 May '15

Full_Name: David Wilson Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.157.85.186) Since the me_txn0 heap allocation is cached across write transactions, when any write transaction fails with MDB_MAP_FULL and causes MDB_TXN_ERROR to be set in me_txn0->mt_flags, it becomes impossible to try another write transaction without reopening the environment, since that bit is never unset anywhere. A simple way to trigger this is attempting to put any value larger than the map size, at which point the environment will always return MDB_BAD_TXN for subsequent write transactions. While MAP_FULL and insufficient validation of input by the application are pretty show-stopper issues already, I doubt wedging the environment state is the most robust response LMDB could muster in this case. It seems MDB_TXN_ERROR wants to be unset in either mdb_txn_abort() or mdb_txn_reset0(). Taking into account the possibility of a parent write transaction also existing, I'm not sure where and how exactly the bit should be unset.

1 0

(ITS#8151) test062 sporadically seg faults
by michael＠stroeder.com 21 May '15

21 May '15

Full_Name: Version: git master 66ab6bafa8e290d842f68e683e3cd3ee63f513be OS: openSUSE Linux x86_64 URL: Submission from: (NULL) (84.178.24.246) test062 in git master sometimes seg faults with hdb and mdb. Core was generated by `/usr/src/michael/openldap-git/master/openldap/servers/slapd/.libs/lt-slapd -s0'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fc961c38c3d in syncprov_free_syncop (so=0x7fc954103950, unlink=1) at syncprov.c:811 811 for ( sop = &so->s_si->si_ops; *sop; sop = &(*sop)->s_next ) { Missing separate debuginfos, use: zypper install cyrus-sasl-crammd5-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-digestmd5-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-gs2-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-gssapi-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-ntlm-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-otp-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-plain-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-scram-debuginfo-2.1.26-11.1.x86_64 glibc-debuginfo-2.21-5.2.x86_64 krb5-debuginfo-1.13.1-1.2.x86_64 libcom_err2-debuginfo-1.42.12-2.2.x86_64 libdb-4_8-debuginfo-4.8.30-30.2.x86_64 libkeyutils1-debuginfo-1.5.9-47.2.x86_64 libltdl7-debuginfo-2.4.6-2.1.x86_64 libopenssl1_0_0-debuginfo-1.0.1k-3.1.x86_64 libpcre1-debuginfo-8.37-1.1.x86_64 libsasl2-3-debuginfo-2.1.26-11.1.x86_64 libselinux1-debuginfo-2.3-4.3.x86_64 libz1-debuginfo-1.2.8-7.2.x86_64 unixODBC-debuginfo-2.3.2-5.2.x86_64 (gdb) bt full #0 0x00007fc961c38c3d in syncprov_free_syncop (so=0x7fc954103950, unlink=1) at syncprov.c:811 sop = 0x6a626f006769666e sr = 0x62644960 srnext = 0x7fc954003270 ga = 0x7fc954103330 gnext = 0x100000 #1 0x00007fc961c396a0 in syncprov_qtask (ctx=0x7fc962644bf0, arg=0x7fc954103950) at syncprov.c:1005 so = 0x7fc954103950 opbuf = {ob_op = {o_hdr = 0x7fc962644960, o_tag = 99, o_time = 1432200195, o_tin % = 0, o_bd = 0x7fc962644660, o_req_dn = {bv_len = 9, bv_val = 0x7fc95410a9e2 "cn=config"}, o_req_ndn = {bv_len = 9, bv_val = 0x7fc95410a9ec "cn=config"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 1410349536, rb_mech = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}}, oq_compar= D {rs_ava = 0x2}, oq_modify = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 140502675503584, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fc95410a9f6, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x7fc9541039e0, rs_filterstr = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = { rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x7fc9541039e0 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', 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 20 times>, "\001\000\000\000\000\000\000\000\000\000\000", o_controls = 0x7fc962644aa8, o_authz = {sai_method = 128, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x7fc95410a9d8 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x7fc95410a9d8 "cn=config"}, 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 = 1, oh_connid = 1003, oh_conn = 0x1bb5730, oh_msgid = 2, oh_protocol = 3, oh_tid = 140502915897088, oh_threadctx = 0x7fc962644bf0, oh_tmpmemctx = 0x7fc954002350, oh_tmpmfuncs = 0x765980 <slap_sl_mfuncs>, oh_counters = 0x7fc954002240, oh_log_prefix = "conn=1003 op=1", '\000' <repeats 241 times>}, ob_controls = { 0x0 <repeats 32 times>}} op = 0x7fc9626447f0 be = {bd_info = 0x760de0 <slap_binfo>, bd_self = 0x1b72470, be_ctrls = '\000' <repeats 15 times>, "\001", '\000' <repeats 16 times>, "\001", be_flags = 131328, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x1b72670, be_nsuffix = 0x1b726c0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x1b72610 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x1b72630 "cn=config"}, be_rootpw = {bv_len = 8, bv_val = 0x1b72930 "D/nFIIJ7"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1c6e000, be_dfltaccess = ACL_NONE, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x1b58ff0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x766680 <cfBackInfo>, be_next = {stqe_next = 0x0}} rc = 0 #2 0x00007fc967987ec3 in ldap_int_thread_pool_wrapper (xpool=0x1b4e640) at tpool.c:958 pq = 0x1b4e640 pool = 0x1b4e550 task = 0x7fc954112e30 work_list = 0x1b4e6b0 ctx = {ltu_pq = 0x1b4e640, ltu_id = 140502915897088, ltu_key = {{ltk_key = 0x43f901 <conn_counter_init>, ltk_data = 0x7fc954002240, ltk_free = 0x43f753 <conn_counter_destroy>}, {ltk_key = 0x4b3ff5 <slap_sl_mem_init>, ltk_data = 0x7fc954002350, ltk_free = 0x4b3e1a <slap_sl_mem_destroy>}, {ltk_key = 0x45a859 <slap_op_free>, ltk_data = 0x7fc954002eb0, ltk_free = 0x45a7ac <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x7fc95410bff0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 28 times>}} kctx = 0x0 i = 32 keyslot = 837 hash = 1269620549 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fc965e5f484 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fc965b9da4d in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

Re: (ITS#8142) back-ldap transparent reconnecting is not so transparent
by hyc＠symas.com 21 May '15

21 May '15

hyc(a)symas.com wrote: > ebackes(a)symas.com wrote: >> Full_Name: Emily Backes >> Version: 2.4 >> OS: >> URL: >> Submission from: (NULL) (50.113.67.84) >> >> >> Currently, back-ldap stores credentials in the outbound connection >> structure. When that disappears, e.g. from idle-timeout, conn-ttl, >> network lossage, AD trouble, etc., the connection becomes unbound and >> AD returns err=1 (Operations error), which isn't enougfofor back-ldap >> to treat it as LDAP_UNAVAILABLE. >> >> Howard reports this is working-as-designed, even if the design is bad. >> Several ITS filings are still open about this problem; 5110, 6571, and >> 7464 are all related. #5110 looks unrelated actually. >> At a minimum, we should drop the client connection if we can't keep >> the session stable. > > This is not as simple as it sounds. In particular, back-ldap may be part of a > larger glued tree of backends. A failure to search in the back-ldap context > should not prevent the rest of the glued tree from being searched, and it > should not drop the client connection. > Fixed now in master. -- -- 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#8129) ignored config variable autocommit for back-sql
by hyc＠symas.com 21 May '15

21 May '15

daniel.chobe(a)dimensiondata.com wrote: > Full_Name: Daniel Chobe > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.111.74.244) > > > This bug is related to ITS#6613. In this bug a new configvariable named > autocommit was introduced. But the flagmask in config.c was wrong, so setting > this config variable has no influence to the behavior of the slapd. > > The Patch is very simply replace SQL_AUTOCOMMIT with BSQL_AUTOCOMMIT. Thanks for the report, fixed in git master. > > > diff -rupN 1/servers/slapd/back-sql/config.c 2/servers/slapd/back-sql/config.c > --- 1/servers/slapd/back-sql/config.c 2013-11-15 04:31:27.000000000 +0100 > +++ 2/servers/slapd/back-sql/config.c 2015-05-05 14:51:43.161310554 +0200 > @@ -210,7 +210,7 @@ static ConfigTable sqlcfg[] = { > "DESC 'Quoting char of the aliasing keyword' " > "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, > { "autocommit", "yes|no", 2, 2, 0, > - ARG_ON_OFF|ARG_MAGIC|SQL_TOCOCOMMIT, (void *)sql_cf_gen, > + ARG_ON_OFF|ARG_MAGIC|BSQL_AUTOCOMMIT, (void *)sql_cf_gen, > "( OLcfgDbAt:6.45 NAME 'olcSqlAutocommit' " > "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL }, > { NULL, NULL, 0, 0, 0, ARG_IGNORED, > > -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by hyc＠symas.com 21 May '15

21 May '15

Ryan Tandy wrote: > Does the following patch make sense? > > ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_ind… Looks fine to me. Pushing to master. -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by ryan＠nardis.ca 21 May '15

21 May '15

Does the following patch make sense? ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_ind…

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by andrew.findlay＠skills-1st.co.uk 20 May '15

20 May '15

On Wed, May 20, 2015 at 11:57:13AM -0700, Ryan Tandy wrote: > It does if you use an initial LDIF like the one from ITS#7016: > > $ mkdir cf.d > $ slapadd -Fcf.d -n0 > dn: cn=config > objectClass: olcGlobal > > dn: olcDatabase=frontend,cn=config > objectClass: olcDatabaseConfig > objectClass: olcFrontendConfig Good point: that suggests an incomplete fix for ITS#7106 rather than a problem in slapcat. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by ryan＠nardis.ca 20 May '15

20 May '15

On Wed, May 20, 2015 at 06:40:36PM +0000, hyc(a)symas.com wrote: >Unable to reproduce. It does if you use an initial LDIF like the one from ITS#7016: $ mkdir cf.d $ slapadd -Fcf.d -n0 dn: cn=config objectClass: olcGlobal dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig ^D $ slapcat -Fcf.d -n0 -l cf.ldif $ rm -r cf.d/* $ slapadd -Fcf.d -n0 -l cf.ldif slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=591): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry _#################### 100.00% eta none elapsed none fast! Closing DB... (I ran into this myself a while back but forgot to report it.)

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by hyc＠symas.com 20 May '15

20 May '15

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.40 > OS: CentOS 7 > URL: > Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) > > > When using cn=config it is sometimes necessary to extract the whole config to an > LDIF file, edit it and re-load into an empty directory. Therefore I would expect > the null-edit case to work for any system: > > slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif > rm -rf .../config > mkdir .../config > slapadd -F .../config -n 0 -l extracted.ldif > > What I actually get is an error message: > slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of > single-valued naming attribute 'olcDatabase' conflicts with value present in > entry Unable to reproduce. violino:~/OD/o24/tests> mkdir testrun/slapd.d violino:~/OD/o24/tests> ../servers/slapd/slapd -Tc -f testrun/slapd.1.conf -F testrun/slapd.d -n0 > cf1.ldif violino:~/OD/o24/tests> ls testrun/slapd.d cn=config cn=config.ldif violino:~/OD/o24/tests> rm -rf testrun/slapd.d/* violino:~/OD/o24/tests> ../servers/slapd/slapd -Ta -F testrun/slapd.d -n0 -l cf1.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by andrew.findlay＠skills-1st.co.uk 20 May '15

20 May '15

Full_Name: Andrew Findlay Version: 2.4.40 OS: CentOS 7 URL: Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) When using cn=config it is sometimes necessary to extract the whole config to an LDIF file, edit it and re-load into an empty directory. Therefore I would expect the null-edit case to work for any system: slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif rm -rf .../config mkdir .../config slapadd -F .../config -n 0 -l extracted.ldif What I actually get is an error message: slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry The problem is the frontend database entry: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcAccess: {0}to * by * read structuralObjectClass: olcDatabaseConfig entryUUID: 35adc8f6-9363-1034-85ee-896d5ca46112 creatorsName: cn=config createTimestamp: 20150520174137Z entryCSN: 20150520174137.558106Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20150520174137Z %SpSpecifically, the '{-1}' in the dn should either be omitted or should also be present on the olcDatabase attribute in the entry itself. The problem is in the behaviour of slapcat, but may be related to the fix for ITS#7016 Andrew

1 0

(ITS#8149) nssov loginStatus doesn't play well with replication
by ryan＠openldap.org 20 May '15

20 May '15

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (142.31.146.2) Submitted by: ryan jindraj in #openldap reported that in a master/slave setup, nssov on the slave updates loginStatus in the local db, not on the master. nssov should update loginStatus in a way that can be forwarded properly (possibly controlled by a conf option, similar to ppolicy_forward_updates). The loginStatus updates also don't behave intuitively under MMR. The mod is done without opattrs, so is not immediately replicated, but it does get replicated if the entry's CSN gets updated for any other reason. loginStatus is not an operational attribute, nor is user-modification of it prohibited. (Maybe it should be?)

1 0

Re: (ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
by alexoz66＠gmail.com 20 May '15

20 May '15

On 05/19/2015 11:55 PM, Howard Chu wrote: > alexoz66(a)gmail.com wrote: >> Full_Name: John Alex. >> Version: 2.4.40 >> OS: FreeBSD 9.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (176.58.252.240) >> >> >> I have a consumer configured with slapo-memberof and exattrs=memberof in order >> to keep track of group memberships locally as suggested in the manpages. This >> works ok when adding/deleting users to groups, but when a user entry containing >> "memberOf" values is modified, those values are deleted in the consumer. >> According to ITS#7400, exattrs=memberOf is necessary to avoid getting this >> attribute from the provider. > > I see nothing in ITS#7400 that even mentions exattrs. In fact there's nothing conclusive > in ITS#7400 at all, it only says the issue should be taken up on the -devel mailing list > and needs new design work. By reading ITS#7400, I got the impression that the provider (wrongly) sends "memberOf" when the consumer requests "+", so I figured I had to either block this attribute by acl at the provider or by using exattrs on the consumer. Has this been fixed? >> However, it was suggested to me to remove >> "memberOf" from exattrs, which I did and now everything seems to work fine. >> >> In any case, even if exattrs=memberof is not needed anymore, it should not have >> any effect to the local slapo-memberof operations. > > Sorry, that doesn't follow. Adding settings will invariably change some server behavior. > Adding a setting that you didn't need generally turns a working config into a broken config. Redundant yes, but broken? Although I don't have the slightest clue about the inner workings of syncrepl and slapo-memberof, I don't see why one should affect the other. >> See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html > >

1 0

Re: (ITS#8133) segfault at startup with memberof+dds
by ryan＠nardis.ca 20 May '15

20 May '15

The patch below fixes the crash, however I'd appreciate a review before committing in case I misunderstood why that code might be needed. The first periodic expiry runs immediately after startup completes, and AFAICT does everything this one would have; so the window for returning stale data should be short. Thanks. ftp://ftp.openldap.org/incoming/20150519_rtandy_ITS-8133-avoid-mods-during-…

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs