openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#8725) Disable cleanup of extended operations if they are asynchronous
by nivanova＠symas.com 25 Apr '18

25 Apr '18

--=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch --=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br data-mce-bogus="1"></div><div>As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></body></html> --=_ff296a31-6740-4409-806d-173ea531b121--

1 0

Re: (ITS#6300) Issues with kqueue after fork
by quanah＠symas.com 24 Apr '18

24 Apr '18

--==========C0CB1C4A269A2DB8FD87========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li To: Quanah Gibson-Mount Hi Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========C0CB1C4A269A2DB8FD87========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD (fwd)" Date: Tue, 24 Apr 2018 14:28:57 -0700 From: Quanah Gibson-Mount <quanah(a)symas.com> Reply-To: Quanah Gibson-Mount <quanah(a)symas.com> To: Howard Chu <hyc(a)symas.com> Subject: Re: kqueue in OpenLDAP for FreeBSD (fwd) Message-ID: <49431EE1A7D095C608D778A4(a)[192.168.1.10]> X-Mailer: Mulberry/4.0.9a1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========EF6328C82A1CE901E152==========" --==========EF6328C82A1CE901E152========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline kqueue issues with slapd --Quanah ------------ Forwarded Message ------------ Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI=20 <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd = to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q > > > I've updated my configure to: > > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl = --disable-dependency-tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q > > > And I still have no issues.=C2=A0 I'm unable to get the freebsd version = of > libtool to build shared libraries, so I can't test dynamic modules. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========EF6328C82A1CE901E152========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD" Return-Path: delphij(a)delphij.net Received: from 127.37.197.104.bc.googleusercontent.com (LHLO zmcc-5-mta-1.zmailcloud.com) (104.197.37.127) by zmcc-5-mailbox-1.zmailcloud.com with LMTP; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 57E10C0814 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Authentication-Results: zmcc-5-mta-1.zmailcloud.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=delphij.net Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrlpf0yr3bg2 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (254.215.154.104.bc.googleusercontent.com [104.154.215.254]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 36497C06D2 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (localhost.localdomain [127.0.0.1]) by mailstronghold-1.zmailcloud.com (8.13.8/8.13.8) with ESMTP id v9N4CeHI010656 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:18 -0500 X-Haraka-RcptSummary: valid=1 invalid=0 unverified=0 relay=0 norelay=0 Received-SPF: Pass (mailstronghold-1.zmailcloud.com: domain of delphij.net designates 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=mailfrom; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received-SPF: None (mailstronghold-1.zmailcloud.com: domain of anubis.delphij.net does not designate 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=helo; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mailstronghold-1.zmailcloud.com (Haraka/2.2.8) with ESMTPS id 44429DF9-9A11-41FD-AF40-A85A1E9CCAE7.1 envelope-from <delphij(a)delphij.net> (version=TLSv1/SSLv3 cipher=AES256-SHA verify=OK); Mon, 23 Oct 2017 01:43:14 -0500 Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:37a:c09f:c4b5:916b:f99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 7315321847; Sun, 22 Oct 2017 23:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1508740990; x=1508755390; bh=lHOLEU7RrRbdsqZiIrERFdjtGcmjK0d4J65y4NciNAE=; h=Cc:Subject:To:References:From:Date:In-Reply-To; b=pSf21voW+1hi95e1Gk7n0Etfo4WpoqUlF4m7Ukgp6+Sw1OreGQEjQPiBMq0Wo6htG P/+uPZswNtPxpr/6yGE9Fsrxku8Bygk6Qv/o3pR9rRe0bKhvrh+jqAcM0KvcjgG9cV geciuENhFuihiQm9Jh/4383kqyrcrgnufON8XY4Q= Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> From: Xin Li <delphij(a)delphij.net> Date: Sun, 22 Oct 2017 23:43:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ" X-Haraka-Syntax: mail_case=upper mail_leading_spaces=N mail_trailing_spaces=N mail_missing_brackets=N rcpt_case=upper rcpt_leading_spaces=N rcpt_missing_brackets=N rcpt_trailing_spaces=N X-Haraka-GeoIP: US X-Haraka-GeoIP-Received: 64.62.153.212:US X-Haraka-rDNS: anubis.delphij.net X-Haraka-FCrDNS: anubis.delphij.net X-Haraka-HostID: delphij.net X-Haraka-SenderAuth: 64.62.153.212 delphij.net X-Haraka-Domain-Info: domain="delphij.net" last_update=176 primary_ns="ns-us.delphij.net" serial=2017043060 refresh=7200 retry=3600 expiration=604800 minimum=14400 flags="" X-Haraka-Watermark: references:WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com References: <1EEAC653239F6692643DB632(a)192.168.1.30> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Message-Id: <WM!ff18dbc4fd0ca98069f4da171165aabfe0351a19a07c5c098b191f5850c1c079bf8b820779722c14189597ab2ab2028a!(a)mailstronghold-1.zmailcloud.com> X-FSL-MailScanner-Information: Please contact postmaster(a)zmailcloud.com for more information X-FSL-MailScanner-ID: v9N4CeHI010656 X-FSL-MailScanner: Found to be clean X-Dirty-Status: X-FSL-MailScanner-From: delphij(a)delphij.net This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: multipart/mixed; boundary="SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl"; protected-headers="v1" From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Message-ID: <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Subject: Re: kqueue in OpenLDAP for FreeBSD References: <1EEAC653239F6692643DB632(a)192.168.1.30> <WM!652ba1f610b07a3646a24508aa83d70e7fbfbbbf4a02ab2f4f5c75bea4ea7433084f5a08cbd2551d01ebcc1be8bfada2!(a)mailstronghold-3.zmailcloud.com> <806290B685E4C0A58E186335(a)192.168.1.30> <a77bd491-68e1-d071-90d1-f081685137cd(a)delphij.net> <WM!9301149f169acc8af0f3fbefd6be96ab8874fd401aaf6373e9390d058b5fc3a788bd3202b6db71ad2dcfda2aec5e5b59!(a)mailstronghold-3.zmailcloud.com> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl Content-Type: multipart/mixed; boundary="------------617F49AD045D5D9CF20DDEA9" Content-Language: en-US This is a multi-part message in MIME format. --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's= descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, et= c. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: >=20 >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd= to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q >=20 >=20 > I've updated my configure to: >=20 > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl --disable-dependency-= tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q >=20 >=20 > And I still have no issues.=C2=A0 I'm unable to get the freebsd version= of > libtool to build shared libraries, so I can't test dynamic modules. >=20 > --Quanah >=20 >=20 > --=20 >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >=20 --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="slapd-workaround.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd-workaround.patch" ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvbWFpbi5jIGIvc2VydmVycy9zbGFwZC9tYWlu LmMKaW5kZXggMGEwNTNjM2VlLi4xOGQ4NDBjNWEgMTAwNjQ0Ci0tLSBhL3NlcnZlcnMvc2xh cGQvbWFpbi5jCisrKyBiL3NlcnZlcnMvc2xhcGQvbWFpbi5jCkBAIC02OTIsNiArNjkyLDkg QEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJYmVyX3NldF9vcHRpb24oTlVMTCwgTEJFUl9PUFRf REVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGFwX3NldF9vcHRpb24oTlVMTCwgTERB UF9PUFRfREVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGlmX2RlYnVnID0gc2xhcF9k ZWJ1ZzsKKwlpZiAoIGNoZWNrICE9IENIRUNLX05PTkUgKSB7CisJCW5vX2RldGFjaCA9IDE7 CisJfQogCiAJaWYgKCB2ZXJzaW9uICkgewogCQlmcHJpbnRmKCBzdGRlcnIsICIlc1xuIiwg VmVyc2lvbnN0ciApOwpAQCAtNzM5LDYgKzc0MiwyOSBAQCB1bmhhbmRsZWRfb3B0aW9uOjsK IAlnbG9iYWxfaG9zdCA9IGxkYXBfcHZ0X2dldF9mcWRuKCBOVUxMICk7CiAJYmVyX3N0cjJi diggZ2xvYmFsX2hvc3QsIDAsIDAsICZnbG9iYWxfaG9zdF9idiApOwogCisjaWZuZGVmIEhB VkVfV0lOU09DSworCWlmICggIW5vX2RldGFjaCApIHsKKwkJaWYgKCBsdXRpbF9wYWlyKCB3 YWl0ZmRzICkgPCAwICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQkJCSJtYWlu OiBsdXRpbF9wYWlyIGZhaWxlZDogJWRcbiIsCisJCQkJMCwgMCwgMCApOworCQkJcmMgPSAx OworCQkJZ290byBkZXN0cm95OworCQl9CisJCXBpZCA9IGx1dGlsX2RldGFjaCggbm9fZGV0 YWNoLCAwICk7CisJCWlmICggcGlkICkgeworCQkJY2hhciBidWZbNF07CisJCQlyYyA9IEVY SVRfU1VDQ0VTUzsKKwkJCWNsb3NlKCB3YWl0ZmRzWzFdICk7CisJCQlpZiAoIHJlYWQoIHdh aXRmZHNbMF0sIGJ1ZiwgMSApICE9IDEgKQorCQkJCXJjID0gRVhJVF9GQUlMVVJFOworCQkJ X2V4aXQoIHJjICk7CisJCX0gZWxzZSB7CisJCQljbG9zZSggd2FpdGZkc1swXSApOworCQl9 CisJfQorI2VuZGlmIC8qIEhBVkVfV0lOU09DSyAqLworCiAJaWYoIGNoZWNrID09IENIRUNL X05PTkUgJiYgc2xhcGRfZGFlbW9uX2luaXQoIHVybHMgKSAhPSAwICkgewogCQlyYyA9IDE7 CiAJCVNFUlZJQ0VfRVhJVCggRVJST1JfU0VSVklDRV9TUEVDSUZJQ19FUlJPUiwgMTYgKTsK QEAgLTkxMSwyOSArOTM3LDYgQEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJKHZvaWQpIFNJR05B TCggU0lHQlJFQUssIHNsYXBfc2lnX3NodXRkb3duICk7CiAjZW5kaWYKIAotI2lmbmRlZiBI QVZFX1dJTlNPQ0sKLQlpZiAoICFub19kZXRhY2ggKSB7Ci0JCWlmICggbHV0aWxfcGFpcigg d2FpdGZkcyApIDwgMCApIHsKLQkJCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKLQkJCQkibWFp bjogbHV0aWxfcGFpciBmYWlsZWQ6ICVkXG4iLAotCQkJCTAsIDAsIDAgKTsKLQkJCXJjID0g MTsKLQkJCWdvdG8gZGVzdHJveTsKLQkJfQotCQlwaWQgPSBsdXRpbF9kZXRhY2goIG5vX2Rl dGFjaCwgMCApOwotCQlpZiAoIHBpZCApIHsKLQkJCWNoYXIgYnVmWzRdOwotCQkJcmMgPSBF WElUX1NVQ0NFU1M7Ci0JCQljbG9zZSggd2FpdGZkc1sxXSApOwotCQkJaWYgKCByZWFkKCB3 YWl0ZmRzWzBdLCBidWYsIDEgKSAhPSAxICkKLQkJCQlyYyA9IEVYSVRfRkFJTFVSRTsKLQkJ CV9leGl0KCByYyApOwotCQl9IGVsc2UgewotCQkJY2xvc2UoIHdhaXRmZHNbMF0gKTsKLQkJ fQotCX0KLSNlbmRpZiAvKiBIQVZFX1dJTlNPQ0sgKi8KLQogI2lmZGVmIENTUklNQUxMT0MK IAltYWxfbGVha3RyYWNlKDEpOwogI2VuZGlmCg== --------------617F49AD045D5D9CF20DDEA9-- --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl-- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ7Y99AAoJEJW2GBstM+nstpMP/0zXWEdlSWycZyYU8ukkLUju Bd+3oVJyhwuVFhVHp4mts+nApF6+yPzMTlhT930cyD+LJ5TLrfaR9bVoVkix0LMk YX7KF7jHWZU/B7+o4VR1l/oMFoRr4qSXQ+hiFgiDZg+id8s9CxnndzmbWK+vgRSp j2ynuh7aQbLBkkao8mfHG/UbDvTvre8BVw9WF/vidwieDGOITo28088ZbX8XgjTO 9e7WFw+ftnFKkv63o/GDOCo+1zFm7n+F7gv4DmZYrt3ZdHCcSRkHMXPltf/4/IRX pFve1h24mPsq0sqit1wsDj2k3f3cJRN4rEShIBfiZm1y4rmCFC8ogDyllBdEbqRd RoN2ol6nh2k38qR4WAHhMFRyCUgUnqYevC7L+AlUAXiweSgzUKfVZt0bpiVnZPDT NiuAX1fBBQIySWzF/iM4d3VPIZdPmcme72kRCLcpbViTW+u4/n+RJEdKl4QRSSrw 5DzVwZDLgl16Ch+YLUYoaSyyk8strbe62owDf6GOb4Pnwy3wBf5o1oIsn/tcu6mh JA2IIVQ9mS3rwDgnL9O7GxrAmWFgpzZmBEC9mYbOToW4EMzDMBj4M7cwrLAVpae7 8KDX5xWX8swr56W8/8PQayLf574lPBhx9QZorKnoIzycHXCI/NkXbW9NBJTr/LLk 0etBpNlk83eCTvtejbbR =dl/v -----END PGP SIGNATURE----- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ-- --==========EF6328C82A1CE901E152==========-- --==========C0CB1C4A269A2DB8FD87==========--

1 0

Re: (ITS#8840) domainScope control is not properly implemented
by quanah＠symas.com 23 Apr '18

23 Apr '18

--On Friday, April 20, 2018 3:28 PM +0000 elecharny(a)symas.com wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.45 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.123.98.139) > > > There has been a change back in 2011 in the controls.c code : > > https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd3 > 556f941a#diff-8237ff8d4da3d46fed54a93482b3a908 This is not a valid link, as it points to a private repository. In the future, please provide a valid reference. The commit at issue is: commit f810e6ed417939ed69b388ad7fb0c696e185f593 Author: Kurt Zeilenga <kurt(a)openldap.org> Date: Fri Apr 20 22:32:58 2007 +0000 Distinguish absent control value from empty control value. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8840) domainScope control is not properly implemented
by elecharny＠symas.com 20 Apr '18

20 Apr '18

Full_Name: Emmanuel Lecharny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.123.98.139) There has been a change back in 2011 in the controls.c code : https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd355… Line 1460 was : if ( ctrl->ldctl_value.bv_len ) { and was transformed to line 1516 : if ( BER_BVISNULL( &ctrl->ldctl_value )) { when it was expected to be : if ( !BER_BVISNULL( &ctrl->ldctl_value )) { as this control is not expecting any value. The consequence is that using this control in ldapsearch leads to an error being generated : "domainScope control value not empty"

1 0

Re: (ITS#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch 18 Apr '18

18 Apr '18

Ok, thanks for your prompt action=2E I confirm it's fixed ;) On April 18, 2018 9:52:08 PM GMT+09:00, Howard Chu <hyc@symas=2Ecom> wrote= : >arekkusu@r42=2Ech wrote: >> Full_Name: Alexandre Rosenberg >> Version: - >> OS: - >> URL: ftp://ftp=2Eopenldap=2Eorg/incoming/ >> Submission from: (NULL) (125=2E30=2E28=2E204) >>=20 >>=20 >> Hello, >>=20 >> TLS certificate for CN=3Dwww=2Eopenldap=2Eorg and many alternative subj= ect >name has >> expired=2E (April 17, 2018, 5:01:56 PM GMT) >>=20 >> I noticed you are using Let's Encrypt=2E I suggest setting up some sort >of >> reminder and/or automated renewal=2E > >Yes, the cron job for auto renewal failed=2E It's updated now=2E >>=20 >> Best, >> Alex >>=20 >> ------------- >>=20 >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: >> 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C =3D US, O =3D Let's Encrypt, CN =3D Let's Encrypt >Authority X3 >> Validity >> Not Before: Jan 17 17:01:56 2018 GMT >> Not After : Apr 17 17:01:56 2018 GMT >> Subject: CN =3D www=2Eopenldap=2Eorg >> (=2E=2E=2E) >> =20 >>=20 >>=20

1 0

(ITS#8839) never use md5 and/or sha1, use sha512, file signing
by openldap＠openldap.org 18 Apr '18

18 Apr '18

Full_Name: openldap user Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.87.231.80) use a 4096-bit rsa key for signing the release files

1 0

Re: (ITS#8838) TLS cert for www.openldap.org expired
by hyc＠symas.com 18 Apr '18

18 Apr '18

arekkusu(a)r42.ch wrote: > Full_Name: Alexandre Rosenberg > Version: - > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (125.30.28.204) > > > Hello, > > TLS certificate for CN=www.openldap.org and many alternative subject name has > expired. (April 17, 2018, 5:01:56 PM GMT) > > I noticed you are using Let's Encrypt. I suggest setting up some sort of > reminder and/or automated renewal. Yes, the cron job for auto renewal failed. It's updated now. > > Best, > Alex > > ------------- > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 > Signature Algorithm: sha256WithRSAEncryption > Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 > Validity > Not Before: Jan 17 17:01:56 2018 GMT > Not After : Apr 17 17:01:56 2018 GMT > Subject: CN = www.openldap.org > (...) > > > -- -- 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#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch 18 Apr '18

18 Apr '18

Full_Name: Alexandre Rosenberg Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.30.28.204) Hello, TLS certificate for CN=www.openldap.org and many alternative subject name has expired. (April 17, 2018, 5:01:56 PM GMT) I noticed you are using Let's Encrypt. I suggest setting up some sort of reminder and/or automated renewal. Best, Alex ------------- Certificate: Data: Version: 3 (0x2) Serial Number: 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Validity Not Before: Jan 17 17:01:56 2018 GMT Not After : Apr 17 17:01:56 2018 GMT Subject: CN = www.openldap.org (...)

1 0

(ITS#8837) fix pw-pbkdf2 man-mage name to get it installed
by peter＠adpm.de 13 Apr '18

13 Apr '18

Full_Name: Peter Marschall Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (217.249.216.145) Hi, although pw-pbkdf2 is not an overlay but a mere module, the existing man page for this module is named slapo-pw-pbkdf2.5. On the other hand, pw-pbkdf2's Makefile correctly mentions the manual page as slapd-pw-pbkdf2.5. Together this results in pw-pbpkdf2's manual page not getting installed despite being available. To fix the issue, please rename contrib/slapd-modules/passwd/pbkdf2/slapo-pw-pbkdf2.5 to contrib/slapd-modules/passwd/pbkdf2/slapd-pw-pbkdf2.5 Thanks in advance Peter

1 0

(ITS#8836) include TOTP into future releases
by peter＠adpm.de 13 Apr '18

13 Apr '18

Full_Name: Peter Marschall Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (217.249.216.145) Hi, although contrib/slapd-modules/passwd/totp/ is part of OpenLDAP's git repository, it is not published as part of recent OpenLDAP releases. Please include contrib/slapd-modules/passwd/totp/ and its contents into future releases of OpenLDAP. Thanks in advance Peter

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs