(ITS#8841) Fix for an assertion error in back-meta
by nivanova＠symas.com
Full_Name: Nadezhda Ivanova
Version: 2.5
OS:
URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425-2.patch
Submission from: (NULL) (93.152.134.25)
This patch contains a fix for the following issue, reported by a customer.
When using back-meta, if a network interface towards a target becomes
unavailable (e.g disabling a virtual interface), back-meta fails an assert.
IPR for this patch:
The attached files are derived from OpenLDAP Software. All of the modifications
to OpenLDAP Software represented in the following patch were developed by Symas
Corporation. Symas Corporation has not assigned rights and/or interest in this
work to any party.
I, Nadezhda Ivanova, am authorized by Symas Corporation, my
employer, to release this work under the following terms.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2018 Symas Corporation
Redistribution and use in source and binary forms, with or without
modification,
are permitted only as authorized by the OpenLDAP Public License.
5 years, 7 months
(ITS#8725) Disable cleanup of extended operations if they are asynchronous
by nivanova＠symas.com
--=_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--
5 years, 7 months
Re: (ITS#6300) Issues with kqueue after fork
by quanah＠symas.com
--==========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==========--
5 years, 7 months
Re: (ITS#8840) domainScope control is not properly implemented
by quanah＠symas.com
--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>
5 years, 7 months
Re: (ITS#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch
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
5 years, 7 months
Re: (ITS#8838) TLS cert for www.openldap.org expired
by hyc＠symas.com
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/
5 years, 7 months
(ITS#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch
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
(...)
5 years, 7 months
