- openldap-bugs - openldap.org

Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 31 Jan '19

31 Jan '19

This is a multi-part message in MIME format. --b1_d8637dbb120a529f4f26d43d4b089cee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SWYgSSBhZGQgdGhlICItdiIgb3B0aW9uIHRvIGNsYW5nIGluIC4vbGlicmFyaWVzL01ha2VmaWxl LCB0aGUgcmVzdWx0aW5nIGxvZyBzaG93cyB0aGF0IHRoZSBsaWJyYXJ5IHdhcyBsaW5rZWQgdHdp Y2UsIGNhdXNpbmcgc3ltYm9sIGR1cGxpY2F0aW9uLgoKVGhpcyBob2xkcyBvbiBtYWNvcyAxMC4x MyB3aXRoIEFwcGxlIHRvb2xraXQgMTAuMTQgYW5kIHRoZSBvcmlnaW5hbCBsbHZtIDcuMC4wIHdp dGggdGhlIGdpdmVuIHNldHRpbmdzLgoKT24gTW9uLCBKYW4gMjgsIDIwMTkgYXQgMTc6MTEsIFF1 YW5haCBHaWJzb24tTW91bnQgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOgoKPiAtLU9uIE1vbmRh eSwgSmFudWFyeSAyOCwgMjAxOSAzOjM1IFBNICswMDAwIFJ1cGVydCBHYWxsYWdoZXIKPiA8cnVn YUBwcm90b25tYWlsLmNvbT4gd3JvdGU6Cj4KPj4gQXMgeW91IGNhbiBzZWUsIEkgYW0gdXNpbmcg dGhlIGRlZmF1bHQgQXBwbGUgbGlua2VyLCBhbmQgaGFyZGVuZWQKPj4gc2V0dGluZ3MgZm9yIHRo ZSBjb21waWxlci4gVHJ5IHVzaW5nIHRob3NlIHNldHRpbmdzIHlvdXJzZWxmLCBhbmQgc2VlCj4+ IHdoYXQgY29tZXMgb3V0Lgo+Cj4gSSB0ZXN0ZWQgb24gRnJlZUJTRDEyIChzaW5jZSBpdCB1c2Vz IGNsYW5nIHJhdGhlciB0aGFuIGdjYykgd2l0aCB0aGUKPiBmb2xsb3dpbmcgZmxhZ3MgYW5kIHRo ZSBidWlsZCBjb21wbGV0ZWQgdy9vIGlzc3VlOgo+Cj4gQ0ZMQUdTPSAtZyAtZnN0YWNrLXByb3Rl Y3Rvci1hbGwgLWZuby1vbWl0LWZyYW1lLXBvaW50ZXIgLWZQSUMgLWZQSUUgLU8yCj4gLVdmb3Jt YXQgLVdmb3JtYXQtc2VjdXJpdHkgLVdlcnJvcj1mb3JtYXQtc2VjdXJpdHkKPiBMREZMQUdTPSAt V2wsLXoscmVscm8sLXosbm93IC1waWUKPiBDUFBGTEFHUz0gLURfRk9SVElGWV9TT1VSQ0U9MiAt RF9GT1JUSUZZX1NPVVJDRT0yIC1EX0ZPUlRJRllfU09VUkNFPTIKPgo+IEluIGFueSBjYXNlLCBJ IHRoaW5rIHdlJ3ZlIHdlbGwgZXN0YWJsaXNoZWQgdGhlIHByb2JsZW0geW91J3JlIGhpdHRpbmcg aGFzCj4gemVybyB0byBkbyB3aXRoIE9wZW5MREFQIGluIGFuZCBvZiBpdHNlbGYuIFlvdSdsbCBu ZWVkIHRvIHRha2UgdGhpcyB1cAo+IGVsc2V3aGVyZS4KPgo+IC0tUXVhbmFoCj4KPiAtLQo+Cj4g UXVhbmFoIEdpYnNvbi1Nb3VudAo+IFByb2R1Y3QgQXJjaGl0ZWN0Cj4gU3ltYXMgQ29ycG9yYXRp b24KPiBQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBv d2VyZWQgYnkgT3BlbkxEQVA6Cj4gPGh0dHA6Ly93d3cuc3ltYXMuY29tPg== --b1_d8637dbb120a529f4f26d43d4b089cee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj5JZiBJIGFkZCB0aGUgIi12IiBvcHRpb24gdG8gY2xhbmcgaW4gLi9saWJyYXJpZXMv TWFrZWZpbGUsIHRoZSByZXN1bHRpbmcgbG9nIHNob3dzIHRoYXQgdGhlIGxpYnJhcnkgd2FzIGxp bmtlZCB0d2ljZSwgY2F1c2luZyBzeW1ib2wgZHVwbGljYXRpb24uJm5ic3A7PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5UaGlzIGhvbGRzIG9uIG1hY29zIDEwLjEzIHdpdGggQXBwbGUgdG9vbGtp dCAxMC4xNCBhbmQgdGhlIG9yaWdpbmFsIGxsdm0gNy4wLjAgd2l0aCB0aGUgZ2l2ZW4gc2V0dGlu Z3MuJm5ic3A7PC9kaXY+IDxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pk9uIE1vbiwgSmFu IDI4LCAyMDE5IGF0IDE3OjExLCBRdWFuYWggR2lic29uLU1vdW50ICZsdDs8YSBocmVmPSJtYWls dG86cXVhbmFoQHN5bWFzLmNvbSIgY2xhc3M9IiI+cXVhbmFoQHN5bWFzLmNvbTwvYT4mZ3Q7IHdy b3RlOjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIiB0eXBlPSJjaXRlIj4gIC0t T24gTW9uZGF5LCBKYW51YXJ5IDI4LCAyMDE5IDM6MzUgUE0gKzAwMDAgUnVwZXJ0IEdhbGxhZ2hl cjxicj4mbHQ7cnVnYUBwcm90b25tYWlsLmNvbSZndDsgd3JvdGU6PGJyPjxicj4mZ3Q7IEFzIHlv dSBjYW4gc2VlLCBJIGFtIHVzaW5nIHRoZSBkZWZhdWx0IEFwcGxlIGxpbmtlciwgYW5kIGhhcmRl bmVkPGJyPiZndDsgc2V0dGluZ3MgZm9yIHRoZSBjb21waWxlci4gVHJ5IHVzaW5nIHRob3NlIHNl dHRpbmdzIHlvdXJzZWxmLCBhbmQgc2VlPGJyPiZndDsgd2hhdCBjb21lcyBvdXQuPGJyPjxicj5J IHRlc3RlZCBvbiBGcmVlQlNEMTIgKHNpbmNlIGl0IHVzZXMgY2xhbmcgcmF0aGVyIHRoYW4gZ2Nj KSB3aXRoIHRoZTxicj5mb2xsb3dpbmcgZmxhZ3MgYW5kIHRoZSBidWlsZCBjb21wbGV0ZWQgdy9v IGlzc3VlOjxicj48YnI+Q0ZMQUdTPSAtZyAtZnN0YWNrLXByb3RlY3Rvci1hbGwgLWZuby1vbWl0 LWZyYW1lLXBvaW50ZXIgLWZQSUMgLWZQSUUgLU8yPGJyPi1XZm9ybWF0IC1XZm9ybWF0LXNlY3Vy aXR5IC1XZXJyb3I9Zm9ybWF0LXNlY3VyaXR5PGJyPkxERkxBR1M9IC1XbCwteixyZWxybywteixu b3cgLXBpZTxicj5DUFBGTEFHUz0gLURfRk9SVElGWV9TT1VSQ0U9MiAtRF9GT1JUSUZZX1NPVVJD RT0yIC1EX0ZPUlRJRllfU09VUkNFPTI8YnI+PGJyPjxicj5JbiBhbnkgY2FzZSwgSSB0aGluayB3 ZSd2ZSB3ZWxsIGVzdGFibGlzaGVkIHRoZSBwcm9ibGVtIHlvdSdyZSBoaXR0aW5nIGhhczxicj56 ZXJvIHRvIGRvIHdpdGggT3BlbkxEQVAgaW4gYW5kIG9mIGl0c2VsZi4gIFlvdSdsbCBuZWVkIHRv IHRha2UgdGhpcyB1cDxicj5lbHNld2hlcmUuPGJyPjxicj4tLVF1YW5haDxicj48YnI+LS08YnI+ PGJyPlF1YW5haCBHaWJzb24tTW91bnQ8YnI+UHJvZHVjdCBBcmNoaXRlY3Q8YnI+U3ltYXMgQ29y cG9yYXRpb248YnI+UGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0 aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQOjxicj4mbHQ7aHR0cDovL3d3dy5zeW1hcy5jb20mZ3Q7 PGJyPjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ --b1_d8637dbb120a529f4f26d43d4b089cee--

1 0

(ITS#8969) LMDB page_split tweak
by hyc＠openldap.org 31 Jan '19

31 Jan '19

Full_Name: Howard Chu Version: LMDB 0.9 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.38.213) Submitted by: hyc In mdb_page_split, we should use the fine-grained search for split point a little more often, to avoid MDB_PAGE_FULL errors.

1 0

(ITS#8968) Async connect mode does not work on Solaris
by vsmith＠interlinknetworks.com 31 Jan '19

31 Jan '19

Full_Name: Vernon Smith Version: 2.4.47 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:c0c9:ced:d06f:39a4) I have managed to upgrade to version 2.4.47 libldap libraries using the Linux OS and async connect mode works fine. But when I tried to upgrade to 2.4.47 using Solaris OS and use async connect mode, no connections could be established to the ldap server. The libldap code did not even send the ldap request to the ldap server. The ldap debug trace showed it just freeing the request and returned an unable to connect. I traced the issue to the routine ldap_int_flush_request which checks the sock_errno return code for EAGAIN but Solaris 10 returns ENOTCONN. This error code seems to mean the same thing as EAGAIN. I changed the code to test for either return code and the async connect works for both Linux and Solaris now. Here is may patch. diff --git a/libraries/libldap/request.c b/libraries/libldap/request.c index 9355d7e..321b79f 100644 --- a/libraries/libldap/request.c +++ b/libraries/libldap/request.c @@ -184,7 +184,7 @@ ldap_int_flush_request( LDAP_ASSERT_MUTEX_OWNER( &ld->ld_conn_mutex ); if ( ber_flush2( lc->lconn_sb, lr->lr_ber, LBER_FLUSH_FREE_NEVER ) != 0 ) { - if ( sock_errno() == EAGAIN ) { + if (( sock_errno() == EAGAIN ) || ( sock_errno() == ENOTCONN )) { /* need to continue write later */ lr->lr_status = LDAP_REQST_WRITING; ldap_mark_select_write( ld, lc->lconn_sb ); Thanks, Vern

1 0

(ITS#8967) back-mdb "unchecked" limit broken vs. search scope
by h.b.furuseth＠usit.uio.no 30 Jan '19

30 Jan '19

Full_Name: Hallvard Breien Furuseth Version: 2.4.47 OS: Linux URL: Submission from: (NULL) (2001:700:100:202::105) The size.unchecked limit does not seem to consider search scope other than 'base' in back-mdb. $ ldapsearch -LLL -xh localhost:3890 -b l=there '(l=over)' 1.1 dn: l=over,l=here,l=there $ ldapsearch -LLL -xh localhost:3890 -b l=over,l=here,l=there 1.1 Administrative limit exceeded (11) $ ldapsearch -LLL -xh localhost:3890 -b l=over,l=here,l=there -s base 1.1 dn: l=over,l=here,l=there $ cat test.ldif dn: l=there objectClass: locality dn: l=here,l=there objectClass: locality dn: l=over,l=here,l=there objectClass: locality dn: l=under,l=here,l=there objectClass: locality $ cat test.conf include schema/core.schema loglevel 0 sizelimit size.unchecked=3 database mdb directory test.db suffix l=there index l,objectClass eq

1 0

Re: (ITS#8957)
by quanah＠symas.com 30 Jan '19

30 Jan '19

--On Wednesday, January 30, 2019 1:44 AM -0500 Vernon Smith <vsmith(a)interlinknetworks.com> wrote: > I Tried to upload it to the openldap ftp server but was not successful so > I am trying the patch again here. > > diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c > index bb81d86..20b3dfc 100644 > --- a/libraries/libldap/open.c > +++ b/libraries/libldap/open.c > @@ -489,7 +489,7 @@ ldap_int_open_connection( > #endif > > #ifdef HAVE_TLS > - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > { > ++conn->lconn_refcnt; /* avoid premature free */ That worked, thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8957)
by vsmith＠interlinknetworks.com 30 Jan '19

30 Jan '19

I Tried to upload it to the openldap ftp server but was not successful so I am trying the patch again here. diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c index bb81d86..20b3dfc 100644 --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -489,7 +489,7 @@ ldap_int_open_connection( #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vern On Tue, January 29, 2019 12:29 pm, Quanah Gibson-Mount wrote: > --On Tuesday, January 29, 2019 4:51 PM +0000 vsmith(a)interlinknetworks.com > wrote: > > > > >> --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 >> 10:57:06.000000000 -0500 >> +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 >> 18:24:48.000000000 -0500 >> @@ -440,7 +440,7 @@ >> ??#endif >> >> >> ??#ifdef HAVE_TLS >> -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == >> LDAP_OPT_X_TLS_HARD || +?????? if ((rc == 0 || rc == -2) && ( >> ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || ???????? ?????? strcmp( >> srv->lud_scheme, "ldaps" ) == 0 )) ???????? { >> ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature free */ >> > > This is not a valid patch. I don't know if it's your email client that is > destroying the patch? I suggest uploading it to the FTP site and responding with the > link to the file. > > Thanks, > Quanah > > > > -- > > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

1 0

(ITS#8966) changelog support for syncrepl
by hyc＠openldap.org 30 Jan '19

30 Jan '19

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.38.213) Submitted by: hyc The syncrepl consumer has had stubs for changelog support ever since delta-syncrepl was added using the accesslog overlay. Time to flesh out the rest of it.

1 0

Re: (ITS#8957)
by quanah＠symas.com 29 Jan '19

29 Jan '19

--On Tuesday, January 29, 2019 4:51 PM +0000 vsmith(a)interlinknetworks.com wrote: > --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 > 10:57:06.000000000 -0500 > +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 > 18:24:48.000000000 -0500 > @@ -440,7 +440,7 @@ > ??#endif > > ??#ifdef HAVE_TLS > -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || +?????? if ((rc == 0 || rc == -2) && ( > ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > ???????? ?????? strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > ???????? { > ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature free */ This is not a valid patch. I don't know if it's your email client that is destroying the patch? I suggest uploading it to the FTP site and responding with the link to the file. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8957)
by vsmith＠interlinknetworks.com 29 Jan '19

29 Jan '19

I reviewed some of the initial discussion about this same issue which lead to this fix in version 2.4.26, "Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at the code that Ian Puleston suggested should be fixed in ldap_int_open_connection. This routine does have the code to do what was need for TSL to work but was not called since it received an error code of -2 not 0. The -2 simply indicated that this was an asynchronous call. I changed the test to call the TSL setup if the return code was either 0 or -2. This fixes my issue. Here is my patch. --- openldap-2.4.47/libraries/libldap/open.c 2018-12-19 10:57:06.000000000 -0500 +++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26 18:24:48.000000000 -0500 @@ -440,7 +440,7 @@ #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vernon

1 0

(ITS#8965) ldap proxy segmentation fault
by praveen.adini＠fireeye.com 29 Jan '19

29 Jan '19

Full_Name: Praveen Adini Version: 2.4.47-r2 OS: Alpine Containers URL: Submission from: (NULL) (209.135.212.252) I'm trying to setup a openldap proxy wherein the proxy denies any search requests for uid=root. When i tried using the rwm overlay to stop the operation(#), i'm getting a segmentation fault although i see the unwilling to perform operation 53 message being printed. here is the snippet of the conf that i'm using. overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"

1 0

Re: (ITS#8957)
by quanah＠symas.com 29 Jan '19

29 Jan '19

Hi, Please read: <https://www.openldap.org/devel/contributing.html> and re-submit the patch accordingly. Please do not use HTML email. Thanks! --On Tuesday, January 29, 2019 6:05 AM +0000 vsmith(a)interlinknetworks.com wrote: > <html> > <head> > > <meta http-equiv="content-type" content="text/html; charset=UTF-8"> > </head> > <body text="#000000" bgcolor="#FFFFFF"> > I reviewed some of the initial discussion > about this same issue which lead to this fix in version 2.4.26, > "Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at > the code that Ian Puleston suggested should be fixed in > ldap_int_open_connection. This routine does have the code to do > what was need for TSL to work but was not called since it received > an error code of -2 not 0. The -2 simply indicated that this was > an asynchronous call. I changed the test to call the TSL setup if > the return code was either 0 or -2. This fixes my issue. Here is > my patch. > --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 > 10:57:06.000000000 -0500 > +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 > 18:24:48.000000000 -0500 > @@ -440,7 +440,7 @@ > ??#endif > ?? > ??#ifdef HAVE_TLS > -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || > +?????? if ((rc == 0 || rc == -2) && ( > ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > ???????? ?????? strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > ???????? { > ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature > free */ > Thanks, > Vern > > </body> > </html> > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8964) ldap proxy segmentation fault
by praveen.adini＠fireeye.com 29 Jan '19

29 Jan '19

Full_Name: Praveen Adini Version: 2.4.47-r2 OS: Alpine Containers URL: Submission from: (NULL) (209.135.212.252) I'm trying to setup a openldap proxy wherein the proxy denies any search requests for uid=root. When i tried using the rwm overlay to stop the operation(#), i'm getting a segmentation fault although i see the unwilling to perform operation 53 message being printed. here is the snippet of the conf that i'm using. overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"

1 0

(ITS#8963) Start TLS failed errors on back-ldap binds / short timeout, config option request
by janne.peltonen＠helsinki.fi 29 Jan '19

29 Jan '19

Full_Name: Janne Peltonen Version: 2.4.44 OS: Red Hat Enterprise Linux 7 URL: https://www.openldap.org/lists/openldap-technical/201901/msg00038.html Submission from: (NULL) (2001:708:110:1820:3664:a9ff:fe04:7363) Proxied BINDs on back-ldap sometimes create Start TLS failed errors on the connection from proxy to backend, and the client of the proxy receives the error 52. We had a look at the code, and it appears that in back-ldap/bind.c, the timeout argument of the function ldap_back_start_tls always ends up as zero, so the timeout tv.sec and tv.usec end up being set as 0 and 100000, respectively, by the macro LDAP_BACK_TV_SET defined in back-ldap/back-ldap.h. This means that the actual timeout waiting for starttls operation to complete will be 0.1 seconds, which is sometimes too little if there are latencies. We did a quick&dirty hack to just set tv.sec to 3 and tv.usec to 0, and were no longer able to get any Start TLS failed errors on the proxy bind. We did find that the back-ldap has an "extended" timeout defined in back-ldap/config.c - except that is commented out as "not implemented". Seems to us that if that were implemented, you could set the timeout in your ldap database section by something like "timeout extended=" and then you could have a longer timeout. Steps to reproduce: 1. Configure an openldap proxy-backend pair, the proxy using the "ldap" database and using ldap urls to connect to the backend (using ldaps urls might actually be a workaround). Configure the binds to be proxied to the backend, too. 2. Create a script that creates multiple - say, 200 - simultaneous connections to the proxy, using an ldaps url to connect to the proxy, and using the same DN to bind as. (We haven't tried to connect to the frontend using ldap+starttls, but I would suppose that would have a similar result, since the client establishes TLS anyway before trying to bind to the proxy.) 3. Observe some of the binds fail (we typically get 5-6 fails for 200 simultaneous connection), with the client of the proxy getting a "Server is unavailable: 52" type of error, and the proxy log containing lines such as "conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed" after the BIND from the client. Possible workaround: Configure the proxy to use ldaps urls to the backend. Suggested fix: Implement the "extended" timeout type in back-ldap/config.c timeout_table, so that people can set the StartTLS timeout to a larger value than the default 0.1 seconds. References: discussion thread on the OpenLDAP-Technical mailing list.

1 0

(ITS#8957)
by vsmith＠interlinknetworks.com 29 Jan '19

29 Jan '19

<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> I reviewed some of the initial discussion about this same issue which lead to this fix in version 2.4.26, "Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at the code that Ian Puleston suggested should be fixed in ldap_int_open_connection. This routine does have the code to do what was need for TSL to work but was not called since it received an error code of -2 not 0. The -2 simply indicated that this was an asynchronous call. I changed the test to call the TSL setup if the return code was either 0 or -2. This fixes my issue. Here is my patch. --- openldap-2.4.47/libraries/libldap/open.c 2018-12-19 10:57:06.000000000 -0500 +++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26 18:24:48.000000000 -0500 @@ -440,7 +440,7 @@ #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vern </body> </html>

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 28 Jan '19

28 Jan '19

--On Monday, January 28, 2019 3:35 PM +0000 Rupert Gallagher <ruga(a)protonmail.com> wrote: > As you can see, I am using the default Apple linker, and hardened > settings for the compiler. Try using those settings yourself, and see > what comes out. I tested on FreeBSD12 (since it uses clang rather than gcc) with the following flags and the build completed w/o issue: CFLAGS= -g -fstack-protector-all -fno-omit-frame-pointer -fPIC -fPIE -O2 -Wformat -Wformat-security -Werror=format-security LDFLAGS= -Wl,-z,relro,-z,now -pie CPPFLAGS= -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 In any case, I think we've well established the problem you're hitting has zero to do with OpenLDAP in and of itself. You'll need to take this up elsewhere. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 28 Jan '19

28 Jan '19

As you can see, I am using the default Apple linker, and hardened settings = for the compiler. Try using those settings yourself, and see what comes out= . =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, January 28, 2019 3:16 PM, Quanah Gibson-Mount <quanah(a)symas.com>= wrote: > --On Monday, January 28, 2019 12:10 PM +0000 Rupert Gallagher > ruga(a)protonmail.com wrote: > > > I can replicate your log when using the default tool-chain by Apple. > > The following causes my system to fail with openldap, replicating my > > original bug. The same settings succeed with many other open source > > projects: openldap is the only one that fails. > > Then it sounds like OpenLDAP is tripping a bug in LLVM or related tools. > Again, there are no duplicate symbols in the liblber library. > > --Quanah

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 28 Jan '19

28 Jan '19

--On Monday, January 28, 2019 12:10 PM +0000 Rupert Gallagher <ruga(a)protonmail.com> wrote: > I can replicate your log when using the default tool-chain by Apple. > > The following causes my system to fail *with openldap*, replicating my > original bug. The same settings succeed with *many* other open source > projects: openldap is the only one that fails. Then it sounds like OpenLDAP is tripping a bug in LLVM or related tools. Again, there are no duplicate symbols in the liblber library. --Quanah > 1. install the official clang/llvm tool-chain from llvm.org; > 2. set up the shell as follows: > > export CC="/opt/llvm/bin/clang"; # gcc > export CMAKE_C_COMPILER="/opt/llvm/bin/clang"; > export CPP="/opt/llvm/bin/clang -E"; # cpp > export CXX="/opt/llvm/bin/clang++"; # g++ > export CMAKE_CXX_COMPILER="/opt/llvm/bin/clang++"; # g++ > export AR="/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_AR="/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_LINKER="/usr/bin/ld"; # Apple's own > export NM="/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_NM="/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_OBJDUMP="/opt/llvm/bin/llvm-objdump"; > export RANLIB="/opt/llvm/bin/llvm-ranlib"; > export CMAKE_RANLIB="/opt/llvm/bin/llvm-ranlib"; > sdk_p="$( /usr/bin/xcode-select -print-path )"; > sdk_v="$( /usr/bin/xcrun --show-sdk-version )"; > ># runtime compatibility with former versions: > sdk_c="${sdk_v}"; > case $sdk_v in > 10.14) sdk_c="10.13";; > 10.13) sdk_c="10.13";; > esac > > CFLAGS=""; > CCFLAGS=""; > CPPFLAGS=""; > LDFLAGS=""; > > export MACOSX_DEPLOYMENT_TARGET="${sdk_c}"; > CFLAGS="$CFLAGS -g -mmacosx-version-min=${sdk_c} -isysroot > ${sdk_p}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"; > CFLAGS="$CFLAGS -arch x86_64"; > ># exploit mitigation: RELRO + BIND_NOW > LDFLAGS="$LDFLAGS -Wl,-z,relro,-z,now"; > ># exploit mitigation: stack canary > CFLAGS="$CFLAGS -fstack-protector-all"; > ># nicer stack traces in error messages > CFLAGS="$CFLAGS -fno-omit-frame-pointer"; > ># exploit mitigations: > CFLAGS="$CFLAGS -fPIC -fPIE"; > LDFLAGS="$LDFLAGS -pie"; > ># exploit mitigation: protect memory and string functions > CFLAGS="$CFLAGS -O2"; > CPPFLAGS="$CPPFLAGS -D_FORTIFY_SOURCE=2"; > ># exploit mitigation: format string warnings as errors > CFLAGS="$CFLAGS -Wformat -Wformat-security -Werror=format-security"; > > export CFLAGS; > export CCFLAGS="$CFLAGS"; > export CPPFLAGS; > export CXXFLAGS="$CPPFLAGS"; > export LDFLAGS; > export DSOFLAGS="$LDFLAGS"; > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Fw: Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 28 Jan '19

28 Jan '19

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, January 28, 2019 12:10 PM, Rupert Gallagher <ruga(a)protonmail.com= > wrote: > I can replicate your log when using the default tool-chain by Apple. > > The following causes my system to fail with openldap, replicating my orig= inal bug. > The same settings succeed with many other open source projects: openldap = is the only one that fails. > > 1. install the official clang/llvm tool-chain from llvm.org; > 2. set up the shell as follows: > > export CC=3D"/opt/llvm/bin/clang"; # gcc > export CMAKE_C_COMPILER=3D"/opt/llvm/bin/clang"; > export CPP=3D"/opt/llvm/bin/clang -E"; # cpp > export CXX=3D"/opt/llvm/bin/clang++"; # g++ > export CMAKE_CXX_COMPILER=3D"/opt/llvm/bin/clang++"; # g++ > export AR=3D"/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_AR=3D"/opt/llvm/bin/llvm-ar"; # ar > export CMAKE_LINKER=3D"/usr/bin/ld"; # Apple's own > export NM=3D"/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_NM=3D"/opt/llvm/bin/llvm-nm"; # nm > export CMAKE_OBJDUMP=3D"/opt/llvm/bin/llvm-objdump"; > export RANLIB=3D"/opt/llvm/bin/llvm-ranlib"; > export CMAKE_RANLIB=3D"/opt/llvm/bin/llvm-ranlib"; > sdk_p=3D"$( /usr/bin/xcode-select -print-path )"; > sdk_v=3D"$( /usr/bin/xcrun --show-sdk-version )"; > > > runtime compatibility with former versions: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > sdk_c=3D"${sdk_v}"; > case $sdk_v in > 10.14) sdk_c=3D"10.13";; > 10.13) sdk_c=3D"10.13";; > esac > > CFLAGS=3D""; > CCFLAGS=3D""; > CPPFLAGS=3D""; > LDFLAGS=3D""; > > export MACOSX_DEPLOYMENT_TARGET=3D"${sdk_c}"; > CFLAGS=3D"$CFLAGS -g -mmacosx-version-min=3D${sdk_c} -isysroot ${sdk_p}/P= latforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"; > CFLAGS=3D"$CFLAGS -arch x86_64"; > > exploit mitigation: RELRO + BIND_NOW > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > LDFLAGS=3D"$LDFLAGS -Wl,-z,relro,-z,now"; > > exploit mitigation: stack canary > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -fstack-protector-all"; > > nicer stack traces in error messages > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -fno-omit-frame-pointer"; > > exploit mitigations: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -fPIC -fPIE"; > LDFLAGS=3D"$LDFLAGS -pie"; > > exploit mitigation: protect memory and string functions > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -O2"; > CPPFLAGS=3D"$CPPFLAGS -D_FORTIFY_SOURCE=3D2"; > > exploit mitigation: format string warnings as errors > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > CFLAGS=3D"$CFLAGS -Wformat -Wformat-security -Werror=3Dformat-security"; > > export CFLAGS; > export CCFLAGS=3D"$CFLAGS"; > export CPPFLAGS; > export CXXFLAGS=3D"$CPPFLAGS"; > export LDFLAGS; > export DSOFLAGS=3D"$LDFLAGS";

1 0

Re: (ITS#8959) duplicate symbols
by hyc＠symas.com 25 Jan '19

25 Jan '19

ruga(a)protonmail.com wrote: >> It builds just fine with zero issues. >I'll believe you when I see your log. Ah right, we're all just liars, and that's why it's so important for you to use our software. Quit wasting our time. The burden of proof is on you to provide logs, not us. -- -- 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#8959) duplicate symbols
by ruga＠protonmail.com 25 Jan '19

25 Jan '19

This is a multi-part message in MIME format. --b1_79bd4f6e67d888ad581efca0722453e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 PiBJdCBidWlsZHMganVzdCBmaW5lIHdpdGggemVybyBpc3N1ZXMuCgpJJ2xsIGJlbGlldmUgeW91 IHdoZW4gSSBzZWUgeW91ciBsb2cuCgpPbiBGcmksIEphbiAyNSwgMjAxOSBhdCAxNjowOSwgUXVh bmFoIEdpYnNvbi1Nb3VudCA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6Cgo+IC0tT24gRnJpZGF5 LCBKYW51YXJ5IDI1LCAyMDE5IDc6NDIgQU0gKzAwMDAgUnVwZXJ0IEdhbGxhZ2hlcgo+IDxydWdh QHByb3Rvbm1haWwuY29tPiB3cm90ZToKPgo+Pgo+PiBJdCBpcyBldmlkZW50IGZyb20gdGhlIGJ1 ZyByZXBvcnQgdGhhdCB0aGUgbGlua2VyIGlzIHJlYWRpbmcgdHdpY2UgZnJvbQo+PiB0aGUgc2Ft ZSBwYXRoIGluc2lkZSBvcGVubGRhcCdzIHNvdXJjZSBmb2xkZXIuCj4+Cj4+Cj4+IFRoZSBsaW5r ZXIganVzdCBmb2xsb3dzIHlvdXIgaW5zdHJ1Y3Rpb25zLgo+Cj4gQWdhaW4sIHRoZXJlIGlzIGEg cHJvYmxlbSBzcGVjaWZpYyB0byB5b3VyIGJ1aWxkIGVudmlyb25tZW50Lgo+Cj4gSnVzdCBmb3Ig a2lja3MsIEkgZG93bmxvYWRlZCBhbmQgYnVpbHQgT3BlbkxEQVAgMi40LjQ3IHRvZGF5IG9uIG15 IE9TWAo+IGxhcHRvcCAoRGFyd2luIDE4LjIuMCkgd2l0aCB0aGUgY3VycmVudCBYY29kZSByZWxl YXNlLgo+Cj4gSXQgYnVpbGRzIGp1c3QgZmluZSB3aXRoIHplcm8gaXNzdWVzLgo+Cj4gLS1RdWFu YWgKPgo+IC0tCj4KPiBRdWFuYWggR2lic29uLU1vdW50Cj4gUHJvZHVjdCBBcmNoaXRlY3QKPiBT eW1hcyBDb3Jwb3JhdGlvbgo+IFBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERB UCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoKPiA8aHR0cDovL3d3dy5zeW1hcy5jb20+ --b1_79bd4f6e67d888ad581efca0722453e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj4mZ3Q7Jm5ic3A7PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsiPkl0IGJ1aWxkcyBqdXN0IGZpbmUgd2l0aCB6ZXJvIGlzc3Vlcy48L3NwYW4+PC9kaXY+ PGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+PGJyPjwv c3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87Ij5JJ2xsIGJlbGlldmUgeW91IHdoZW4gSSBzZWUgeW91ciBsb2cuPC9zcGFuPjwvZGl2PiA8 ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5PbiBGcmksIEphbiAyNSwgMjAxOSBhdCAxNjow OSwgUXVhbmFoIEdpYnNvbi1Nb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1YW5haEBzeW1hcy5j b20iIGNsYXNzPSIiPnF1YW5haEBzeW1hcy5jb208L2E+Jmd0OyB3cm90ZTo8YmxvY2txdW90ZSBj bGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+ICAtLU9uIEZyaWRheSwgSmFudWFy eSAyNSwgMjAxOSA3OjQyIEFNICswMDAwIFJ1cGVydCBHYWxsYWdoZXI8YnI+Jmx0O3J1Z2FAcHJv dG9ubWFpbC5jb20mZ3Q7IHdyb3RlOjxicj48YnI+Jmd0Ozxicj4mZ3Q7IEl0IGlzIGV2aWRlbnQg ZnJvbSB0aGUgYnVnIHJlcG9ydCB0aGF0IHRoZSBsaW5rZXIgaXMgcmVhZGluZyB0d2ljZSBmcm9t PGJyPiZndDsgdGhlIHNhbWUgcGF0aCBpbnNpZGUgb3BlbmxkYXAncyBzb3VyY2UgZm9sZGVyLjxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBUaGUgbGlua2VyIGp1c3QgZm9sbG93cyB5b3VyIGluc3Ry dWN0aW9ucy48YnI+PGJyPkFnYWluLCB0aGVyZSBpcyBhIHByb2JsZW0gc3BlY2lmaWMgdG8geW91 ciBidWlsZCBlbnZpcm9ubWVudC48YnI+PGJyPkp1c3QgZm9yIGtpY2tzLCBJIGRvd25sb2FkZWQg YW5kIGJ1aWx0IE9wZW5MREFQIDIuNC40NyB0b2RheSBvbiBteSBPU1g8YnI+bGFwdG9wIChEYXJ3 aW4gMTguMi4wKSB3aXRoIHRoZSBjdXJyZW50IFhjb2RlIHJlbGVhc2UuPGJyPjxicj5JdCBidWls ZHMganVzdCBmaW5lIHdpdGggemVybyBpc3N1ZXMuPGJyPjxicj4tLVF1YW5haDxicj48YnI+PGJy Pjxicj4tLTxicj48YnI+UXVhbmFoIEdpYnNvbi1Nb3VudDxicj5Qcm9kdWN0IEFyY2hpdGVjdDxi cj5TeW1hcyBDb3Jwb3JhdGlvbjxicj5QYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVk IExEQVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxEQVA6PGJyPiZsdDtodHRwOi8vd3d3LnN5 bWFzLmNvbSZndDs8YnI+PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj4= --b1_79bd4f6e67d888ad581efca0722453e4--

1 0

(ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"
by michael＠stroeder.com 25 Jan '19

25 Jan '19

Full_Name: Michael Str.der Version: OS: URL: Submission from: (NULL) (213.240.182.19) All links herein are dead: https://www.openldap.org/faq/data/cache/220.html I'd suggest to remove this FAQ page completely.

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 25 Jan '19

25 Jan '19

--On Friday, January 25, 2019 7:42 AM +0000 Rupert Gallagher <ruga(a)protonmail.com> wrote: > > It is evident from the bug report that the linker is reading twice from > the same path inside openldap's source folder. > > > The linker just follows your instructions. Again, there is a problem specific to your build environment. Just for kicks, I downloaded and built OpenLDAP 2.4.47 today on my OSX laptop (Darwin 18.2.0) with the current Xcode release. It builds just fine with zero issues. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by quanah＠symas.com 25 Jan '19

25 Jan '19

--On Friday, January 25, 2019 1:51 PM +0000 hbohnenkamp(a)united-internet.de wrote: > While writing the test scripts I was wondering if somebody else did > ever do something similar. There are of course tests in the test > directory of the Openldap sources, but are there any (regression) > tests made (e.g. for Openldap release candidates) which try to > simulate large productive setups? Hi Henrik, I've been expanding the regression test cases (See tests/data/regressions) and made it possible to run "make its" to trigger executing them prior to releases. However for obvious reasons that clearly isn't going to include large datasets. I've been quite interested in setting adding tests for large data sets that are stored and executed outside of the regular set of OpenLDAP tests and source tree but so far haven't had a specific case that required such a thing. So if this issue turns out to require testing against a large data set, it could be the first item for that work. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hbohnenkamp＠united-internet.de 25 Jan '19

25 Jan '19

Some months have passed but I finally found the time to set up a test rig for regression testing of my patch under LIVE conditions. I'll describe the setup below. The good news is, today I found the first bug in my patch (handling of scope=one searches is incorrect). I say "good" news because it shows that the testing setup is doing something right. In related news, it turns out that apparently the implementation of alias-dereferencing in the hdb backend seems to be faulty, too... not wrt performance, but pureley from a functional point of view. We found a search request which should return around 6700 entries, but only deliveres around 6150. My patched mdb-implementation returns more closely to 6700 entries, but for obvious reasons also that might be wrong still. I had not the time yet to find out what goes wrong in the hdb backend. I'll open a bug if I manage to reproduce it somehow under lab conditions. My test setup is like this: I use the productive LDAP content of my company of about 2.4 million Entries, slapcated from the LDAP master, to test against. All user passwd hashes are replaced with a default hash so that the test tool can bind successfully. Slapd configuration is essentially the same as for our productive slaves (esp. the ACLs). As test cases I use slapd logfiles of our productive clusters (approx 24 million log lines (stats) per server per 24h). Mostly binds and searches. Those are directed against the hdb-configured slapd and a patched-mdb-configured slapd (v 2.4.47). Results are compared: whether binds succeed or fail, and the returned search results. I will extend the tester to also include other operations, but this is waht is relevant to test the patch, I guess. In the taxonomy of test-methods I would classify this as "advanced monkey testing". While writing the test scripts I was wondering if somebody else did ever do something similar. There are of course tests in the test directory of the Openldap sources, but are there any (regression) tests made (e.g. for Openldap release candidates) which try to simulate large productive setups? -- Henrik Bohnenkamp

1 0

Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 25 Jan '19

25 Jan '19

This is a multi-part message in MIME format. --b1_4735ab60e16b531e1cbee2b5bac08b8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SXQgaXMgZXZpZGVudCBmcm9tIHRoZSBidWcgcmVwb3J0IHRoYXQgdGhlIGxpbmtlciBpcyByZWFk aW5nIHR3aWNlIGZyb20gdGhlIHNhbWUgcGF0aCBpbnNpZGUgb3BlbmxkYXAncyBzb3VyY2UgZm9s ZGVyLgoKVGhlIGxpbmtlciBqdXN0IGZvbGxvd3MgeW91ciBpbnN0cnVjdGlvbnMuCgpPbiBGcmks IEphbiAyNSwgMjAxOSBhdCAwMTozMSwgUXVhbmFoIEdpYnNvbi1Nb3VudCA8cXVhbmFoQHN5bWFz LmNvbT4gd3JvdGU6Cgo+IC0tT24gVGh1cnNkYXksIEphbnVhcnkgMjQsIDIwMTkgMTA6NTkgUE0g KzAwMDAgcnVnYUBwcm90b25tYWlsLmNvbSB3cm90ZToKPgo+PiBUaGlzIGlzIGEgbXVsdGktcGFy dCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0Lgo+Pgo+PiAtLWIxXzI2NjVhMzUzNjdiOWYyOWQyOWU0 YjBlZmMwNWM3OTgxCj4+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOAo+ PiBDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQKPj4KPj4gTXkgYnVpbGQgZW52aXJv bm1lbnQgd29ya3Mgd2VsbCBmb3IgbWFueSBvcGVuIHNvdXJjZSBwcm9qZWN0cy4KPgo+IE9wZW5M REFQIGJ1aWxkcyBhY3Jvc3MgZG96ZW5zIG9mIGxpbnV4IGRpc3RyaWJ1dGlvbnMgYW5kIG9wZXJh dGluZyBzeXN0ZW1zCj4ganVzdCBmaW5lLiBUaGUgZXJyb3IgeW91J3ZlIHByb3ZpZGVkIGNsZWFy bHkgaW5kaWNhdGVzIHRoZXJlJ3MgYSBwcm9ibGVtCj4gd2l0aCB0aGUgc2V0dXAgb24geW91ciBz eXN0ZW0gYW5kIGRvZXMgbm90IHNob3cgYW55IGluZGljYXRpb24gb2YgYSBwcm9ibGVtCj4gd2l0 aCB0aGUgT3BlbkxEQVAgYnVpbGQgcHJvY2Vzcy4gQXMgd2FzIGFscmVhZHkgbm90ZWQsIHRoZXJl IGFyZSBubwo+IGR1cGxpY2F0ZSBzeW1ib2xzIGluIHRoZSBPcGVuTERBUCBzb3VyY2UgY29kZS4g SSB3b3VsZCBndWVzcyB0aGF0IHlvdQo+IHBlcmhhcHMgaGF2ZSBhbm90aGVyIGluc3RhbGxhdGlv biBvZiBPcGVuTERBUCdzIGxpYmxiZXIgdGhhdCdzIGdldHRpbmcKPiBpbmNvcnJlY3RseSBpbmNs dWRlZCBkdXJpbmcgdGhlIGxpbmsgcGhhc2UuIFJlZ2FyZGxlc3MsIHRoZSBPcGVuTERBUCBJVFMK PiBzeXN0ZW0gaXMgZm9yIHJlcG9ydGluZyBidWdzIGluIHRoZSBPcGVuTERBUCBzb2Z0d2FyZS4g SXQgaXMgbm90IGZvcgo+IHJlcG9ydGluZyBpc3N1ZXMgd2l0aCB5b3VyIGJ1aWxkIGVudmlyb25t ZW50LiBUaGlzIElUUyB3aWxsIHJlbWFpbiBjbG9zZWQuCj4KPiBJZiB5b3UgbmVlZCBhZGRpdGlv bmFsIGFzc2lzdGFuY2Ugd2l0aCBjb21waWxpbmcgT3BlbkxEQVAsIHlvdSBtYXkgd2lzaCB0bwo+ IGFzayBvbiB0aGUgb3BlbmxkYXAtdGVjaG5pY2FsQG9wZW5sZGFwLm9yZyBtYWlsaW5nIGxpc3Qu IEhvd2V2ZXIgSSB3b3VsZAo+IGZpcnN0IHJlc29sdmUgd2hhdGV2ZXIncyBicm9rZW4gaW4geW91 ciBidWlsZCBlbnZpcm9ubWVudCBhcyBpdCdzIGNsZWFybHkKPiBub3QgYW4gT3BlbkxEQVAgaXNz dWUuCj4KPiBXYXJtIHJlZ2FyZHMsCj4gUXVhbmFoCj4KPiAtLQo+Cj4gUXVhbmFoIEdpYnNvbi1N b3VudAo+IFByb2R1Y3QgQXJjaGl0ZWN0Cj4gU3ltYXMgQ29ycG9yYXRpb24KPiBQYWNrYWdlZCwg Y2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxE QVA6Cj4gPGh0dHA6Ly93d3cuc3ltYXMuY29tPg== --b1_4735ab60e16b531e1cbee2b5bac08b8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JdCBpcyBldmlkZW50IGZyb20gdGhlIGJ1ZyByZXBvcnQgdGhhdCB0aGUgbGlua2VyIGlz IHJlYWRpbmcgdHdpY2UgZnJvbSB0aGUgc2FtZSBwYXRoIGluc2lkZSBvcGVubGRhcCdzIHNvdXJj ZSBmb2xkZXIuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbGlua2VyIGp1c3QgZm9sbG93 cyB5b3VyIGluc3RydWN0aW9ucy4mbmJzcDs8L2Rpdj4gPGRpdj48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+T24gRnJpLCBKYW4gMjUsIDIwMTkgYXQgMDE6MzEsIFF1YW5h aCBHaWJzb24tTW91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWFuYWhAc3ltYXMuY29tIiBjbGFz cz0iIj5xdWFuYWhAc3ltYXMuY29tPC9hPiZndDsgd3JvdGU6PGJsb2NrcXVvdGUgY2xhc3M9InBy b3Rvbm1haWxfcXVvdGUiIHR5cGU9ImNpdGUiPiAgLS1PbiBUaHVyc2RheSwgSmFudWFyeSAyNCwg MjAxOSAxMDo1OSBQTSArMDAwMCBydWdhQHByb3Rvbm1haWwuY29tIHdyb3RlOjxicj48YnI+Jmd0 OyBUaGlzIGlzIGEgbXVsdGktcGFydCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0Ljxicj4mZ3Q7PGJy PiZndDsgLS1iMV8yNjY1YTM1MzY3YjlmMjlkMjllNGIwZWZjMDVjNzk4MTxicj4mZ3Q7IENvbnRl bnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtODxicj4mZ3Q7IENvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IGJhc2U2NDxicj4mZ3Q7PGJyPiZndDsgTXkgYnVpbGQgZW52aXJvbm1lbnQg d29ya3Mgd2VsbCBmb3IgbWFueSBvcGVuIHNvdXJjZSBwcm9qZWN0cy48YnI+PGJyPk9wZW5MREFQ IGJ1aWxkcyBhY3Jvc3MgZG96ZW5zIG9mIGxpbnV4IGRpc3RyaWJ1dGlvbnMgYW5kIG9wZXJhdGlu ZyBzeXN0ZW1zPGJyPmp1c3QgZmluZS4gIFRoZSBlcnJvciB5b3UndmUgcHJvdmlkZWQgY2xlYXJs eSBpbmRpY2F0ZXMgdGhlcmUncyBhIHByb2JsZW08YnI+d2l0aCB0aGUgc2V0dXAgb24geW91ciBz eXN0ZW0gYW5kIGRvZXMgbm90IHNob3cgYW55IGluZGljYXRpb24gb2YgYSBwcm9ibGVtPGJyPndp dGggdGhlIE9wZW5MREFQIGJ1aWxkIHByb2Nlc3MuICBBcyB3YXMgYWxyZWFkeSBub3RlZCwgdGhl cmUgYXJlIG5vPGJyPmR1cGxpY2F0ZSBzeW1ib2xzIGluIHRoZSBPcGVuTERBUCBzb3VyY2UgY29k ZS4gIEkgd291bGQgZ3Vlc3MgdGhhdCB5b3U8YnI+cGVyaGFwcyBoYXZlIGFub3RoZXIgaW5zdGFs bGF0aW9uIG9mIE9wZW5MREFQJ3MgbGlibGJlciB0aGF0J3MgZ2V0dGluZzxicj5pbmNvcnJlY3Rs eSBpbmNsdWRlZCBkdXJpbmcgdGhlIGxpbmsgcGhhc2UuICBSZWdhcmRsZXNzLCB0aGUgT3BlbkxE QVAgSVRTPGJyPnN5c3RlbSBpcyBmb3IgcmVwb3J0aW5nIGJ1Z3MgaW4gdGhlIE9wZW5MREFQIHNv ZnR3YXJlLiAgSXQgaXMgbm90IGZvcjxicj5yZXBvcnRpbmcgaXNzdWVzIHdpdGggeW91ciBidWls ZCBlbnZpcm9ubWVudC4gIFRoaXMgSVRTIHdpbGwgcmVtYWluIGNsb3NlZC48YnI+PGJyPklmIHlv dSBuZWVkIGFkZGl0aW9uYWwgYXNzaXN0YW5jZSB3aXRoIGNvbXBpbGluZyBPcGVuTERBUCwgeW91 IG1heSB3aXNoIHRvPGJyPmFzayBvbiB0aGUgb3BlbmxkYXAtdGVjaG5pY2FsQG9wZW5sZGFwLm9y ZyBtYWlsaW5nIGxpc3QuICBIb3dldmVyIEkgd291bGQ8YnI+Zmlyc3QgcmVzb2x2ZSB3aGF0ZXZl cidzIGJyb2tlbiBpbiB5b3VyIGJ1aWxkIGVudmlyb25tZW50IGFzIGl0J3MgY2xlYXJseTxicj5u b3QgYW4gT3BlbkxEQVAgaXNzdWUuPGJyPjxicj5XYXJtIHJlZ2FyZHMsPGJyPlF1YW5haDxicj48 YnI+PGJyPi0tPGJyPjxicj5RdWFuYWggR2lic29uLU1vdW50PGJyPlByb2R1Y3QgQXJjaGl0ZWN0 PGJyPlN5bWFzIENvcnBvcmF0aW9uPGJyPlBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0 ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDo8YnI+Jmx0O2h0dHA6Ly93d3cu c3ltYXMuY29tJmd0Ozxicj48YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2Pg== --b1_4735ab60e16b531e1cbee2b5bac08b8c--

1 0

Re: (ITS#8961) Crash when deleting olcDbIndex (back-mdb)
by h.b.furuseth＠usit.uio.no 25 Jan '19

25 Jan '19

On 1/25/19 1:31 AM, ryan(a)nardis.ca wrote: > Possible duplicate of ITS#8472? Yes

1 0

Re: (ITS#8959) duplicate symbols
by quanah＠symas.com 25 Jan '19

25 Jan '19

--On Thursday, January 24, 2019 10:59 PM +0000 ruga(a)protonmail.com wrote: > This is a multi-part message in MIME format. > > --b1_2665a35367b9f29d29e4b0efc05c7981 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: base64 > > My build environment works well for many open source projects. OpenLDAP builds across dozens of linux distributions and operating systems just fine. The error you've provided clearly indicates there's a problem with the setup on your system and does not show any indication of a problem with the OpenLDAP build process. As was already noted, there are no duplicate symbols in the OpenLDAP source code. I would guess that you perhaps have another installation of OpenLDAP's liblber that's getting incorrectly included during the link phase. Regardless, the OpenLDAP ITS system is for reporting bugs in the OpenLDAP software. It is not for reporting issues with your build environment. This ITS will remain closed. If you need additional assistance with compiling OpenLDAP, you may wish to ask on the openldap-technical(a)openldap.org mailing list. However I would first resolve whatever's broken in your build environment as it's clearly not an OpenLDAP issue. Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8961) Crash when deleting olcDbIndex (back-mdb)
by ryan＠nardis.ca 25 Jan '19

25 Jan '19

Possible duplicate of ITS#8472?

1 0

(ITS#8961) Crash when deleting olcDbIndex (back-mdb)
by h.b.furuseth＠usit.uio.no 25 Jan '19

25 Jan '19

Full_Name: Hallvard Breien Furuseth Version: RE24 de23e57b13fa25ffc9b9c204fd22a50dbde6c0b2 OS: Linux: Fedora 28 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.90.49.117) ch_malloc(0) asserts when completely deleting olcDbIndex from an MDB database. $ mkdir db.foo $ servers/slapd/slapd -h ldapi://ldapi/ -f slapd.conf -d0 & $ ldapmodify -H ldapi://ldapi/ -QYEXTERNAL <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcDbIndex - EOF modifying entry "olcDatabase={1}mdb,cn=config" slapd: ch_malloc.c:107: ch_calloc: Assertion `0' failed. ldap_result: Can't contact LDAP server (-1) $ cat slapd.conf include schema/core.schema authz-regexp ,cn=peercred,cn=external,cn=auth cn=admin database config rootdn cn=admin database mdb suffix o=foo directory db.foo index cn eq

1 0

Re: (ITS#8959) duplicate symbols
by ruga＠protonmail.com 24 Jan '19

24 Jan '19

This is a multi-part message in MIME format. --b1_2665a35367b9f29d29e4b0efc05c7981 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TXkgYnVpbGQgZW52aXJvbm1lbnQgd29ya3Mgd2VsbCBmb3IgbWFueSBvcGVuIHNvdXJjZSBwcm9q ZWN0cy4KCk9uIFRodSwgSmFuIDI0LCAyMDE5IGF0IDE5OjU2LCBIb3dhcmQgQ2h1IDxoeWNAc3lt YXMuY29tPiB3cm90ZToKCj4gcnVnYUBwcm90b25tYWlsLmNvbSB3cm90ZToKPj4gRnVsbF9OYW1l OiBSdXBlcnQKPj4gVmVyc2lvbjogMi40LjQ3Cj4+IE9TOiBEYXJ3aW4gYWxpY2UgMTcuNy4wIERh cndpbiBLZXJuZWwgVmVyc2lvbiAxNy43LjA6IEZyaSBOb3YgMiAyMDo0MzoxNiBQRFQgMjAxODsg cm9vdDp4bnUtNDU3MC43MS4xN34xL1JFTEVBU0VfWDg2XzY0IHg4Nl82NAo+PiBVUkw6IGZ0cDov L2Z0cC5vcGVubGRhcC5vcmcvaW5jb21pbmcvCj4+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICg1 LjE3MC4xMjAuMTI2KQo+Pgo+Pgo+PiBOT1RFCj4+Cj4+PiBtYWtlCj4+Cj4+IFsuLi5dCj4+IGR1 cGxpY2F0ZSBzeW1ib2wgX2Jlcl9pbnRfb3B0aW9ucyBpbjoKPj4gL29wdC9zcmMvb3BlbmxkYXAt Mi40LjQ3L2xpYnJhcmllcy9saWJsYmVyLy5saWJzL2xpYmxiZXIuYShvcHRpb25zLm8pCj4+IC4u Ly4uL2xpYnJhcmllcy9saWJsYmVyLy5saWJzL2xpYmxiZXIuYShvcHRpb25zLm8pCj4+IGR1cGxp Y2F0ZSBzeW1ib2wgX2Jlcl9zZXRfb3B0aW9uIGluOgo+PiAvb3B0L3NyYy9vcGVubGRhcC0yLjQu NDcvbGlicmFyaWVzL2xpYmxiZXIvLmxpYnMvbGlibGJlci5hKG9wdGlvbnMubykKPj4gLi4vLi4v bGlicmFyaWVzL2xpYmxiZXIvLmxpYnMvbGlibGJlci5hKG9wdGlvbnMubykKPj4gZHVwbGljYXRl IHN5bWJvbCBfYmVyX2dldF9vcHRpb24gaW46Cj4+IC9vcHQvc3JjL29wZW5sZGFwLTIuNC40Ny9s aWJyYXJpZXMvbGlibGJlci8ubGlicy9saWJsYmVyLmEob3B0aW9ucy5vKQo+PiAuLi8uLi9saWJy YXJpZXMvbGlibGJlci8ubGlicy9saWJsYmVyLmEob3B0aW9ucy5vKQo+PiBsZDogMyBkdXBsaWNh dGUgc3ltYm9scyBmb3IgYXJjaGl0ZWN0dXJlIHg4Nl82NAo+PiBjbGFuZy03OiBlcnJvcjogbGlu a2VyIGNvbW1hbmQgZmFpbGVkIHdpdGggZXhpdCBjb2RlIDEgKHVzZSAtdiB0byBzZWUKPj4gaW52 b2NhdGlvbikKPj4gbWFrZVsyXTogKioqIFthcGl0ZXN0XSBFcnJvciAxCj4+IG1ha2VbMl06ICoq KiBXYWl0aW5nIGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uCj4+IGR1cGxpY2F0ZSBzeW1ib2wgX2Jl cl9pbnRfb3B0aW9ucyBpbjoKPj4gL29wdC9zcmMvb3BlbmxkYXAtMi40LjQ3L2xpYnJhcmllcy9s aWJsYmVyLy5saWJzL2xpYmxiZXIuYShvcHRpb25zLm8pCj4+IC4uLy4uL2xpYnJhcmllcy9saWJs YmVyLy5saWJzL2xpYmxiZXIuYShvcHRpb25zLm8pCj4+IGR1cGxpY2F0ZSBzeW1ib2wgX2Jlcl9z ZXRfb3B0aW9uIGluOgo+PiAvb3B0L3NyYy9vcGVubGRhcC0yLjQuNDcvbGlicmFyaWVzL2xpYmxi ZXIvLmxpYnMvbGlibGJlci5hKG9wdGlvbnMubykKPj4gLi4vLi4vbGlicmFyaWVzL2xpYmxiZXIv LmxpYnMvbGlibGJlci5hKG9wdGlvbnMubykKPj4gZHVwbGljYXRlIHN5bWJvbCBfYmVyX2dldF9v cHRpb24gaW46Cj4+IC9vcHQvc3JjL29wZW5sZGFwLTIuNC40Ny9saWJyYXJpZXMvbGlibGJlci8u bGlicy9saWJsYmVyLmEob3B0aW9ucy5vKQo+PiAuLi8uLi9saWJyYXJpZXMvbGlibGJlci8ubGli cy9saWJsYmVyLmEob3B0aW9ucy5vKQo+PiBsZDogMyBkdXBsaWNhdGUgc3ltYm9scyBmb3IgYXJj aGl0ZWN0dXJlIHg4Nl82NAo+PiBjbGFuZy03OiBlcnJvcjogbGlua2VyIGNvbW1hbmQgZmFpbGVk IHdpdGggZXhpdCBjb2RlIDEgKHVzZSAtdiB0byBzZWUKPj4gaW52b2NhdGlvbikKPj4gbWFrZVsy XTogKioqIFtkbnRlc3RdIEVycm9yIDEKPj4gbWFrZVsxXTogKioqIFthbGwtY29tbW9uXSBFcnJv ciAxCj4+IG1ha2U6ICoqKiBbYWxsLWNvbW1vbl0gRXJyb3IgMQo+Pgo+Pgo+PiBDT01NRU5UCj4+ Cj4+IFNpbGx5IGJ1ZywgdHJpcHBpbmcgdGhlIGNvbXBpbGVyLgo+Cj4gU291bmRzIGxpa2UgYSBs aW5rZXIgYnVnIG9yIHNvbWUgb3RoZXIgcHJvYmxlbSBpbiB5b3VyIGJ1aWxkIGVudmlyb25tZW50 Lgo+IFRoZXJlIGFyZSBubyBkdXBsaWNhdGUgc3ltYm9scyBhbnl3aGVyZSBpbiB0aGlzIHNvdXJj ZSB0cmVlLgo+Cj4gLS0KPiAtLSBIb3dhcmQgQ2h1Cj4gQ1RPLCBTeW1hcyBDb3JwLiBodHRwOi8v d3d3LnN5bWFzLmNvbQo+IERpcmVjdG9yLCBIaWdobGFuZCBTdW4gaHR0cDovL2hpZ2hsYW5kc3Vu LmNvbS9oeWMvCj4gQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCBodHRwOi8vd3d3Lm9wZW5sZGFw Lm9yZy9wcm9qZWN0Lw== --b1_2665a35367b9f29d29e4b0efc05c7981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 ICAgPGRpdj5NeSBidWlsZCBlbnZpcm9ubWVudCB3b3JrcyB3ZWxsIGZvciBtYW55IG9wZW4gc291 cmNlIHByb2plY3RzLiZuYnNwOzwvZGl2PiA8ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5P biBUaHUsIEphbiAyNCwgMjAxOSBhdCAxOTo1NiwgSG93YXJkIENodSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmh5Y0BzeW1hcy5jb20iIGNsYXNzPSIiPmh5Y0BzeW1hcy5jb208L2E+Jmd0OyB3cm90ZTo8 YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+ICBydWdhQHBy b3Rvbm1haWwuY29tIHdyb3RlOjxicj4mZ3Q7IEZ1bGxfTmFtZTogUnVwZXJ0PGJyPiZndDsgVmVy c2lvbjogMi40LjQ3PGJyPiZndDsgT1M6IERhcndpbiBhbGljZSAxNy43LjAgRGFyd2luIEtlcm5l bCBWZXJzaW9uIDE3LjcuMDogRnJpIE5vdiAgMiAyMDo0MzoxNiBQRFQgMjAxODsgcm9vdDp4bnUt NDU3MC43MS4xN34xL1JFTEVBU0VfWDg2XzY0IHg4Nl82NDxicj4mZ3Q7IFVSTDogZnRwOi8vZnRw Lm9wZW5sZGFwLm9yZy9pbmNvbWluZy88YnI+Jmd0OyBTdWJtaXNzaW9uIGZyb206IChOVUxMKSAo NS4xNzAuMTIwLjEyNik8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgTk9URTxicj4mZ3Q7PGJyPiZn dDsmZ3Q7IG1ha2U8YnI+Jmd0Ozxicj4mZ3Q7IFsuLi5dPGJyPiZndDsgZHVwbGljYXRlIHN5bWJv bCBfYmVyX2ludF9vcHRpb25zIGluOjxicj4mZ3Q7ICAgICAvb3B0L3NyYy9vcGVubGRhcC0yLjQu NDcvbGlicmFyaWVzL2xpYmxiZXIvLmxpYnMvbGlibGJlci5hKG9wdGlvbnMubyk8YnI+Jmd0OyAg ICAgLi4vLi4vbGlicmFyaWVzL2xpYmxiZXIvLmxpYnMvbGlibGJlci5hKG9wdGlvbnMubyk8YnI+ Jmd0OyBkdXBsaWNhdGUgc3ltYm9sIF9iZXJfc2V0X29wdGlvbiBpbjo8YnI+Jmd0OyAgICAgL29w dC9zcmMvb3BlbmxkYXAtMi40LjQ3L2xpYnJhcmllcy9saWJsYmVyLy5saWJzL2xpYmxiZXIuYShv cHRpb25zLm8pPGJyPiZndDsgICAgIC4uLy4uL2xpYnJhcmllcy9saWJsYmVyLy5saWJzL2xpYmxi ZXIuYShvcHRpb25zLm8pPGJyPiZndDsgZHVwbGljYXRlIHN5bWJvbCBfYmVyX2dldF9vcHRpb24g aW46PGJyPiZndDsgICAgIC9vcHQvc3JjL29wZW5sZGFwLTIuNC40Ny9saWJyYXJpZXMvbGlibGJl ci8ubGlicy9saWJsYmVyLmEob3B0aW9ucy5vKTxicj4mZ3Q7ICAgICAuLi8uLi9saWJyYXJpZXMv bGlibGJlci8ubGlicy9saWJsYmVyLmEob3B0aW9ucy5vKTxicj4mZ3Q7IGxkOiAzIGR1cGxpY2F0 ZSBzeW1ib2xzIGZvciBhcmNoaXRlY3R1cmUgeDg2XzY0PGJyPiZndDsgY2xhbmctNzogZXJyb3I6 IGxpbmtlciBjb21tYW5kIGZhaWxlZCB3aXRoIGV4aXQgY29kZSAxICh1c2UgLXYgdG8gc2VlPGJy PiZndDsgaW52b2NhdGlvbik8YnI+Jmd0OyBtYWtlWzJdOiAqKiogW2FwaXRlc3RdIEVycm9yIDE8 YnI+Jmd0OyBtYWtlWzJdOiAqKiogV2FpdGluZyBmb3IgdW5maW5pc2hlZCBqb2JzLi4uLjxicj4m Z3Q7IGR1cGxpY2F0ZSBzeW1ib2wgX2Jlcl9pbnRfb3B0aW9ucyBpbjo8YnI+Jmd0OyAgICAgL29w dC9zcmMvb3BlbmxkYXAtMi40LjQ3L2xpYnJhcmllcy9saWJsYmVyLy5saWJzL2xpYmxiZXIuYShv cHRpb25zLm8pPGJyPiZndDsgICAgIC4uLy4uL2xpYnJhcmllcy9saWJsYmVyLy5saWJzL2xpYmxi ZXIuYShvcHRpb25zLm8pPGJyPiZndDsgZHVwbGljYXRlIHN5bWJvbCBfYmVyX3NldF9vcHRpb24g aW46PGJyPiZndDsgICAgIC9vcHQvc3JjL29wZW5sZGFwLTIuNC40Ny9saWJyYXJpZXMvbGlibGJl ci8ubGlicy9saWJsYmVyLmEob3B0aW9ucy5vKTxicj4mZ3Q7ICAgICAuLi8uLi9saWJyYXJpZXMv bGlibGJlci8ubGlicy9saWJsYmVyLmEob3B0aW9ucy5vKTxicj4mZ3Q7IGR1cGxpY2F0ZSBzeW1i b2wgX2Jlcl9nZXRfb3B0aW9uIGluOjxicj4mZ3Q7ICAgICAvb3B0L3NyYy9vcGVubGRhcC0yLjQu NDcvbGlicmFyaWVzL2xpYmxiZXIvLmxpYnMvbGlibGJlci5hKG9wdGlvbnMubyk8YnI+Jmd0OyAg ICAgLi4vLi4vbGlicmFyaWVzL2xpYmxiZXIvLmxpYnMvbGlibGJlci5hKG9wdGlvbnMubyk8YnI+ Jmd0OyBsZDogMyBkdXBsaWNhdGUgc3ltYm9scyBmb3IgYXJjaGl0ZWN0dXJlIHg4Nl82NDxicj4m Z3Q7IGNsYW5nLTc6IGVycm9yOiBsaW5rZXIgY29tbWFuZCBmYWlsZWQgd2l0aCBleGl0IGNvZGUg MSAodXNlIC12IHRvIHNlZTxicj4mZ3Q7IGludm9jYXRpb24pPGJyPiZndDsgbWFrZVsyXTogKioq IFtkbnRlc3RdIEVycm9yIDE8YnI+Jmd0OyBtYWtlWzFdOiAqKiogW2FsbC1jb21tb25dIEVycm9y IDE8YnI+Jmd0OyBtYWtlOiAqKiogW2FsbC1jb21tb25dIEVycm9yIDE8YnI+Jmd0Ozxicj4mZ3Q7 PGJyPiZndDsgQ09NTUVOVDxicj4mZ3Q7PGJyPiZndDsgU2lsbHkgYnVnLCB0cmlwcGluZyB0aGUg Y29tcGlsZXIuPGJyPjxicj5Tb3VuZHMgbGlrZSBhIGxpbmtlciBidWcgb3Igc29tZSBvdGhlciBw cm9ibGVtIGluIHlvdXIgYnVpbGQgZW52aXJvbm1lbnQuPGJyPlRoZXJlIGFyZSBubyBkdXBsaWNh dGUgc3ltYm9scyBhbnl3aGVyZSBpbiB0aGlzIHNvdXJjZSB0cmVlLjxicj48YnI+LS08YnI+ICAt LSBIb3dhcmQgQ2h1PGJyPiAgQ1RPLCBTeW1hcyBDb3JwLiAgICAgICAgICAgaHR0cDovL3d3dy5z eW1hcy5jb208YnI+ICBEaXJlY3RvciwgSGlnaGxhbmQgU3VuICAgICBodHRwOi8vaGlnaGxhbmRz dW4uY29tL2h5Yy88YnI+ICBDaGllZiBBcmNoaXRlY3QsIE9wZW5MREFQICBodHRwOi8vd3d3Lm9w ZW5sZGFwLm9yZy9wcm9qZWN0Lzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+ --b1_2665a35367b9f29d29e4b0efc05c7981--

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 24 Jan '19

24 Jan '19

My bug report's bug.sh script is broken. It needs "mpid=$!" before "sleep 0.5", and "wait $mpid" before "kill $pid". -- Hallvard

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 24 Jan '19

24 Jan '19

On 22.01.2019 19:55, Ondřej Kuzník wrote: > The problem is not that it's still scheduled when the pause is > requested, scheduled tasks don't prevent a pause (and I think some > of them need to be a bit more aware of that fact), but that it's been > picked up by a worker thread and is running while cn=config waits for > them to pause. _And_ that a pause request is all-or-nothing. This demo code of graduated wait-for-pause works for me. For RE24, it doesn't combine easily with Git master's multiple tpool queues:-( ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-190124.patch.gz But I'm not volunteering to write one for master anytime soon, unless someone has less complicated ideas for that than I do. A real version looks like more work than I expected anyway. > What I was suggesting was that it could check every so often whether it > might be holding up a pause and join it just like some other tasks do. > But that's only a good idea if it's able to handle the changes that > happen during the pause (indexes reconfigured again, the database going > away, ...) as well as being able to release any locks temporarily. Yes. I should have answered that, but I still cannot decide what I think of it. I see no locks to worry about in that code, but the rest does make me nervous. Possibly we can find some times where we can pause safely, but not a general case. For example, in the case of back-mdb we could register scheduled config operations the database itself, in a "(TODO)" LMDB DB. Doesn't help with schema changes, but does help renumbering slapd DBs. -- Hallvard

1 0

Re: (ITS#8959) duplicate symbols
by hyc＠symas.com 24 Jan '19

24 Jan '19

ruga(a)protonmail.com wrote: > Full_Name: Rupert > Version: 2.4.47 > OS: Darwin alice 17.7.0 Darwin Kernel Version 17.7.0: Fri Nov 2 20:43:16 PDT 2018; root:xnu-4570.71.17~1/RELEASE_X86_64 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (5.170.120.126) > > > NOTE > >> make > > [...] > duplicate symbol _ber_int_options in: > /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) > ../../libraries/liblber/.libs/liblber.a(options.o) > duplicate symbol _ber_set_option in: > /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) > ../../libraries/liblber/.libs/liblber.a(options.o) > duplicate symbol _ber_get_option in: > /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) > ../../libraries/liblber/.libs/liblber.a(options.o) > ld: 3 duplicate symbols for architecture x86_64 > clang-7: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [apitest] Error 1 > make[2]: *** Waiting for unfinished jobs.... > duplicate symbol _ber_int_options in: > /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) > ../../libraries/liblber/.libs/liblber.a(options.o) > duplicate symbol _ber_set_option in: > /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) > ../../libraries/liblber/.libs/liblber.a(options.o) > duplicate symbol _ber_get_option in: > /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) > ../../libraries/liblber/.libs/liblber.a(options.o) > ld: 3 duplicate symbols for architecture x86_64 > clang-7: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [dntest] Error 1 > make[1]: *** [all-common] Error 1 > make: *** [all-common] Error 1 > > > COMMENT > > Silly bug, tripping the compiler. Sounds like a linker bug or some other problem in your build environment. There are no duplicate symbols anywhere in this source tree. -- -- 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#8959) duplicate symbols
by quanah＠symas.com 24 Jan '19

24 Jan '19

--On Thursday, January 24, 2019 6:26 PM +0000 ruga(a)protonmail.com wrote: > Full_Name: Rupert > Version: 2.4.47 > OS: Darwin alice 17.7.0 Darwin Kernel Version 17.7.0: Fri Nov 2 20:43:16 > PDT 2018; root:xnu-4570.71.17~1/RELEASE_X86_64 x86_64 URL: > ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (5.170.120.126) Builds fine for me using clang compiler on FreeBSD. Also appears to work fine for Apple, since it ships the OpenLDAP libraries. You'll need to provide more details as to exactly what you're doing to encounter this issue. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8960) code quality
by quanah＠symas.com 24 Jan '19

24 Jan '19

--On Thursday, January 24, 2019 6:47 PM +0000 ruga(a)protonmail.com wrote: > Full_Name: Rupert > Version: - > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (5.170.120.126) > > > The source code of openldap went through lumnify's meat grinder, > receiving a score of 1 (fail) out of 5. Score 1 means "A lot of patch Sounds like lumnify is a poor quality product. You may wish to use something better written? In any case, the ITS system is for bug reports, this is clearly not a bug report. It will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8960) code quality
by ruga＠protonmail.com 24 Jan '19

24 Jan '19

Full_Name: Rupert Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (5.170.120.126) The source code of openldap went through lumnify's meat grinder, receiving a score of 1 (fail) out of 5. Score 1 means "A lot of patch work and bandages, project is most likely in initial stage of development. Most of source code is highly unmaintainable and feels a bit chaotic. It is good starting point, but plenty of work ahead. Don't give up yet!". I see old bugs pending. Is the project active? [1] https://sysadmin.libhunt.com/openldap-alternatives [2] https://lumnify.com/grades/?rel=libhunt

1 0

(ITS#8959) duplicate symbols
by ruga＠protonmail.com 24 Jan '19

24 Jan '19

Full_Name: Rupert Version: 2.4.47 OS: Darwin alice 17.7.0 Darwin Kernel Version 17.7.0: Fri Nov 2 20:43:16 PDT 2018; root:xnu-4570.71.17~1/RELEASE_X86_64 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (5.170.120.126) NOTE >make [...] duplicate symbol _ber_int_options in: /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) ../../libraries/liblber/.libs/liblber.a(options.o) duplicate symbol _ber_set_option in: /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) ../../libraries/liblber/.libs/liblber.a(options.o) duplicate symbol _ber_get_option in: /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) ../../libraries/liblber/.libs/liblber.a(options.o) ld: 3 duplicate symbols for architecture x86_64 clang-7: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [apitest] Error 1 make[2]: *** Waiting for unfinished jobs.... duplicate symbol _ber_int_options in: /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) ../../libraries/liblber/.libs/liblber.a(options.o) duplicate symbol _ber_set_option in: /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) ../../libraries/liblber/.libs/liblber.a(options.o) duplicate symbol _ber_get_option in: /opt/src/openldap-2.4.47/libraries/liblber/.libs/liblber.a(options.o) ../../libraries/liblber/.libs/liblber.a(options.o) ld: 3 duplicate symbols for architecture x86_64 clang-7: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [dntest] Error 1 make[1]: *** [all-common] Error 1 make: *** [all-common] Error 1 COMMENT Silly bug, tripping the compiler.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by ondra＠mistotebe.net 22 Jan '19

22 Jan '19

On Tue, Jan 22, 2019 at 05:49:12PM +0000, h.b.furuseth(a)usit.uio.no wrote: > On 1/21/19 7:49 PM, Ondřej Kuzník wrote: >> Except there are no locks as you know being the author of parts of >> code that deals with what I'm about to outline anyway: >> >> Whenever a cn=config op is about to be processed, a pause is requested. >> That tells worker threads to stop picking up new work and waits until >> they're all quiet. The indexing task is run by one of these worker >> threads. > > Duuh, right. I got stuck looking for what's special about the > indexing task and couldn't find it:-( I need to make it special. > > So, let tasks declare their expected speed until finish or > between pausechecks. At FAST=1 (default) and SLOW=0. > A pause only stops tasks with speed < ltp_pause. > In thread_pool_pause(), replace the WANT_PAUSE stage with > > while (++ltp_pause <= max speed) { > wait until no more tasks with speed < ltp_pause; > } > > Then fast tasks should breeze past slow ones when preparing > to pause. Until all threads have slow tasks, anyway. > > To mitigate that, we'd need to predeclare the speed when > submitting a task, and limit the number of parallel slow > tasks. pool_submit() could stash the rest in a "slow queue" > instead of submitting. But I don't want to go there yet. The problem is not that it's still scheduled when the pause is requested, scheduled tasks don't prevent a pause (and I think some of them need to be a bit more aware of that fact), but that it's been picked up by a worker thread and is running while cn=config waits for them to pause. What I was suggesting was that it could check every so often whether it might be holding up a pause and join it just like some other tasks do. But that's only a good idea if it's able to handle the changes that happen during the pause (indexes reconfigured again, the database going away, ...) as well as being able to release any locks temporarily. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 22 Jan '19

22 Jan '19

On 1/21/19 7:49 PM, Ondřej Kuzník wrote: > Except there are no locks as you know being the author of parts of > code that deals with what I'm about to outline anyway: > > Whenever a cn=config op is about to be processed, a pause is requested. > That tells worker threads to stop picking up new work and waits until > they're all quiet. The indexing task is run by one of these worker > threads. Duuh, right. I got stuck looking for what's special about the indexing task and couldn't find it:-( I need to make it special. So, let tasks declare their expected speed until finish or between pausechecks. At FAST=1 (default) and SLOW=0. A pause only stops tasks with speed < ltp_pause. In thread_pool_pause(), replace the WANT_PAUSE stage with while (++ltp_pause <= max speed) { wait until no more tasks with speed < ltp_pause; } Then fast tasks should breeze past slow ones when preparing to pause. Until all threads have slow tasks, anyway. To mitigate that, we'd need to predeclare the speed when submitting a task, and limit the number of parallel slow tasks. pool_submit() could stash the rest in a "slow queue" instead of submitting. But I don't want to go there yet.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by ondra＠mistotebe.net 21 Jan '19

21 Jan '19

On Mon, Jan 21, 2019 at 03:23:55PM +0000, h.b.furuseth(a)usit.uio.no wrote: > On 20.01.2019 19:52, Hallvard Breien Furuseth wrote: > > Can cn=config have 2 lock levels? That fixes this ITS (my > > ldapwhoami hang) without introducing cn=config failures. > > > > The outer lock serializes cn=config ops including the indexer. > > Other ops do not lock it. The inner lock blocks slapd like > > cn=config does now, and should only be held briefly. Always > > hold the outer lock when taking the inner lock. > > Correction again: while taking and holding the inner lock. > Except non-config ops. Except there are no locks as you know being the author of parts of code that deals with what I'm about to outline anyway: Whenever a cn=config op is about to be processed, a pause is requested. That tells worker threads to stop picking up new work and waits until they're all quiet. The indexing task is run by one of these worker threads. Some long-running processes (syncrepl) will regularly check to see if they should pause as well: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/s… Handling things in a similar way might be an option if we could survive anything changing in cn=config while we yield. That might be a big "if" to implement, though. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 21 Jan '19

21 Jan '19

On 20.01.2019 19:52, Hallvard Breien Furuseth wrote: > Can cn=config have 2 lock levels? That fixes this ITS (my > ldapwhoami hang) without introducing cn=config failures. > > The outer lock serializes cn=config ops including the indexer. > Other ops do not lock it. The inner lock blocks slapd like > cn=config does now, and should only be held briefly. Always > hold the outer lock when taking the inner lock. Correction again: while taking and holding the inner lock. Except non-config ops. > Also, the inner lock could be taken and released several > times during a config op when feasible. That might improve > non-config op latency, for the price of slower config ops.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 20 Jan '19

20 Jan '19

I wrote: > Limiting the problems beyond that is a bonus. Or maybe not. > A cn=config which fails in some obscure cases is flaky. (...) Correction: Obscure _situations_, not obscure cases. As in, operation X normally succeds, but can fail if you just did the somewhat-related operation Y.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 20 Jan '19

20 Jan '19

Can cn=config have 2 lock levels? That fixes this ITS (my ldapwhoami hang) without introducing cn=config failures. The outer lock serializes cn=config ops including the indexer. Other ops do not lock it. The inner lock blocks slapd like cn=config does now, and should only be held briefly. Always hold the outer lock when taking the inner lock. Also, the inner lock could be taken and released several times during a config op when feasible. That might improve non-config op latency, for the price of slower config ops. On 1/20/19 4:42 PM, Howard Chu wrote: > Hallvard Breien Furuseth wrote: >> On 1/19/19 8:04 PM, Howard Chu wrote: >>> modifications to cn=config require no other threads to be active. Once the background indexer >>> starts running, its activity will of course block further cn=config modifications until it >>> completes. >> >> Nothing "of course" about it. I don't know why running >> the background indexer is considered a change to cn=config. > > It is not. But the indexing rules can be changed by further config mods, and we > don't want the config to change out from under it. OK. I was just parsing your worlds too literally. Also, I'm trying to think like an admin, not an OpenLDAP insider: >> The ldapmodify did the change to cn=config and completed. >> >> I can guess that it might block cn=config simply because that's >> the safe way to have both an indexer and dynamic config. Or >> I can read the code. But "read the code" != "of course". > > This was all discussed on the -devel mailing list when the feature was first implemented. > http://www.openldap.org/lists/openldap-devel/200504/msg00090.html Thanks. >> So... back to start, I guess I was suggesting that the >> indexing task should stop if another config mod comes in, >> if it can resume afterwards. And the config change need >> only fail if it might prevent the indexer from resuming. >> I suppose that gets complicated in a hurry though. > > Stopping and resuming is problematic, especially if other config changes to the DB occur > that would invalidate the in-progress indexing. OK. > We could arrange to return LDAP_BUSY to config mods if any background indexers are running. > Or as I already mentioned, we could try to only do this for relevant config mods, e.g. to > the active backend, or to global schema. I'm mostly interested in the worst expected case during normal cn=config use - whether hang or error. Limiting the problems beyond that is a bonus. Or maybe not. A cn=config which fails in some obscure cases is flaky. A cn=config which fails more frequently but in predictable ways can be annoying, but is easy to figure out how to operate. I suppose a simple test is how simple the documentation can be: If I want non-config operations to not hang, what do I do and what do I avoid? And same thing if want to write a config script which won't need to cope with expected failures.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 20 Jan '19

20 Jan '19

Hallvard Breien Furuseth wrote: > On 1/19/19 8:04 PM, Howard Chu wrote: >> modifications to cn=3Dconfig require no other threads to be active. On= ce the background indexer >> starts running, its activity will of course block further cn=3Dconfig = modifications until it >> completes. >=20 > Nothing "of course" about it.=C2=A0 I don't know why running > the background indexer is considered a change to cn=3Dconfig. It is not. But the indexing rules can be changed by further config mods, = and we don't want the config to change out from under it. > The ldapmodify did the change to cn=3Dconfig and completed. >=20 > I can guess that it might block cn=3Dconfig simply because that's > the safe way to have both an indexer and dynamic config.=C2=A0 Or > I can read the code.=C2=A0 But "read the code" !=3D "of course". This was all discussed on the -devel mailing list when the feature was fi= rst implemented. http://www.openldap.org/lists/openldap-devel/200504/msg00090.html > So... back to start, I guess I was suggesting that the > indexing task should stop if another config mod comes in, > if it can resume afterwards.=C2=A0 And the config change need > only fail if it might prevent the indexer from resuming. > I suppose that gets complicated in a hurry though. Stopping and resuming is problematic, especially if other config changes = to the DB occur that would invalidate the in-progress indexing. We could arrange to return LDAP_BUSY to config mods if any background ind= exers are running. Or as I already mentioned, we could try to only do this for relevant conf= ig mods, e.g. to the active backend, or to global schema. --=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/

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 20 Jan '19

20 Jan '19

On 1/19/19 8:04 PM, Howard Chu wrote: > modifications to cn=config require no other threads to be active. Once the background indexer > starts running, its activity will of course block further cn=config modifications until it > completes. Nothing "of course" about it. I don't know why running the background indexer is considered a change to cn=config. The ldapmodify did the change to cn=config and completed. I can guess that it might block cn=config simply because that's the safe way to have both an indexer and dynamic config. Or I can read the code. But "read the code" != "of course". So... back to start, I guess I was suggesting that the indexing task should stop if another config mod comes in, if it can resume afterwards. And the config change need only fail if it might prevent the indexer from resuming. I suppose that gets complicated in a hurry though.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 20 Jan '19

20 Jan '19

On 1/20/19 5:26 AM, Howard Chu wrote: > Hallvard Breien Furuseth wrote: >> On 1/20/19 4:48 AM, Hallvard Breien Furuseth wrote: >>> On 1/20/19 2:14 AM, Howard Chu wrote: >>>> This was the safest approach, considering that a config change could alter/remove context out >>>> from under running threads otherwise. >>> >>> No, the safest approach is to fail the 2nd cn=config mod >>> unless the user says it's OK to block the server. > > How would the user say so? An LDAP control. Or the modify operation could modify an operational attribute which which doesn't exist in LDAP, it just changes the operation's behavior. Or only accept cn=config mods after the connection has added an ephemeral control entry which says how cn=config mods should behave in that connection. Maybe that's the least annoying way, since there won't be any special cases for the use to cope with. Either way, it sounds like there's no right answer for RE24's default behavior, and the only fix there would involve a config option which says which behavior to pick. (It'd be nice to be able to say things like "it's OK to hang if ldapi:// is the only listener", but I suppose then people have a hundred other conditions which would be nice too.) I don't like any of my own answers to this though. I just dislike server hangs more. >> Or fail the 1st cn=config mod too, if that's easier. > > Huh? That op has already completed. The indexer is started as a background task after > the mod op completes. I meant fail when the operation is issued, but never mind. That was silly, and cumbersome for the user to find out when he can safely issue the next operation. Either way, diagnosticMessage "RTFM: back-mdb(5) about olcDbIndex and slapd-config(5) about possible server hangs". And we should document when cn=config mods can be dangerous and how to use it safely without the users noticing. There should in any case be a method to ask the server "is cn=config very busy now, or is another cn=config mod safe?". Like failing the operation if it is not, like I said first.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 20 Jan '19

20 Jan '19

Hallvard Breien Furuseth wrote: > On 1/20/19 4:48 AM, Hallvard Breien Furuseth wrote: >> On 1/20/19 2:14 AM, Howard Chu wrote: >>> This was the safest approach, considering that a config change could alter/remove context out >>> from under running threads otherwise. >> >> No, the safest approach is to fail the 2nd cn=config mod >> unless the user says it's OK to block the server. How would the user say so? > Or fail the 1st cn=config mod too, if that's easier. Huh? That op has already completed. The indexer is started as a background task after the mod op completes. -- -- 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#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 20 Jan '19

20 Jan '19

On 1/20/19 4:48 AM, Hallvard Breien Furuseth wrote: > On 1/20/19 2:14 AM, Howard Chu wrote: >> This was the safest approach, considering that a config change could >> alter/remove context out >> from under running threads otherwise. > > No, the safest approach is to fail the 2nd cn=config mod > unless the user says it's OK to block the server. Or fail the 1st cn=config mod too, if that's easier.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by h.b.furuseth＠usit.uio.no 20 Jan '19

20 Jan '19

On 1/20/19 2:14 AM, Howard Chu wrote: > Ah, the 2nd cn=config mod has requested a pause, which can't succeed until all > background threads complete. And no new threads will be run while a pause is being requested. Exactly. > This was the safest approach, considering that a config change could alter/remove context out > from under running threads otherwise. No, the safest approach is to fail the 2nd cn=config mod unless the user says it's OK to block the server.

1 0

Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index
by hyc＠symas.com 20 Jan '19

20 Jan '19

Hallvard Breien Furuseth wrote: > On 1/19/19 9:55 PM, h.b.furuseth(a)usit.uio.no wrote: >> 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. > > That is, the 2nd mod to cn=config blocks, and that's fine by me, except > _then_ the server is hung. Ah, the 2nd cn=config mod has requested a pause, which can't succeed until all background threads complete. And no new threads will be run while a pause is being requested. This was the safest approach, considering that a config change could alter/remove context out from under running threads otherwise. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs