January 2019 - openldap-bugs

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

by h.b.furuseth＠usit.uio.no

On 1/19/19 8:04 PM, Howard Chu wrote: > The *server* is not hung. Only modifications to the cn=config DB are blocked. Yes it is. See the ldapwhoami in my example.

4 years, 8 months

1
0
0 / 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

by hyc＠symas.com

Hallvard Breien Furuseth wrote: > Testing again 'subordinate' looks irrelevant. I wonder what I > did in my original and bigger testcase to make it seem relevant. >=20 > On 1/19/19 6:30 PM, Howard Chu wrote: >> This is not really surprising. >=20 > I don't know these interactions well enough to be unsurprised. >=20 > It's not hard to guess that modify(olcDbIndex) might be heavy and > had better be tested.=C2=A0 A simple test says it returns quickly.=C2=A0= I > don't know why the ongoing indexing keeps cn=3Dconfig locked after > the operation succeeded, instead of keeping something in the > indexed DB locked.=C2=A0 I wouldn't expect others to guess that either. modifications to cn=3Dconfig require no other threads to be active. Once = the background indexer starts running, its activity will of course block further cn=3Dconfig mod= ifications until it completes. >> Are you suggesting the indexing task should stop if another config mod= comes in? >=20 > I'm suggesting to fail the 2nd operation if that's what it takes. > Or only hang if the user passes some LDAP control. >=20 > I'm suggesting that config pauses should be brief.=C2=A0 Server hangs > are bad.=C2=A0 Even a crash can be better when other load-balanced > servers can take over.=C2=A0 Not that I'm suggesting that "fix":-) The *server* is not hung. Only modifications to the cn=3Dconfig DB are bl= ocked. You might make a case that background indexing on a backend shouldn't blo= ck writes to unrelated parts of the cn=3Dconfig tree. The current pause desi= gn wouldn't easily support that, but it might be worth working on. Also it's not clea= r which parts of the tree are actually unrelated. E.g., changing schema elements = could affect all backends at once. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 8 months

1
0
0 / 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

by h.b.furuseth＠usit.uio.no

Testing again 'subordinate' looks irrelevant. I wonder what I did in my original and bigger testcase to make it seem relevant. On 1/19/19 6:30 PM, Howard Chu wrote: > This is not really surprising. I don't know these interactions well enough to be unsurprised. It's not hard to guess that modify(olcDbIndex) might be heavy and had better be tested. A simple test says it returns quickly. I don't know why the ongoing indexing keeps cn=config locked after the operation succeeded, instead of keeping something in the indexed DB locked. I wouldn't expect others to guess that either. > Are you suggesting the indexing task should stop if another config mod comes in? I'm suggesting to fail the 2nd operation if that's what it takes. Or only hang if the user passes some LDAP control. I'm suggesting that config pauses should be brief. Server hangs are bad. Even a crash can be better when other load-balanced servers can take over. Not that I'm suggesting that "fix":-)

4 years, 8 months

1
0
0 / 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

by hyc＠symas.com

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard Breien Furuseth > Version: 2.4.47, master > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz > Submission from: (NULL) (193.90.50.50) > > > Use cn=config to add an index to a subordinate database, > then make a 2nd cn=config change. 2nd change waits while > (I assume) indexing, and blocks other slapd operations. > So ldapwhoami during 2nd change takes 5 seconds. > > To reproduce: ./bug.sh > To debug, attach gdb in another terminal during 2nd MOD. > gdb -q ../servers/slapd/slapd `cat slapd.pid` > > trace.txt shows the 2nd config_back_modify() waiting > in slap_pause_server(). This is not really surprising. Are you suggesting the indexing task should stop if another config mod comes in? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 8 months

1
0
0 / 0

(ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

by h.b.furuseth＠usit.uio.no

Full_Name: Hallvard Breien Furuseth Version: 2.4.47, master OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190119.tgz Submission from: (NULL) (193.90.50.50) Use cn=config to add an index to a subordinate database, then make a 2nd cn=config change. 2nd change waits while (I assume) indexing, and blocks other slapd operations. So ldapwhoami during 2nd change takes 5 seconds. To reproduce: ./bug.sh To debug, attach gdb in another terminal during 2nd MOD. gdb -q ../servers/slapd/slapd `cat slapd.pid` trace.txt shows the 2nd config_back_modify() waiting in slap_pause_server().

4 years, 8 months

1
0
0 / 0

(ITS#8957) Handling of TLS in async mode

by vsmith＠interlinknetworks.com

Full_Name: Vernon Smith Version: 2.4.47 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:8d9a:95ec:46f9:30fd) I looked at the release notes and there have been a few issues with Async mode with TSL in 2.4. I had been using 2.3.20 with my own patches to make Async mode with TLS work with my aplication. I need to upgrade to 2.4 but I have tried many version of it and none have worked. The basic issue is that the TLS code is never called so LDAPS connections fail. My symptoms are very similar to the bug report that caused a fix in 2.4.26 but 2.4.26 is not working for me. I see the same issue with 2.4.47. If I don't use LDAP_OPT_CONNECT_ASYNC then the connection works and I get this trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: 0 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_int_poll: fd: 10 tm: 3 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:unknown state TLS certificate verification: depth: 1, err: 0, subject: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=Michigan/L=Ann Arbor/O=Interlink Networks Services, LLC./OU=Quality Assurance/CN=test.interlinknetworks.com/emailAddress=QAtest@interlinknetw..., issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest(a)interlinknetworks.com TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state ldap_open_defconn: successful ldap_send_server_request But with LDAP_OPT_CONNECT_ASYNC enabled I never see the TLS code called and the connection fails. The trace is: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: -1 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_open_defconn: successful ldap_send_server_request ... ldap_result ld 0x9bd6f70 msgid 1 wait4msg ld 0x9bd6f70 msgid 1 (timeout 0 usec) wait4msg continue ld 0x9bd6f70 msgid 1 all 1 ** ld 0x9bd6f70 Connections: * host: test.interlinknetworks.com port: 636 (default) refcnt: 2 status: Connected last used: Mon Jan 14 15:33:57 2019 ** ld 0x9bd6f70 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9bd6f70 request count 1 (abandoned 0) ** ld 0x9bd6f70 Response Queue: Empty ld 0x9bd6f70 response count 0 ldap_chkResponseList ld 0x9bd6f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x9bd6f70 NULL ldap_int_select read1msg: ld 0x9bd6f70 msgid 1 all 1 ber_get_next failed. ldap_err2string ... Can't contact LDAP server Thanks, Vern

4 years, 8 months

1
0
0 / 0

(ITS#8956) Update slapd-sql(5) man page to remove BDB reference

by quanah＠openldap.org

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The slapd-sql(5) man page has the following blurb: It is NOT designed as a general-purpose backend that uses RDBMS instead of BerkeleyDB (as the standard BDB backend does), though it can be used as such with several limitations. Given the deprecation of BDB based backends, this should be updated to reference LMDB and back-mdb.

4 years, 8 months

1
0
0 / 0

Re: (ITS#8951) Replication stalls

by quanah＠symas.com

--On Wednesday, January 02, 2019 7:44 PM +0000 whm(a)dropbox.com wrote: > Bill Hi Bill, I believe this issue was resolved by setting a keepalive in the syncrepl stanza. Can you confirm? Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 8 months

1
0
0 / 0

Re: (ITS#8954) LMDB double-commit double-free heap crash

by hyc＠symas.com

robin.rowe(a)venturehollywood.com wrote: > Full_Name: Robin Rowe > Version: --branch OPENLDAP_REL_ENG_2_4 > OS: Windows 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (23.242.20.216) > > > LMDB becomes unstable if we double-commit the same transaction. Caused by > freeing me_txn0 again after 2nd commit had previously free it. This is not an LMDB bug, this is a stupid user error. http://www.lmdb.tech/doc/group__mdb.html#ga846fbd6f46105617ac9f4d76476f6597 Closing this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 years, 9 months

1
0
0 / 0

(ITS#8954) LMDB double-commit double-free heap crash

by robin.rowe＠venturehollywood.com

Full_Name: Robin Rowe Version: --branch OPENLDAP_REL_ENG_2_4 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (23.242.20.216) LMDB becomes unstable if we double-commit the same transaction. Caused by freeing me_txn0 again after 2nd commit had previously free it. To experience this bug, add a second commit to sample-mdb.c about line 43, deliberately cause a double-commit: sprintf(sval, "%03x %d foo bar", 32, 3141592); rc = mdb_put(txn, dbi, &key, &data, 0); rc = mdb_txn_commit(txn); #ifndef HIDE_DOUBLE_FREE_BUG rc = mdb_txn_commit(txn);// 2nd commit destabilizes LMDB env #endif if (rc) { What's different after a double-commit... mdb.c:3470 rc = MDB_BAD_TXN; // Detected double-commit mdb.c:3471 goto fail; // Jumps away into unsafe code path... ...Much later, at end of program: mdb_env_close(env); // Heap crash here, double-free! return 0; } Double-commit eventually crashes us with double-free in mdb_env_close here: mdb.c:5076 free(env->me_dirty_list); mdb.c:5076 free(env->me_txn0); // 2nd commit already freed // txn pointed to by me_txn0! Granted it is a user mistake to commit the same transaction twice. However, because the crash won't happen until much later, when env is freed, any LMDB users who make this mistake will be quite perplexed. Will anyone fix this? Robin

4 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2019