Re: (ITS#8304) LMDB mdb_del data loss in a cursor
by hyc＠symas.com
malyn(a)strangeGizmo.com wrote:
> Full_Name: Michael Alyn Miller
> Version: Git head
> OS: Windows 8.1 x64, NixOS 14.12 x64
> URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151109.c
> Submission from: (NULL) (71.119.103.68)
>
>
> I have a new repro of an ITS#8264 and ITS#8299-like situation, but with
> different input data.
>
> The referenced test runs twice: once with mdb_cursor_del and once with mdb_del.
>
> Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts
> the
> database. In this case, mdb_del incorrectly removes one extra key (a key
> prefixed with 03000000000000003a...).
Thanks. Fixed in git. This appears to have been broken by commit
d9423e13f85bac7c33083a4b872c022d18a41232
> On a related note, I have switched to mdb_cursor_del whenever possible, but
> there are a couple of situations where clients of my library only have the key
> during a scan and so must use mdb_del instead of mdb_cursor_del. Just letting
> you know that I took your advice from earlier, but must still use mdb_del here
> and there.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 10 months
(ITS#8304) LMDB mdb_del data loss in a cursor
by malyn＠strangeGizmo.com
Full_Name: Michael Alyn Miller
Version: Git head
OS: Windows 8.1 x64, NixOS 14.12 x64
URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151109.c
Submission from: (NULL) (71.119.103.68)
I have a new repro of an ITS#8264 and ITS#8299-like situation, but with
different input data.
The referenced test runs twice: once with mdb_cursor_del and once with mdb_del.
Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts
the
database. In this case, mdb_del incorrectly removes one extra key (a key
prefixed with 03000000000000003a...).
On a related note, I have switched to mdb_cursor_del whenever possible, but
there are a couple of situations where clients of my library only have the key
during a scan and so must use mdb_del instead of mdb_cursor_del. Just letting
you know that I took your advice from earlier, but must still use mdb_del here
and there.
7 years, 10 months
Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com
Michael Alyn Miller wrote:
>>>> Another issue similar to ITS#8264 and ITS#8299, but this time using
>>>> mdb_cursor_del inside of the cursor causes corruption. mdb_del
>>>> causes corruption as well, but this is the first time that I have
>>>> seen mdb_cursor_del do the wrong thing.
>>>>
>>>> In this case, mdb_cursor_del incorrectly removes one extra key (a key
>>>> prefixed with 0c000000000000003a...) in addition to correctly
>>>> removing all of the keys that begin with 0d000000000000003a.
>>>>
>>>> mdb_del does not remove that extra key, but instead fails to remove
>>>> two 0d000000000000003a keys that should have been removed.
>>>>
>>>> I am not sure if these are two different bugs or if they are caused
>>>> by the same underlying issue.
>>>
>>> Similar reason, two different mistakes. Fixed now in git.
>>>>
>>>> mdb_cursor_del performs correctly on subsequent runs if you do *not*
>>>> remove the database between tests, whereas mdb_del continues to fail,
>>>> but stabilizes on a different set of results after the first run.
>>
>> For future reference, here's a patch to your test program that also checks for
>> cursors pointed adjacent to the item being deleted. The previous fix was
>> missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG
>> for the mdb_cursor_chk() function to be defined.
>
> Just to confirm, are you saying that this is something that I should
> include
only in the test harness, or should these checks be in my actual library as well?
That was primarily a note for *myself* or anyone who may need to research this
issue in the future. Building LMDB with -DMDB_DEBUG is something that we only
do for test/debug efforts, not something that any user code should ever worry
about.
So no, I was not saying there was any particular action you should take.
Merely an FYI on how I verified the fix.
> Thank you for taking the time to work through these bugs and address all
> of
the various edge cases. I really appreciate the help.
I stand behind my code.
> Michael Alyn Miller
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 10 months
RE: (ITS#8300) LMDB mdb_cursor_del data loss
by malyn＠strangegizmo.com
> >> Another issue similar to ITS#8264 and ITS#8299, but this time using
> >> mdb_cursor_del inside of the cursor causes corruption. mdb_del
> >> causes corruption as well, but this is the first time that I have
> >> seen mdb_cursor_del do the wrong thing.
> >>
> >> In this case, mdb_cursor_del incorrectly removes one extra key (a key
> >> prefixed with 0c000000000000003a...) in addition to correctly
> >> removing all of the keys that begin with 0d000000000000003a.
> >>
> >> mdb_del does not remove that extra key, but instead fails to remove
> >> two 0d000000000000003a keys that should have been removed.
> >>
> >> I am not sure if these are two different bugs or if they are caused
> >> by the same underlying issue.
> >
> > Similar reason, two different mistakes. Fixed now in git.
> >>
> >> mdb_cursor_del performs correctly on subsequent runs if you do *not*
> >> remove the database between tests, whereas mdb_del continues to fail,
> >> but stabilizes on a different set of results after the first run.
>=20
> For future reference, here's a patch to your test program that also check=
s for
> cursors pointed adjacent to the item being deleted. The previous fix was
> missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG
> for the mdb_cursor_chk() function to be defined.
Just to confirm, are you saying that this is something that I should includ=
e only in the test harness, or should these checks be in my actual library =
as well?
Thank you for taking the time to work through these bugs and address all of=
the various edge cases. I really appreciate the help.
Michael Alyn Miller
7 years, 10 months
Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com
This is a multi-part message in MIME format.
--------------090509040809000501070508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Howard Chu wrote:
> malyn(a)strangeGizmo.com wrote:
>> Full_Name: Michael Alyn Miller
>> Version: Git head
>> OS: Windows 8.1 x64, NixOS 14.12 x64
>> URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151104.c
>> Submission from: (NULL) (96.251.78.237)
>>
>>
>> Another issue similar to ITS#8264 and ITS#8299, but this time using
>> mdb_cursor_del inside of the cursor causes corruption. mdb_del causes
>> corruption as well, but this is the first time that I have seen mdb_cursor_del
>> do the wrong thing.
>>
>> In this case, mdb_cursor_del incorrectly removes one extra key (a key
>> prefixed with 0c000000000000003a...) in addition to correctly removing all of
>> the keys that begin with 0d000000000000003a.
>>
>> mdb_del does not remove that extra key, but instead fails to remove two
>> 0d000000000000003a keys that should have been removed.
>>
>> I am not sure if these are two different bugs or if they are caused by the same
>> underlying issue.
>
> Similar reason, two different mistakes. Fixed now in git.
>>
>> mdb_cursor_del performs correctly on subsequent runs if you do *not* remove the
>> database between tests, whereas mdb_del continues to fail, but stabilizes on a
>> different set of results after the first run.
For future reference, here's a patch to your test program that also checks for
cursors pointed adjacent to the item being deleted. The previous fix was
missing a step, fixed now. Note you must build LMDB with -DMDB_DEBUG for the
mdb_cursor_chk() function to be defined.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--------------090509040809000501070508
Content-Type: text/plain; charset=UTF-8;
name="dif.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="dif.txt"
--- /tmp/michaelalynmiller-151104.c 2015-11-06 10:38:44.772490173 +0000
+++ michaelalynmiller-151104.c 2015-11-06 10:18:13.000000000 +0000
@@ -3696,10 +3696,10 @@
void remove_collection12(MDB_env *env, MDB_dbi dbi, int delete_with_cursor)
{
- int rc;
+ int i, rc;
MDB_txn *txn;
MDB_val key, data;
- MDB_cursor *cursor;
+ MDB_cursor *cursor, *cup, *cdn;
E(mdb_txn_begin(env, NULL, 0, &txn));
@@ -3710,6 +3710,8 @@
E(mdb_del(txn, dbi, &key, &data));
E(mdb_cursor_open(txn, dbi, &cursor));
+ E(mdb_cursor_open(txn, dbi, &cup));
+ E(mdb_cursor_open(txn, dbi, &cdn));
key.mv_size = 8+1;
key.mv_data = "\x0D\x00\x00\x00\x00\x00\x00\x00:";
@@ -3717,13 +3719,19 @@
data.mv_data = NULL;
E(mdb_cursor_get(cursor, &key, &data, MDB_SET_RANGE));
- for (;;) {
+ for (i=0;;i++) {
data.mv_size = 8+1;
data.mv_data = "\x0D\x00\x00\x00\x00\x00\x00\x00;";
if (mdb_cmp(txn, dbi, &data, &key) < 0) {
break;
}
+ E(mdb_cursor_get(cup, &key, &data, MDB_SET));
+ E(mdb_cursor_get(cdn, &key, &data, MDB_SET));
+ mdb_cursor_get(cup, NULL, NULL, MDB_NEXT);
+ mdb_cursor_get(cdn, NULL, NULL, MDB_PREV);
+
+ printf("Deleting %d\n", i);
if (delete_with_cursor) {
E(mdb_cursor_del(cursor, 0));
} else {
@@ -3731,6 +3739,9 @@
data.mv_data = NULL;
E(mdb_del(txn, dbi, &key, &data));
}
+ mdb_cursor_chk(cursor);
+ mdb_cursor_chk(cup);
+ mdb_cursor_chk(cdn);
rc = mdb_cursor_get(cursor, &key, &data, MDB_NEXT);
if (rc == MDB_NOTFOUND) {
--------------090509040809000501070508--
7 years, 10 months
Re: Re: (ITS#8302) The chain-tls failure
by benhuang＠icil.net
This is a multi-part message in MIME format.
------=_001_NextPart715611200672_=----
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: base64
RGVhciBRdWFuYWgsDQoNClRoYW5rcyBmb3IgeW91ciByZXBseSwgSSdsbCBjb250YWN0IHdpdGgg
b3BlbmxkYXAtdGVjaG5pY2FsQG9wZW5sZGFwLm9yZyB0byBmaXggdGhpcyBpc3N1ZS4NCg0KDQoN
Cg0KVGhhbmtzICYgQmVzdCBSZWdhcmRzIA0KQmVuIEh1YW5nL0lDSUxTWlggDQo4Ni0wNzU1LTg4
Mjg1MzcwLWV4dDExMTYuDQogDQpGcm9tOiBRdWFuYWggR2lic29uLU1vdW50DQpEYXRlOiAyMDE1
LTExLTA2IDAxOjQxDQpUbzogYmVuaHVhbmc7IG9wZW5sZGFwLWl0cw0KU3ViamVjdDogUmU6IChJ
VFMjODMwMikgVGhlIGNoYWluLXRscyBmYWlsdXJlDQotLU9uIFRodXJzZGF5LCBOb3ZlbWJlciAw
NSwgMjAxNSAxMToyNyBBTSArMDAwMCBiZW5odWFuZ0BpY2lsLm5ldCB3cm90ZToNCiANCj4gRnVs
bF9OYW1lOiBCZW4gSHVhbmcNCj4gVmVyc2lvbjogMi40LjM3DQo+IE9TOiBVYnVudHUgMTIuMDQu
NCBMVFMNCj4gVVJMOiBmdHA6Ly9mdHAub3BlbmxkYXAub3JnL2luY29taW5nLw0KPiBTdWJtaXNz
aW9uIGZyb206IChOVUxMKSAoMjAyLjEzMC44Ni4xMzApDQogDQpQbGVhc2UgdXNlIGEgY3VycmVu
dCByZWxlYXNlLiAgVXNhZ2UgcXVlc3Rpb25zIHN1Y2ggYXMgeW91cnMgc2hvdWxkIGFsc28gYmUg
DQpkaXJlY3RlZCB0byBvcGVubGRhcC10ZWNobmljYWxAb3BlbmxkYXAub3JnIHJhdGhlciB0aGFu
IHRoZSBJVFMgc3lzdGVtLCANCndoaWNoIGlzIGZvciBidWcgcmVwb3J0cyBhZ2FpbnN0IGN1cnJl
bnQgY29kZS4NCiANClRoaXMgSVRTIHdpbGwgYmUgY2xvc2VkLg0KIA0KVGhhbmtzLA0KUXVhbmFo
DQogDQogDQotLQ0KIA0KUXVhbmFoIEdpYnNvbi1Nb3VudA0KUmVsZWFzZSBhbmQgUUEgRW5naW5l
ZXINCjxodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZz4NCg==
------=_001_NextPart715611200672_=----
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse=
t=3DISO-8859-1"><style>body { line-height: 1.5; }blockquote { margin-top: =
0px; margin-bottom: 0px; margin-left: 0.5em; }body { font-size: 12pt; font=
-family: Calibri; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><=
body>=0A<div><span></span>Dear <span style=3D"font-size: 12pt; line-h=
eight: 1.5; background-color: window;">Quanah,</span></div><div><span styl=
e=3D"font-size: 12pt; line-height: 1.5; background-color: window;"><br></s=
pan></div><div>Thanks for your reply, I'll contact with <span style=
=3D"font-size: 12pt; line-height: 1.5; background-color: window;"></span><=
a href=3D"mailto:openldap-technical@openldap.org" style=3D"font-size: 12pt=
; line-height: 1.5; background-color: window;">openldap-technical@openldap=
.org</a><span style=3D"font-size: 12pt; line-height: 1.5; background-color=
: window;"> to fix this issue.</span></div>=0A<div><br></div><hr styl=
e=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align=3D"lef=
t">=0A<div><span><div><span segoe=3D"" ui'";=3D"" font-size:=3D"" 14px;=3D=
"" color:=3D"" rgb(0,=3D"" 0,=3D"" 0);=3D"" background-color:=3D"" rgba(0,=
=3D"" font-weight:=3D"" normal;=3D"" font-style:=3D"" normal;text-decorati=
on:=3D"" none;'=3D""><b><font face=3D"Calibri Light"><br></font></b></span=
></div><span segoe=3D"" ui'";=3D"" font-size:=3D"" 14px;=3D"" color:=3D"" =
rgb(0,=3D"" 0,=3D"" 0);=3D"" background-color:=3D"" rgba(0,=3D"" font-weig=
ht:=3D"" normal;=3D"" font-style:=3D"" normal;text-decoration:=3D"" none;'=
=3D""><b><div><b style=3D"font-size: 12pt; line-height: 1.5; background-co=
lor: window;"><font>Thanks & Best Regards </font></b></div>Ben Hu=
ang/ICILSZX=0A<br>86-0755-88285370-ext1116.</b></span></span></div>=0A<blo=
ckquote style=3D"margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em;"=
><div> </div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt=
;padding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT: 8px; PADDING-LEFT=
: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efef=
ef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>From:</b> <a href=
=3D"mailto:quanah@openldap.org">Quanah Gibson-Mount</a></div><div><b>Date:=
</b> 2015-11-06 01:41</div><div><b>To:</b> <a href=3D"mailt=
o:benhuang@icil.net">benhuang</a>; <a href=3D"mailto:openldap-its@openldap=
.org">openldap-its</a></div><div><b>Subject:</b> Re: (ITS#8302) The c=
hain-tls failure</div></div></div><div><div>--On Thursday, November 05, 20=
15 11:27 AM +0000 benhuang(a)icil.net wrote:</div>=0A<div> </div>=0A<di=
v>> Full_Name: Ben Huang</div>=0A<div>> Version: 2.4.37</div>=0A<div=
>> OS: Ubuntu 12.04.4 LTS</div>=0A<div>> URL: ftp://ftp.openldap.org=
/incoming/</div>=0A<div>> Submission from: (NULL) (202.130.86.130)</div=
>=0A<div> </div>=0A<div>Please use a current release. Usage que=
stions such as yours should also be </div>=0A<div>directed to openldap-tec=
hnical(a)openldap.org rather than the ITS system, </div>=0A<div>which is for=
bug reports against current code.</div>=0A<div> </div>=0A<div>This I=
TS will be closed.</div>=0A<div> </div>=0A<div>Thanks,</div>=0A<div>Q=
uanah</div>=0A<div> </div>=0A<div> </div>=0A<div>--</div>=0A<div=
> </div>=0A<div>Quanah Gibson-Mount</div>=0A<div>Release and QA Engin=
eer</div>=0A<div><http://www.openldap.org></div>=0A</div></blockquot=
e>=0A</body></html>
------=_001_NextPart715611200672_=------
7 years, 10 months
Re: (ITS#8302) The chain-tls failure
by quanah＠openldap.org
--On Thursday, November 05, 2015 11:27 AM +0000 benhuang(a)icil.net wrote:
> Full_Name: Ben Huang
> Version: 2.4.37
> OS: Ubuntu 12.04.4 LTS
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (202.130.86.130)
Please use a current release. Usage questions such as yours should also be
directed to openldap-technical(a)openldap.org rather than the ITS system,
which is for bug reports against current code.
This ITS will be closed.
Thanks,
Quanah
--
Quanah Gibson-Mount
Release and QA Engineer
<http://www.openldap.org>
7 years, 11 months
(ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com
Full_Name: Nadezhda Ivanova
Version: slapd 2.X
OS:
URL: ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch
Submission from: (NULL) (78.83.54.234)
This is an asynchronous version of the meta back-end.
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 2015 Symas Corporation
Redistribution and use in source and binary forms, with or without modification,
are permitted only as authorized by the OpenLDAP Public License.
7 years, 11 months
Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by hyc＠symas.com
ryan(a)nardis.ca wrote:
> On Thu, Nov 05, 2015 at 12:12:26AM +0000, ondra(a)mistotebe.net wrote:
>> Hi, the following will assert in liblber on i386 (and it should be possible to
>> craft a similar one for 64bit, I think):
>>
>> echo 'CoSSoJKSCg==' | base64 -d | ~/code/openldap/libraries/liblber/etest .
>
> ITYM dtest?
>
> slapd's sane default setting for sb_max_incoming appears to mitigate
> most of the potential security impact of this one.
Agreed.
But I guess we need to reject any len values that exceed the range of a signed
ber_len_t, since many liblber functions can only return a ber_slen_t result.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 11 months
(ITS#8302) The chain-tls failure
by benhuang＠icil.net
Full_Name: Ben Huang
Version: 2.4.37
OS: Ubuntu 12.04.4 LTS
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (202.130.86.130)
Two servers: Provider (A public IP) and Consumer (A private IP) both running
slap
2.4.37 and ubuntu 12.04. Replica is a replication partner of Provider using
syncrepl. Replication and TLS is working fine. When I attempt to add a chain
overlay
to Replica to send all writes over to the Privder, I cannot enable TLS from the
consumer to the ldap Provider.
Here is my overlay config using the rootDN and TLS (on Replica):
ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b
olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
olcChainCacheURI: FALSE
olcChainMaxReferralDepth: 1
olcChainReturnError: TRUE
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: none starttls=no
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://provider.example.com"
olcDbStartTLS: start starttls=no
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=ufreight,dc=com"
credentials="password" keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
With above configuration, I run following command is ok:
#ldapsearch -xLLL -H ldap://ldap-u1.ufreight.com -ZZ uid=testuser dn
dn: uid=testuser,ou=People,dc=ufreight,dc=com
But below errors occurred when I try to add an entry on consumer.
ldapadd -x -D "cn=admin,dc=ufreight,dc=com" -w password -f add_user.ldif -ZZ
adding new entry "uid=test,ou=People,dc=ufreight,dc=com"
ldap_add: Server is unavailable (52)
Consumer LDAP logs:
No 5 1 19:12:28 consumer slapd[6575]: conn=1005 fd=16 ACCEPT from
IP=127.0.0.1:41018 (IP=0.0.0.0:389)
Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 STARTTLS
Nov 5 19:12:29 consumer slapd[6575]: conn=1005 op=0 RESULT oid= err=0 text=
Nov 5 19:12:30 consumer slapd[6575]: conn=1005 fd=16 TLS established
tls_ssf=128 ssf=128
Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND
dn="cn=admin,dc=ufreight,%c=com" method=128
Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 BIND
dn="cn=admin,dc=ufreight,dc=com" mech=SIMPLE ssf=0
Nov 5 19:12:31 consumer slapd[6575]: conn=1005 op=1 RESULT tag=97 err=0 text=
Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 ADD
dn="uid=test,ou=People,dc=ufreight,dc=com"
Nov 5 19:12:32 consumer slapd[6575]: conn=1005 op=2 RESULT tag=105 err=52
text=
Nov 5 19:12:33 consumer slapd[6575]: conn=1005 op=3 UNBIND
Nov 5 19:12:33 consumer slapd[6575]: conn=1005 fd=16 closed
Provider LDAP logs:
Nov 5 19:11:18 provider slapd[17011]: conn=312743 fd=13 ACCEPT from
IP=140.207.172.138:39551 (IP=0.0.0.0:389)
Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 STARTTLS
Nov 5 19:11:18 provider slapd[17011]: conn=312743 op=0 RESULT oid= err=0 text=
Nov 5 19:11:19 provider slapd[17011]: conn=312743 fd=13 closed (TLS negotiation
failure)
Any suggestion what cause TLS negotiation failure? Thank you very much.
7 years, 11 months
