- openldap-bugs - openldap.org

RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 27 Mar '17

27 Mar '17

--On Friday, March 24, 2017 8:07 PM +0000 henson(a)acm.org wrote: >> From: Ond=C5=99ej Kuzn=C3=ADk >> Sent: Friday, March 24, 2017 2:28 AM >> =20 >> Looks like your patch differs from what was applied to re24 at least = > on >> that line (which calls be_add instead). Do you know why that is? Could >> you try with the current re24 branch (OPENLDAP_REL_ENG_2_4) instead? > > Ah, more confusion, sorry; I confirmed with Quanah the ITS 8432 patch I = > applied is identical to the one applied upstream, however, the line I = > referred to is in the patch applied to 2.4.44 release code, whereas I = > see you are referring to the current head of the 2.4 branch, which I'm = > sure has had numerous other changes applied to it that have probably = > shuffled things around a bit. > > If I could reliably reproduce this issue :(, I would definitely test it = > on our dev systems with whatever code you requested. Unfortunately, it = > only randomly occurs every 2-4 weeks in production, and I don't think I = > could get management approval to run the unreleased development branch = > of code in production for that long to see what happens. The 2.4.45 = > testing call came out last month, is there a timeline yet on getting = > that out? I should be able to push that into production fairly soon = > after it is released and see what happens there. There's too many outstanding issues to release 2.4.45, including this one. The remaining changes to syncrepl.c between 2.4.44 and current RE25 are: <http://www.openldap.org/its/index.cgi/?findid=8435> <http://www.openldap.org/its/index.cgi/?findid=8413> I would consider at least the patch for ITS#8413 as mandatory as well. Since ITS#8435 has been around since 2.4.40, it's unlikely to be related. <https://github.com/Zimbra/packages/blob/master/thirdparty/openldap/patches/…> is an easy spot to grab it from. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 24 Mar '17

24 Mar '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Friday, March 24, 2017 2:28 AM >=20 > Looks like your patch differs from what was applied to re24 at least = on > that line (which calls be_add instead). Do you know why that is? Could > you try with the current re24 branch (OPENLDAP_REL_ENG_2_4) instead? Ah, more confusion, sorry; I confirmed with Quanah the ITS 8432 patch I = applied is identical to the one applied upstream, however, the line I = referred to is in the patch applied to 2.4.44 release code, whereas I = see you are referring to the current head of the 2.4 branch, which I'm = sure has had numerous other changes applied to it that have probably = shuffled things around a bit. If I could reliably reproduce this issue :(, I would definitely test it = on our dev systems with whatever code you requested. Unfortunately, it = only randomly occurs every 2-4 weeks in production, and I don't think I = could get management approval to run the unreleased development branch = of code in production for that long to see what happens. The 2.4.45 = testing call came out last month, is there a timeline yet on getting = that out? I should be able to push that into production fairly soon = after it is released and see what happens there. Thanks much=E2=80=A6

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 24 Mar '17

24 Mar '17

On Thu, Mar 23, 2017 at 05:51:46PM -0700, Paul B. Henson wrote: >> From: Ond=C5=99ej Kuzn=C3=ADk >> Sent: Thursday, March 23, 2017 5:29 AM >> >> so far I've been unable to reproduce the issue, but going through the >> traceback again, there is something odd. In frame #5, syncrepl.c:2394 >> reads "rc =3D op->o_bd->be_add( op, &rs );" as per re24[0], but in you= r >> traceback, over_op_func calls overlay_op_walk with "which=3Dop_modify" >> (see frame #3) which doesn't really make sense to me. >=20 > As I mentioned in the report, this is 2.4.44 with the ITS 8432 patch > applied to prevent the infinite replication issue from occurring in > our production environment. With that patch applied, line 2394 of > syncrepl.c is: >=20 > rc =3D op->o_bd->be_modify( op, &rs ); >=20 > Sorry for any confusion that caused :(. Looks like your patch differs from what was applied to re24 at least on that line (which calls be_add instead). Do you know why that is? Could you try with the current re24 branch (OPENLDAP_REL_ENG_2_4) instead? Thanks --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 24 Mar '17

24 Mar '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, March 23, 2017 5:29 AM > > so far I've been unable to reproduce the issue, but going through the > traceback again, there is something odd. In frame #5, syncrepl.c:2394 > reads "rc =3D op->o_bd->be_add( op, &rs );" as per re24[0], but in = your > traceback, over_op_func calls overlay_op_walk with "which=3Dop_modify" > (see frame #3) which doesn't really make sense to me. As I mentioned in the report, this is 2.4.44 with the ITS 8432 patch = applied to prevent the infinite replication issue from occurring in our = production environment. With that patch applied, line 2394 of syncrepl.c = is: rc =3D op->o_bd->be_modify( op, &rs ); Sorry for any confusion that caused :(.

1 0

Re: (ITS#8622) Getting MDB_CORRUPTED when deleting within a DUPSORT database
by hyc＠symas.com 23 Mar '17

23 Mar '17

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> URL: http://www.openldap.org/lists/openldap-technical/201703/msg00043.html > > malloc (sizeof (KeyDataType) * recordCount); in the test program should be > calloc (recordCount, sizeof (KeyDataType)); to avoid writing uninit'ed data. > > And the test can be a lot smaller and faster: > > static long size = 50000000; > static int recordCount = 600000; > static int majorIdCount = 2500; > static int minorIdCount = 5000; 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

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 23 Mar '17

23 Mar '17

On 03/23/2017 05:38 AM, Howard Chu wrote: > subbarao(a)computer.org wrote: >> This could well be a very good idea for broader reasons, but it probably >> would be less desirable as a sole solution for this particular >> situation, at least for my use case. In this case, I'm backporting >> 2.4.44 for zesty to 14.04 LTS. Ideally, I want this to be a clean >> rebuild, without any code changes. > Overriding shell variables doesn't require any code changes. It only > requires that you set their values in whatever build script you use > that issues the "make test" command. That is the whole reason why we > defined these variables. Hmm, I don't think you're hearing what I'm saying in its intended context. But let me table this for now. Can we back up to the other part of the thread? If you can point out what I'm missing with the VM clock reliability, that would help me better appreciate where you're coming from. For example, if we were talking about tests between multiple VMs, I could immediately appreciate the value of being generous with timing margins. But as I indicated in my other message, I'm having difficulty seeing how those kinds of problems could arise here. I apologize if there's something obvious I'm missing or if I'm coming across as belaboring an undesirable point. I'm just trying to make sure we don't inadvertently rule out a simple solution to the problem that could work for everyone. Thanks, -Kartik

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 23 Mar '17

23 Mar '17

Hi Paul, so far I've been unable to reproduce the issue, but going through the traceback again, there is something odd. In frame #5, syncrepl.c:2394 reads "rc =3D op->o_bd->be_add( op, &rs );" as per re24[0], but in your traceback, over_op_func calls overlay_op_walk with "which=3Dop_modify" (see frame #3) which doesn't really make sense to me. [0]. http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f= =3Dservers/slapd/syncrepl.c;hb=3Drefs/heads/OPENLDAP_REL_ENG_2_4#l2394 --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by hyc＠symas.com 23 Mar '17

23 Mar '17

subbarao(a)computer.org wrote: > On 03/22/2017 03:19 PM, Quanah Gibson-Mount wrote: >> Even better is to use the SLEEP variables instead of hard coded >> values. Then they can be overridden in the test environment if >> necessary for specific VMs. >> >> At the moment we have: >> >> quanah@ub16:~/git/openldap/openldap-head/tests/scripts$ grep SLEEP >> defines.sh >> SLEEP0=${SLEEP0-1} >> SLEEP1=${SLEEP1-7} >> SLEEP2=${SLEEP2-15} >> >> It may be useful to add things like SLEEP10, SLEEP20, etc, and rebase >> tests off of that. 1/7/15 seem rather odd increments (no pun intended!). > > This could well be a very good idea for broader reasons, but it probably > would be less desirable as a sole solution for this particular > situation, at least for my use case. In this case, I'm backporting > 2.4.44 for zesty to 14.04 LTS. Ideally, I want this to be a clean > rebuild, without any code changes. Overriding shell variables doesn't require any code changes. It only requires that you set their values in whatever build script you use that issues the "make test" command. That is the whole reason why we defined these variables. -- -- 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#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by michael＠stroeder.com 22 Mar '17

22 Mar '17

Disclaimer: I did not dive into the test script. Maybe my suggestion is stupid. ;-) How about just setting the pwdChangedTime attribute (with the help of relax rules control) to a value in the (near?) past right before sending the bind request to be tested? Ciao, Michael.

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 22 Mar '17

22 Mar '17

On 03/22/2017 04:00 PM, Kartik Subbarao wrote: > On 03/22/2017 03:11 PM, Howard Chu wrote: >>> A recent 2.4.44 package build failed on a VM due to the following >>> timing >>> dependency between the lockout and expiration tests in test022-ppolicy. >> >> Clocks on VMs are notoriously unstable, which is why we have always >> used such large margins in these tests. Shaving things down to "1 >> second more than needed" will probably break in multiple build >> environments. > > Just to make sure we're understanding each other clearly -- are you > saying that you've seen VMs where "sleep 10" won't sleep for at > *least* 10 actual seconds? I haven't come across this, [...] Hmm, the more I think about this, the harder it is for me to envision the kind of failure scenario you seem to be implying. Let me spell out my thought process and you can point out where I'm going wrong: Assumption: An "unstable" clock on a VM is one that doesn't advance at one second per second of real-world time, but at least monotonically increases over time (ignoring DST exceptions and rare things like that). If it's *not* monotonically increasing, then I don't see how all kinds of things wouldn't break on the system -- like cron running duplicate jobs, etc. OpenLDAP tests would be the least of someone's worries in that situation :-) Given this assumption, then "sleep 10" on a VM should always sleep for at *least* 10 seconds as marked by the VM's system clock. It doesn't matter how that compares to 10 seconds in the real world, since everything running on the VM is calculated relative to the VM clock. In particular, both the slapd process and the test shell script are relying on the same VM clock. So I don't see how sleeping for "1 second more than needed" -- which in this case would be 16 seconds and 31 seconds for each section -- could cause anything to break in this particular script. What am I missing? Thanks, -Kartik

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 22 Mar '17

22 Mar '17

On 03/22/2017 03:19 PM, Quanah Gibson-Mount wrote: > Even better is to use the SLEEP variables instead of hard coded > values. Then they can be overridden in the test environment if > necessary for specific VMs. > > At the moment we have: > > quanah@ub16:~/git/openldap/openldap-head/tests/scripts$ grep SLEEP > defines.sh > SLEEP0=${SLEEP0-1} > SLEEP1=${SLEEP1-7} > SLEEP2=${SLEEP2-15} > > It may be useful to add things like SLEEP10, SLEEP20, etc, and rebase > tests off of that. 1/7/15 seem rather odd increments (no pun intended!). This could well be a very good idea for broader reasons, but it probably would be less desirable as a sole solution for this particular situation, at least for my use case. In this case, I'm backporting 2.4.44 for zesty to 14.04 LTS. Ideally, I want this to be a clean rebuild, without any code changes. I'm especially reluctant to maintain a customized package for something that doesn't affect the behavior of the actual software. So having more variable(s) that need to be tuned, and thus changed from the vanilla Ubuntu package, isn't too appealing :-) Hopefully there's an agreeable solution to this issue that will make it work for everyone out of the box. In any case, I appreciate your and Howard's responses to this! Regards, -Kartik

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 22 Mar '17

22 Mar '17

On 03/22/2017 03:11 PM, Howard Chu wrote: >> A recent 2.4.44 package build failed on a VM due to the following timing >> dependency between the lockout and expiration tests in test022-ppolicy. > > Clocks on VMs are notoriously unstable, which is why we have always > used such large margins in these tests. Shaving things down to "1 > second more than needed" will probably break in multiple build > environments. Just to make sure we're understanding each other clearly -- are you saying that you've seen VMs where "sleep 10" won't sleep for at *least* 10 actual seconds? I haven't come across this, but if you have, then the adaptive solution where line 91 checks to see how many seconds have elapsed since line 67, and then calculates how much more it needs to sleep (perhaps with some more buffer) could be effective. If that doesn't work, then another thought might be to widen the difference between pwdLockoutDuration and pwdMaxAge to enable greater separation between the two tests, and adjust the script accordingly. Regards, -Kartik

1 0

Re: Re: (ITS#8546) "allow bind_anon_cred" in slapd.conf does not work as expected
by yelin＠venustech.com.cn 22 Mar '17

22 Mar '17

This is a multi-part message in MIME format. ------=_001_NextPart714452840021_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gUXVhbmFoDQpJIGFtIGZpbmUgdG8gY2xvc2UgdGhpcyBJVFMuDQoNCkluIHRoaXMgY2Fz ZSwgSSBvd2UgeW91IGEgJ1RoYW5rcycgZm9yIHJlc29sdmluZyB0aGUgaXNzdWUgaW4gbXkgcHJv amVjdC4NCkJ1dCB0aGUgdXNlciBleHBlcmllbmNlIGlzIHBvb3IuDQpGcm9tIHRoZSBjdXN0b21l cidzIHBvaW50IG9mIHZpZXcsIGl0IGlzIGhhcmQgdG8gZGV0ZXJtaW5lIGEgYnVnIG9yIGEgbWlz dW5kZXJzdGFuZGluZyB3aGVuIHRoZSByZXN1bHQgaXMgdW5leHBlY3RlZC4gDQoNCkJlc3RzLA0K DQoNCg0KDQp5ZWxpbkB2ZW51c3RlY2guY29tLmNuDQogDQpGcm9tOiBRdWFuYWggR2lic29uLU1v dW50DQpEYXRlOiAyMDE3LTAzLTIyIDIzOjI2DQpUbzogeWVsaW47IG9wZW5sZGFwLWl0cw0KU3Vi amVjdDogUmU6IChJVFMjODU0NikgImFsbG93IGJpbmRfYW5vbl9jcmVkIiBpbiBzbGFwZC5jb25m IGRvZXMgbm90IHdvcmsgYXMgZXhwZWN0ZWQNCkhlbGxvIFllbGluLA0KIA0KVGhlIElUUyBzeXN0 ZW0gaXMgZm9yIGZpbGluZyBidWcgcmVwb3J0cywgbm90IGZvciBhc2tpbmcgaGVscCB3aXRoIHNs YXBkIA0KY29uZmlndXJhdGlvbi4gIFRoZSBjb3JyZWN0IHJlc291cmNlIGZvciBjb25maWd1cmF0 aW9uIHF1ZXN0aW9ucyBpcyB0aGUgDQpvcGVubGRhcC10ZWNobmljYWwgbGlzdDoNCiANCjxodHRw Oi8vd3d3Lm9wZW5sZGFwLm9yZy9saXN0cy9tbS9saXN0aW5mby9vcGVubGRhcC10ZWNobmljYWw+ DQogDQogDQpZb3VyIHVuZGVyc3RhbmRpbmcgb2YgaG93IHRoaXMgZmVhdHVyZSB3b3JrcyBpcyBp bmNvcnJlY3QuICBBcyBub3RlZCBpbiB0aGUgDQpzbGFwZC5jb25mKDUpIG1hbiBwYWdlOg0KIA0K YmluZF9hbm9uX2NyZWQgYWxsb3dzIGFub255bW91cyBiaW5kIHdoZW4gY3JlZGVudGlhbHMgYXJl IG5vdCBlbXB0eSAoZS5nLiANCndoZW4gRE4gaXMgZW1wdHkpLg0KIA0KVGhlIG9wdGlvbiB5b3Ug YXJlIGxvb2tpbmcgZm9yIGluIHlvdXIgY2FzZSBpczoNCiANCmJpbmRfYW5vbl9kbiAgYWxsb3dz IHVuYXV0aGVudGljYXRlZCAoYW5vbnltb3VzKSBiaW5kIHdoZW4gRE4gaXMgbm90IGVtcHR5Lg0K IA0KVGhpcyBJVFMgd2lsbCBiZSBjbG9zZWQuDQogDQpSZWdhcmRzLA0KUXVhbmFoDQogDQotLQ0K IA0KUXVhbmFoIEdpYnNvbi1Nb3VudA0KUHJvZHVjdCBBcmNoaXRlY3QNClN5bWFzIENvcnBvcmF0 aW9uDQpQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBv d2VyZWQgYnkgT3BlbkxEQVA6DQo8aHR0cDovL3d3dy5zeW1hcy5jb20+DQogDQo= ------=_001_NextPart714452840021_=---- 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: 10.5pt; fo= nt-family: ????; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><b= ody>=0A<div><span></span>Hello <span style=3D"font-size: 10.5pt; line= -height: 1.5; background-color: window;">Quanah</span></div><div>I am fine= to close this ITS.</div><div><br></div><div><span style=3D"font-size: 10.= 5pt; line-height: 1.5; background-color: window;">In this case, I owe you = a 'Thanks' for resolving the issue in my project.</span></div><div>But the= user experience is poor.</div><div><span style=3D"font-size: 10.5pt; line= -height: 1.5; background-color: window;">From the customer's point of view= , it is hard to determine a bug or a misunderstanding when the result is u= nexpected. </span></div><div><br></div><div>Bests,</div><div><br></di= v>=0A<div><br></div><hr style=3D"width: 210px; height: 1px;" color=3D"#b5c= 4df" size=3D"1" align=3D"left">=0A<div><span><div style=3D"MARGIN: 10px; F= ONT-FAMILY: verdana; FONT-SIZE: 10pt"><div>yelin(a)venustech.com.cn</div></d= iv></span></div>=0A<blockquote style=3D"margin-top: 0px; margin-bottom: 0p= x; 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-R= IGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#00= 0000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>= From:</b> <a href=3D"mailto:quanah@symas.com">Quanah Gibson-Mount</a>= </div><div><b>Date:</b> 2017-03-22 23:26</div><div><b>To:</b>&nb= sp;<a href=3D"mailto:yelin@venustech.com.cn">yelin</a>; <a href=3D"mailto:= openldap-its(a)openldap.org">openldap-its</a></div><div><b>Subject:</b>&nbsp= ;Re: (ITS#8546) "allow bind_anon_cred" in slapd.conf does not work as expe= cted</div></div></div><div><div>Hello Yelin,</div>=0A<div> </div>=0A<= div>The ITS system is for filing bug reports, not for asking help with sla= pd </div>=0A<div>configuration.  The correct resource for configurati= on questions is the </div>=0A<div>openldap-technical list:</div>=0A<div>&n= bsp;</div>=0A<div><http://www.openldap.org/lists/mm/listinfo/openldap-t= echnical></div>=0A<div> </div>=0A<div> </div>=0A<div>Your und= erstanding of how this feature works is incorrect.  As noted in the <= /div>=0A<div>slapd.conf(5) man page:</div>=0A<div> </div>=0A<div>bind= _anon_cred allows anonymous bind when credentials are not empty (e.g. </di= v>=0A<div>when DN is empty).</div>=0A<div> </div>=0A<div>The option y= ou are looking for in your case is:</div>=0A<div> </div>=0A<div>bind_= anon_dn  allows unauthenticated (anonymous) bind when DN is not empty= .</div>=0A<div> </div>=0A<div>This ITS will be closed.</div>=0A<div>&= nbsp;</div>=0A<div>Regards,</div>=0A<div>Quanah</div>=0A<div> </div>= =0A<div>--</div>=0A<div> </div>=0A<div>Quanah Gibson-Mount</div>=0A<d= iv>Product Architect</div>=0A<div>Symas Corporation</div>=0A<div>Packaged,= certified, and supported LDAP solutions powered by OpenLDAP:</div>=0A<div= ><http://www.symas.com></div>=0A<div> </div>=0A</div></blockquo= te>=0A</body></html> ------=_001_NextPart714452840021_=------

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by quanah＠symas.com 22 Mar '17

22 Mar '17

--On Wednesday, March 22, 2017 8:11 PM +0000 hyc(a)symas.com wrote: > subbarao(a)computer.org wrote: >> Full_Name: Kartik Subbarao >> Version: 2.4.44 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (108.52.86.252) >> >> >> A recent 2.4.44 package build failed on a VM due to the following timing >> dependency between the lockout and expiration tests in test022-ppolicy. > > Clocks on VMs are notoriously unstable, which is why we have always used > such large margins in these tests. Shaving things down to "1 second more > than needed" will probably break in multiple build environments. Even better is to use the SLEEP variables instead of hard coded values. Then they can be overridden in the test environment if necessary for specific VMs. At the moment we have: quanah@ub16:~/git/openldap/openldap-head/tests/scripts$ grep SLEEP defines.sh SLEEP0=${SLEEP0-1} SLEEP1=${SLEEP1-7} SLEEP2=${SLEEP2-15} It may be useful to add things like SLEEP10, SLEEP20, etc, and rebase tests off of that. 1/7/15 seem rather odd increments (no pun intended!). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by hyc＠symas.com 22 Mar '17

22 Mar '17

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.52.86.252) > > > A recent 2.4.44 package build failed on a VM due to the following timing > dependency between the lockout and expiration tests in test022-ppolicy. Clocks on VMs are notoriously unstable, which is why we have always used such large margins in these tests. Shaving things down to "1 second more than needed" will probably break in multiple build environments. > > The problem is that the password expiration time is 30 seconds, and on slower > VMs, lines 67-91 take more than 30 seconds to execute. This causes the password > to expire by the time the ldapsearch command on line 93 is executed. That > ldapsearch command eats up one of the grace logins that's not supposed to be > consumed until line 106. This causes the grep count on line 124 to be off, > failing the entire script. > > A simple improvement would be to change line 91 to "sleep 10" instead of the > current "sleep 20". This would buy 10 more seconds of leeway on slower VMs, > while guaranteeing sufficient delay between lines 67-90 (e.g. 16 seconds, 1 > second more than the 15 second lockout time) on fast VMs. A more robust > improvement would be to check how much time has actually elapsed between lines > 67-90 and change line 91 to only sleep until 16 total seconds have elapsed since > line 67. > > Another suggestion would be to change the "sleep 20" on line 104 to "sleep 15". > That will shave 5 seconds off the build time for everyone, while still > guaranteeing that 31 seconds (e.g. 1 second more than the 30 second expiration > time) will have elapsed between lines 67-106). > > A further optimization could be implemented, if desired, by revisiting the test > and reducing all lockout times, expiration times, and other delays to the bare > minimum necessary, which would speed up package build times across the board. > > -- -- 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#8622) Getting MDB_CORRUPTED when deleting within a DUPSORT database
by h.b.furuseth＠usit.uio.no 22 Mar '17

22 Mar '17

I wrote: > URL: http://www.openldap.org/lists/openldap-technical/201703/msg00043.html malloc (sizeof (KeyDataType) * recordCount); in the test program should be calloc (recordCount, sizeof (KeyDataType)); to avoid writing uninit'ed data. And the test can be a lot smaller and faster: static long size = 50000000; static int recordCount = 600000; static int majorIdCount = 2500; static int minorIdCount = 5000;

1 0

(ITS#8623) test022-ppolicy can fail due to timing dependency between lockout and expiration tests
by subbarao＠computer.org 22 Mar '17

22 Mar '17

Full_Name: Kartik Subbarao Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.52.86.252) A recent 2.4.44 package build failed on a VM due to the following timing dependency between the lockout and expiration tests in test022-ppolicy. The problem is that the password expiration time is 30 seconds, and on slower VMs, lines 67-91 take more than 30 seconds to execute. This causes the password to expire by the time the ldapsearch command on line 93 is executed. That ldapsearch command eats up one of the grace logins that's not supposed to be consumed until line 106. This causes the grep count on line 124 to be off, failing the entire script. A simple improvement would be to change line 91 to "sleep 10" instead of the current "sleep 20". This would buy 10 more seconds of leeway on slower VMs, while guaranteeing sufficient delay between lines 67-90 (e.g. 16 seconds, 1 second more than the 15 second lockout time) on fast VMs. A more robust improvement would be to check how much time has actually elapsed between lines 67-90 and change line 91 to only sleep until 16 total seconds have elapsed since line 67. Another suggestion would be to change the "sleep 20" on line 104 to "sleep 15". That will shave 5 seconds off the build time for everyone, while still guaranteeing that 31 seconds (e.g. 1 second more than the 30 second expiration time) will have elapsed between lines 67-106). A further optimization could be implemented, if desired, by revisiting the test and reducing all lockout times, expiration times, and other delays to the bare minimum necessary, which would speed up package build times across the board.

1 0

RE: (ITS#8402) indexing issue
by quanah＠symas.com 22 Mar '17

22 Mar '17

--On Wednesday, April 13, 2016 5:00 PM +0000 escriba(a)cells.es wrote: > Mail system message that raised the alarm: > > Reporting-MTA: dns; mail01.xxxx.xx > X-Postfix-Queue-ID: 24C5526003F > X-Postfix-Sender: rfc822; xxxxx at xxx .xy > Arrival-Date: Wed, 13 Apr 2016 16:30:34 +0200 (CEST) > > Final-Recipient: rfc822; xxxxx @ xxx .xy > Original-Recipient: rfc822; xxxxxx at xxx .xy > Action: failed > Status: 5.1.1 > Remote-MTA: dns; mail02.xxxx.xx > Diagnostic-Code: smtp; 550 5.1.1 <xxxxxxx at xxx .xy >: Recipient address > rejected: User unknown in local recipient table > > >> From my point of view indexing, even if not needed, may never do the >> queries > fail, isn't it? > But seems something weird happened. Hello, I would note that you reported using a very ancient version of OpenLDAP (2.4.23, released June 2010). It's possible you encountered a bug that has long since been fixed. I would advise using a current release of OpenLDAP. If you still encounter the same issue with indices, then please follow up to this ITS. In the meantime, this ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8451) slapd[27939]: connection_input: conn=1295612 deferring operation: binding
by quanah＠symas.com 22 Mar '17

22 Mar '17

Hello, The ITS system is for reporting bugs with OpenLDAP, rather than help/configuration requests such as what was filed in your report. In the future, please use the OpenLDAP technical mailing list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8546) "allow bind_anon_cred" in slapd.conf does not work as expected
by quanah＠symas.com 22 Mar '17

22 Mar '17

Hello Yelin, The ITS system is for filing bug reports, not for asking help with slapd configuration. The correct resource for configuration questions is the openldap-technical list: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> Your understanding of how this feature works is incorrect. As noted in the slapd.conf(5) man page: bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty). The option you are looking for in your case is: bind_anon_dn allows unauthenticated (anonymous) bind when DN is not empty. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8622) Getting MDB_CORRUPTED when deleting within a DUPSORT database
by h.b.furuseth＠usit.uio.no 22 Mar '17

22 Mar '17

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.19, mdb.master OS: Linux x86_64 URL: http://www.openldap.org/lists/openldap-technical/201703/msg00043.html Submission from: (NULL) (193.157.240.142) Submitted by: hallvard This is Klaus Malorny's test case from openldap-technical (linked below). Compiled with gcc -std=gnu99. Breaks mdv.master and mdb.RE: .... 33000000 records written testing mdb_cursor_get: unexpected error -30796: MDB_CORRUPTED: Located page was wrong type In LMDB 0.9.18, the test case instead asserted: mdb.c:5647: Assertion 'mc->mc_flags & C_INITIALIZED' failed in mdb_cursor_next() That was fixed by commit b46fc3e438d8085d5e5fc7d558c0002ee1e2753c "ITS#8406 fix xcursors after cursor_del". Then it broke again at 6b1df0e4c7fadd21d1233d7157229b2d89ccaa04 "More for ITS#8406 (xcursor fixups)", giving the MDB_CORRUPTED.

1 0

Re: (ITS#8467) LMDB creation
by quanah＠symas.com 21 Mar '17

21 Mar '17

--On Tuesday, July 19, 2016 3:44 PM +0000 potte324(a)umn.edu wrote: > I've been trying to create LMDB files for a particle physics project in > classifying particle interactions. Anyways, I modified an old code used to > create levelDB files from a TTree in the Root software developed by CERN > using c++. Then, I tried to run the neural net on the lmdb files and it > gave me an error that std::string_length was too large. And I tried to > show the images I had saved in it and it didn't show me anything, whereas > on an LMDB file I had from one of the caffe tutorials it did show me the > image. > > Do you have any ideas of what could be wrong? It think it is likely that I > messed something up and can't find a lot of documentation for building > LMDB files. In addition, I'm fairly new to coding and I had a hard time > reading the API page due to this. If you have any ideas of how to help > that would be great. Hi Jordan, The ITS system is for reporting bugs, rather than asking for help with programming questions, etc. The correct place for such questions would be the openldap-technical mailing list: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8621) Unique through multiple attribute
by quanah＠symas.com 21 Mar '17

21 Mar '17

--On Sunday, March 19, 2017 12:07 AM +0000 michael(a)stroeder.com wrote: > I'd say it works as designed and there is no bug. > > The work-around for your use-case is to use SUP to derive from a common > attribute type. But this should be discussed on openldap-technical > mailing list. Agreed. I've moved this to the enhancement queue in case anyone ever wants to work on enforcing uniqueness across > 1 attribute, but I would think that would require all of the attributes to have the same syntax, etc. Michael's suggestion for this specific use case seems to be the best solution for now. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8619) Enhancement request: Nested group support using dynlist recursion
by Christ.Klinge＠web.de 20 Mar '17

20 Mar '17

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>I have encountered some scepticism regarding the benefits of nesting within OpenLDAP itself. Some have argued, that applications should resolve nested groups or that nested groups should be created using automation instead. Here, I'd like to respond to these two objections.</div> <div> </div> <div>1. applications should be responsible resolve nested groups</div> <div>First, I disagree from a philosophical point of view. The identity management system and thus the user directory is the central point of knowledge regarding group membership. For the sake of maintainability, all of the information as to why any given user is member of any of its groups, should be present at this central location. Whether a user is a direct member of a group or whether he is member of a sub-group, may interest applications, but what matters most, is that the user is in fact part of both the sub-group and all of its ancestors.</div> <div> </div> <div>Secondly, some applications simply don't have nested group support. It is a fairly common feature, but it just isn't part of every piece of software out there. Implementing nesting in the directory removes the need for support on the application side entirely. In the (from my curent point of view unlikely) event that some application demands to resolve nesting itself, aliasing can be used to deactivate dynlist for the given application.</div> <div> </div> <div>2. automation instead of nesting</div> <div>Automation comes with two caveats which I would like to address individually:</div> <div> </div> <div> <div>2.a additional software</div> <div>This may come as a no brainer for most, but I'd like to point out that automation requires some form of additional software, be it diy scripts or an application. This increases complexity both due to operation of this software and its interaction with the user directory.</div> <div> </div> </div> <div>2.b divergent center of information</div> <div>Instead of maintaining nesting information within the user directory, the software used most likely stores its data outside of the directory. Worst case, it is hardcoded into some scripts. Thus, the information as to which groups are related is likely stored outside of the actual directory itself. This point may be void if the automation system stores nesting information on the group objects inside of the user directory.<br/>  </div> <div>Sincerely,</div> <div>Christopher Klinge</div></div></body></html>

1 0

(ITS#8578)
by sca+openldap＠andreasschulze.de 19 Mar '17

19 Mar '17

Am 01.02.2017 um 23:04 schrieb openldap-its(a)OpenLDAP.org: > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. the patch I provided 20170201 remove variables that are unused as long as "configure --disable-rewrite" was given. Now I enabled rewrite and build fail :-/ server/slapd/syncrepl.c define variables named 'bv2' that are used if rewrite is enabled and unused otherwise. Maybe the definition of 'REWRITE_DN' ( server/slapd/syncrepl.c, ~line 1726 ) could declare bv2 as unused to avoid a compiler warning. uploaded a new version: ftp://ftp.openldap.org/incoming/andreas-schulze-its8578-20170319.patch Andreas

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs