- openldap-bugs - openldap.org

Re: (ITS#8308) Replication master/master with delta sync freeze after reboot
by quanah＠zimbra.com 12 Nov '15

12 Nov '15

--On Thursday, November 12, 2015 1:23 PM +0000 fs(a)etiam.com wrote: > Full_Name: Florian Suhard > Version: 2.4.40 > OS: Redhat 6.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.157.230.211) > I tried using gdb to detect the error. I see this trace : > Loaded symbols for /usr/bib64/libnsspem.so > 0x00007faa47d2022d in pthread_join (threadid=140368938260224, > thread_return=0x0) at pthread_join.c:89 > 89 lll_wait_tid (pd->tid); > > I'm at your disposal for any further informations. Hello, The RedHat builds of OpenLDAP are linked to the MozNSS crypto libraries. This is neither supported nor encouraged by the OpenLDAP project. You will need to take this report to RedHat, as they are responsible for dealing with any issues caused by their unsupported usage of MozNSS. I *strongly* advise you completely avoid the RHEL based OpenLDAP builds entirely. The LTB project provides builds for RHEL that are sanely linked to the supported OpenSSL crypto libraries if you are not able to build OpenLDAP yourself. Companies requires a support matrix for their OpenLDAP deployments will likely wish to contact Symas. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8309) Replication master/master with delta sync freeze after reboot
by fs＠etiam.com 12 Nov '15

12 Nov '15

Full_Name: Florian Suhard Version: 2.4.40 OS: Redhat 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.157.230.211) Hello, My name is Florian Suhard, i'm a french engineer. I am currently working on a project using openldap replication. Architecture of the project is as follows. We have several Redhat 6.5 servers (4 on our test environments). Each server has its own openldap directory on version 2.4.40. One of this server is the hub (connected to all other). Other servers are nodes (only connected to the hub). Replication master/master with delta sync has been configured on each servers. Nodes replicates only with the hub, Hub replicate with all nodes. What we observe it's sometimes (i'm sorry it's really random) when we reboot the hub, the slapd service 'freeze' on the hub and on others nodes. Service slapd seems start (service slapd status => OK) but not respo w when we try to connect with JXplorer and whith php function ldap_connect. When we restart slapd on the hub (service slapd restart) everything returns to normal. I have the feeling that it's more easily to reproduce the bug by doing change on ldap directory before reboot the hub. We tried to correct by upgrade on openldap version 2.4.42. Redhat not provide 2.4.42 version so we get source rpm of Redhat 2.4.40 and rebuild with source of openldap 2.4.42. Bug still reproduced after the upgrade. Our replication configuration can be found on your ftp ftp://ftp.openldap.org/incoming/ in archive Florian-Suhard-20151112.tar This archive is composed of 4 folders for the 4 servers configurations slapd_opex-ctm.test.etiam.com.tar => one node slapd_hia1-ctm.test.etiam.com.tar => one node slapd_hia2-ctm.test.etiam.com.tar => one node slapd_central-ctm.test.etiam.com.tar => hub I tried using gdb to detect the error. I see this trace : Loaded symbols for /usr/bib64/libnsspem.so 0x00007faa47d2022d in pthread_join (threadid=140368938260224, thread_return=0x0) at pthread_join.c:89 89 lll_wait_tid (pd->tid); I'm at your disposal for any further informations. Thanks

1 0

(ITS#8308) Replication master/master with delta sync freeze after reboot
by fs＠etiam.com 12 Nov '15

12 Nov '15

Full_Name: Florian Suhard Version: 2.4.40 OS: Redhat 6.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.157.230.211) Hello, My name is Florian Suhard, i'm a french engineer. I am currently working on a project using openldap replication. Architecture of the project is as follows. We have several Redhat 6.5 servers (4 on our test environments). Each server has its own openldap directory on version 2.4.40. One of this server is the hub (connected to all other). Other servers are nodes (only connected to the hub). Replication master/master with delta sync has been configured on each servers. Nodes replicates only with the hub, Hub replicate with all nodes. What we observe it's sometimes (i'm sorry it's really random) when we reboot the hub, the slapd service 'freeze' on the hub and on others nodes. Service slapd seems start (service slapd status => OK) but not respo w when we try to connect with JXplorer and whith php function ldap_connect. When we restart slapd on the hub (service slapd restart) everything returns to normal. I have the feeling that it's more easily to reproduce the bug by doing change on ldap directory before reboot the hub. We tried to correct by upgrade on openldap version 2.4.42. Redhat not provide 2.4.42 version so we get source rpm of Redhat 2.4.40 and rebuild with source of openldap 2.4.42. Bug still reproduced after the upgrade. Our replication configuration can be found on your ftp ftp://ftp.openldap.org/incoming/ in archive Florian-Suhard-20151112.tar This archive is composed of 4 folders for the 4 servers configurations slapd_opex-ctm.test.etiam.com.tar => one node slapd_hia1-ctm.test.etiam.com.tar => one node slapd_hia2-ctm.test.etiam.com.tar => one node slapd_central-ctm.test.etiam.com.tar => hub I tried using gdb to detect the error. I see this trace : Loaded symbols for /usr/bib64/libnsspem.so 0x00007faa47d2022d in pthread_join (threadid=140368938260224, thread_return=0x0) at pthread_join.c:89 89 lll_wait_tid (pd->tid); I'm at your disposal for any further informations. Thanks

1 0

(ITS#8307) startup failed with DDS enabled
by boesch＠fhv.at 12 Nov '15

12 Nov '15

Full_Name: Christian B.sch Version: 2.4.42 OS: FreeBSD 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:628:2130:4458::93) I installed OpenLDAP 2.4.42, enabled these overlays on the mdb database: olcOverlay={0}syncprov.ldif olcOverlay={1}dds.ldif olcOverlay={2}accesslog.ldif olcOverlay={3}unique.ldif olcOverlay={4}ppolicy.ldif olcOverlay={5}refint.ldif olcOvery%y={6}memberof.ldif olcOverlay={7}dynlist.ldif started, everything is fine. Then I added an empty base tree: dn: dc=example,dc=net objectClass: dcObject objectClass: organization o: ORG dc: example dn: cn=admin,dc=example,dc=net objectClass: organizationalRole cn: LDAP Admin cn: admin dn: o=org,dc=example,dc=net o: ORG objectClass: organization objectClass: top After that, if slapd is restarted: /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd If the db files are removed again, the startup works again, and if the dds overlay is removed the startup is always working even if the database isn't empty.

1 0

(ITS#8306) SLEEP0 etc should be used in test scripts
by quanah＠openldap.org 10 Nov '15

10 Nov '15

Full_Name: Quanah Gibson-Mount Version: master OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) We define SLEEP0, SLEEP1, etc to allow the ability to set via the environment how long to sleep during test executions. However, the variables are not used consistently. For example, "sleep 1" occurs 142 times in the test scripts, instead of using SLEEP0

1 0

Re: (ITS#8304) LMDB mdb_del data loss in a cursor
by hyc＠symas.com 09 Nov '15

09 Nov '15

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/

1 0

(ITS#8304) LMDB mdb_del data loss in a cursor
by malyn＠strangeGizmo.com 09 Nov '15

09 Nov '15

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.

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 06 Nov '15

06 Nov '15

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/

1 0

RE: (ITS#8300) LMDB mdb_cursor_del data loss
by malyn＠strangegizmo.com 06 Nov '15

06 Nov '15

> >> 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

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 06 Nov '15

06 Nov '15

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--

1 0

Re: Re: (ITS#8302) The chain-tls failure
by benhuang＠icil.net 06 Nov '15

06 Nov '15

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_=------

1 0

Re: (ITS#8302) The chain-tls failure
by quanah＠openldap.org 05 Nov '15

05 Nov '15

--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>

1 0

(ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 05 Nov '15

05 Nov '15

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.

1 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by hyc＠symas.com 05 Nov '15

05 Nov '15

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/

1 0

(ITS#8302) The chain-tls failure
by benhuang＠icil.net 05 Nov '15

05 Nov '15

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.

1 0

Re: (ITS#8267) contributing a new overlay unicodepw
by ingo.voss＠gmail.com 05 Nov '15

05 Nov '15

2015-10-25 9:28 GMT+01:00 Howard Chu <hyc(a)symas.com>: > Ingo Voss wrote: >> >> >> >> Am 17.10.2015 um 20:58 schrieb Howard Chu: >>> >>> ingo.voss(a)gmail.com wrote: >>>> >>>> Full_Name: Ingo Voss >>>> Version: >>>> OS: >>>> URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar >>>> Submission from: (NULL) (78.53.86.212) >>>> >>>> >>>> Hello, >>>> >>>> I wrote a small overlay, that restricts all LDAP modification requests, >>>> so >>>> that >>>> only password changes for MS unicodePwd are possible. >>>> All other LDAP requests will not be observed. >>>> If someone needs a read-only proxy (in a e.g. dmz) for an MS Active >>>> Directory, >>>> but password changes must be possible, then unicodepw is the right >>>> overlay. >>>> For more informations, a manual page is included. >>> >>> >>> If you want a read-only proxy, shouldn't this overlay also intercept and >>> deny all Add/Delete/ModDN requests? >>> >> >> Yes, you are right! But such overlay (denyop) exist already and it is >> working >> well. >> The manual page for unicodepw refers to denyop and describes the complete >> configuration in detail. > > > OK. > > This code is full of C++ comments. OpenLDAP uses C comments only. > > This code is full of SPACEs for indentation. OpenLDAP uses TAB characters > for indentation, with 4-column tab stops. OK, I'll change that. > > Your debug messages are using STATS debug level. STATS is reserved for LDAP > operation/parameter logging only and is the default level. Code should be > silent at the default level unless major errors have occurred. Please can you guide me what log level should be used for such security related messages? The messages are only logged, if a password is changed. (Normally, password changes are very seldom and makes low noise.) Thanks Ingo

1 0

Re: (ITS#8301) signed/unsigned confusion in ber_get_next()
by ryan＠nardis.ca 05 Nov '15

05 Nov '15

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.

1 0

(ITS#8301) signed/unsigned confusion in ber_get_next()
by ondra＠mistotebe.net 05 Nov '15

05 Nov '15

Full_Name: Ond&#345;ej Kuzn.k Version: re24 OS: Linux i386 URL: Submission from: (NULL) (86.166.135.137) 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 . My first reaction was that it encodes a length that, while still not enough to overflow the address space, will have the highest bit set and is interpreted as negative when saved into to_go in io.c:658, triggering the assert. However ber_get_next is more complex than that and I can't read BER yet.

1 0

Re: (ITS#8300) LMDB mdb_cursor_del data loss
by hyc＠symas.com 04 Nov '15

04 Nov '15

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. > > -- -- 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#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by malyn＠strangegizmo.com 04 Nov '15

04 Nov '15

> >> I have a new repro of an ITS#8264-like situation, but with different > >> input data and with slightly different results. Note that ITS#8264 > >> was fixed with the dataset provided in that bug; this is a different > >> dataset and produces different results. > >> > >> 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 04000000000000003a...), and > >> incorrectly leaves 21 keys in place that should have been deleted > >> (those keys begin with 05000000000000003a...). > >> This last item is the primary difference between these two bugs. > >> > >> Unlike ITS#8264, you do not need to remove the database in between > >> test runs in order to repro this issue, although the results are > >> still incorrect and will eventually cause a bus error. > > > > Thanks again for the excellent bug reports. Fixed now in git. >=20 > I should also note that this is not a sensible use case. mdb_del has to > construct a cursor to perform its work; if you already have a cursor open= you > should just use mdb_cursor_del. mdb_del is meant for one-shot use and is > much slower than mdb_cursor_del when used in an iteration. Thanks for this information. I will make the change to use mdb_cursor_del = when possible. There are a couple of circumstances where I do not currentl= y have access to the cursor though and will need to use mdb_del (or mdb_put= , for updates) inside of the cursor. I will look into passing the cursor u= p to my higher-level API callers though... Note that I just reported ITS#8300, which was found after making the switch= to mdb_cursor_del (and after applying the fix for ITS#8299). Thanks, Michael Alyn Miller

1 0

(ITS#8300) LMDB mdb_cursor_del data loss
by malyn＠strangeGizmo.com 04 Nov '15

04 Nov '15

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. 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.

1 0

Re: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by hyc＠symas.com 04 Nov '15

04 Nov '15

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-151103.c >> Submission from: (NULL) (96.251.78.237) >> >> >> I have a new repro of an ITS#8264-like situation, but with different input data >> and with slightly different results. Note that ITS#8264 was fixed with the >> dataset provided in that bug; this is a different dataset and produces >> different >> results. >> >> 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 04000000000000003a...), and incorrectly leaves 21 keys in place >> that should have been deleted (those keys begin with 05000000000000003a...). >> This last item is the primary difference between these two bugs. >> >> Unlike ITS#8264, you do not need to remove the database in between test runs in >> order to repro this issue, although the results are still incorrect and will >> eventually cause a bus error. > > Thanks again for the excellent bug reports. Fixed now in git. I should also note that this is not a sensible use case. mdb_del has to construct a cursor to perform its work; if you already have a cursor open you should just use mdb_cursor_del. mdb_del is meant for one-shot use and is much slower than mdb_cursor_del when used in an iteration. -- -- 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#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by hyc＠symas.com 04 Nov '15

04 Nov '15

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-151103.c > Submission from: (NULL) (96.251.78.237) > > > I have a new repro of an ITS#8264-like situation, but with different input data > and with slightly different results. Note that ITS#8264 was fixed with the > dataset provided in that bug; this is a different dataset and produces different > results. > > 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 04000000000000003a...), and incorrectly leaves 21 keys in place > that should have been deleted (those keys begin with 05000000000000003a...). > This last item is the primary difference between these two bugs. > > Unlike ITS#8264, you do not need to remove the database in between test runs in > order to repro this issue, although the results are still incorrect and will > eventually cause a bus error. Thanks again for the excellent bug reports. Fixed now in git. -- -- 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#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by malyn＠strangeGizmo.com 03 Nov '15

03 Nov '15

Full_Name: Michael Alyn Miller Version: Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151103.c Submission from: (NULL) (96.251.78.237) I have a new repro of an ITS#8264-like situation, but with different input data and with slightly different results. Note that ITS#8264 was fixed with the dataset provided in that bug; this is a different dataset and produces different results. 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 04000000000000003a...), and incorrectly leaves 21 keys in place that should have been deleted (those keys begin with 05000000000000003a...). This last item is the primary difference between these two bugs. Unlike ITS#8264, you do not need to remove the database in between test runs in order to repro this issue, although the results are still incorrect and will eventually cause a bus error.

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 02 Nov '15

02 Nov '15

Hello Quanah, unfortunately I cannot send here the complete and precise schema, is used by our internal proprietary applications. Anyway, it can be described as: * dc=directory ** ou=person ** ou=organization ** ou=relationship "ou=person" has "objectClass=inetOrgPerson" and an identifier (yeah, clearly other fields like first name, last name, isActive, phone number, address and so on) "ou=organization" has an identifier plus the other "common" fields (name, address...) "ou=relationship" has "objectClass=groupOfNames" and is used to describe: * relationships between persons and organizations ("a person belongs to one or more organization", that is an "organization has these persons as members") * relationships between organizations (e.g. "org_1_a is a sub-organization of the main organization org_1", that is "org_1 has org_1_a as member"). So, considering the schema I described in my previous email: Test-bench_application --> spring_http_invoker --> Server_side_app ---> data_for_db_2 ---> LDAP ---> data_from_db_2 ---> App_in_syncprov_with_ldap the "Server_side_app" creates in sequence: * one unique organization (let me call it simply "org_p", it has no sub-organization) * about 19500 persons by doing a loop as: ** create one person ** create the related entry in "ou=relationship" to describe "person x belongs to org_p" Meanwhile this procedure is done, the synchronization via syncprov is running to keep in sync the LDAP database 2 and "App_in_syncprov_with_ldap". Hope it helps. thanks for the feedback. 2015-10-30 19:06 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, October 30, 2015 10:35 AM +0100 Maurizio Lattuada > <maurizio.lattuada(a)gmail.com> wrote: > >> Hello Quanah, >> >> I added the syncprov overlay to the 1st database, but is neither used >> by our application (rather than by another off-the-shelf application) >> nor replicated as is for the 2nd database. >> For your 2nd request, unfortunately I'm not able to test it, since >> between the LDAP and my test-bench application there is another server >> side application: > > > Ok. Is it possible to provide the custom schema you are using, and an > example of a user entry you are loading, so I can template it? I'd like to > see if I can reproduce the problem. > > Thanks. > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration -- Maurizio Lattuada

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs