- openldap-bugs - openldap.org

Re: (ITS#8291) ./run -b hdb test007 fails
by ondra＠mistotebe.net 27 Oct '15

27 Oct '15

On Tue, Oct 27, 2015 at 08:24:08AM +0000, michael(a)stroeder.com wrote: > Currently this test fails with git master > 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2: > > michael@nb2:.../openldap/tests> ./run -b hdb test007 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test007-slapmodify for hdb... > running defines.sh > Running slapadd to build slapd database... > Testing modify, add, and delete using slapmodify... > slapmodify failed (1)! > > I can provide more logs if needed. Yes please. I am curious which modify/delete failed as I can't reproduce this failure. Cheers, Ondrej

1 0

(ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com 27 Oct '15

27 Oct '15

Full_Name: Michael Str.der Version: master 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2 OS: openSUSE Linux URL: Submission from: (NULL) (213.240.180.113) Currently this test fails with git master 0d9b8ebe4bfe584e796f683be6203d4a4eb421a2: michael@nb2:/usr/src/michael/openldap-git/master/openldap/tests> ./run -b hdb test007 Cleaning up test run directory leftover from previous run. Running ./scripts/test007-slapmodify for hdb... running defines.sh Running slapadd to build slapd database... Testing modify, add, and delete using slapmodify... slapmodify failed (1)! I can provide more logs if needed.

1 0

Re: (ITS#8289) slapd seg faults with MOD_INCREMENT on derived attribute
by hyc＠symas.com 27 Oct '15

27 Oct '15

michael(a)stroeder.com wrote: > Full_Name: > Version: re24 > OS: openSUSE Linux > URL: > Submission from: (NULL) (213.240.180.113) > > > Attribute type declaration 'bar' with Integer syntax. > > 'foo' SUP 'bar' makes slapd crash when sending LDAP_MOD_INCREMENT on 'foo'. > > LDAP_MOD_INCREMENT on 'foo' works if it's not SUP 'bar' but directly declared > with Integer syntax. > > Fixed now in master -- -- 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#8290) Our system has occured "Server is unwilling to perform" from slapd when syncrepl rid was changed.
by t-ogura＠az.jp.nec.com 27 Oct '15

27 Oct '15

Full_Name: Tom Ogura Version: 2.4.40 OS: Redhat Enterprise Linux 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (182.250.250.193) Our system use LDAP server. Master server connect two slave nodes , A and B. And, LDAP syncronization configure as below. B server <---> Master server <---> A server rid=27 rid=30 rid=32 Master server is set for LDAP syncronization in slapd.conf. ----- serverID 30 syncrepl rid=27 provider=ldap://xx.xx.xx.xx bindmethod=simple binddn="cn=xxxx" credentials="xxxx" searchbase="xxxx" schemachecking=off type=refreshAndPersist retry="2 30 30 +" syncrepl rid=32 provider=ldap://xx.xx.xx.xx bindmethod=simple binddn="cn=xxxx" credentials="xxxx" searchbase="xxxx" schemachecking=off type=refreshAndPersist retry="2 30 30 +" ----- When master server's slapd restart, B server's slapd disconnect to Master server's slapd. After master server 's slapd start, B server's slapd made Error log as below and didn't syncronize to LDAP updating data from B server to master server. slapd[12491]: do_syncrep2: rid=030 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform slapd[12491]: do_syncrep2: rid=030 (53) Server is unwilling to perform slapd[12491]: do_syncrepl: rid=030 rc -2 retrying (23 retries left) Why did it happen ?

1 0

Re: (ITS#8289) slapd seg faults with MOD_INCREMENT on derived attribute
by michael＠stroeder.com 27 Oct '15

27 Oct '15

The last lines before crash: 562eb075 => access_allowed: delete access to "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de" "oathFailureCount" requested 562eb075 => dn: [5] dc=stroeder,dc=de 562eb075 => acl_get: [5] matched 562eb075 => acl_get: [5] attr oathFailureCount 562eb075 => acl_mask: access to entry "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de", attr "oathFailureCount" requested 562eb075 => acl_mask: to all values by "cn=michael ströder+mail=michael(a)stroeder.com,ou=private,dc=stroeder,dc=de", (=0) 562eb075 <= check a_group_pat: cn=slapd admins,ou=groups,dc=stroeder,dc=de 562eb075 <= acl_mask: [1] applying manage(=mwrscxd) (stop) 562eb075 <= acl_mask: [1] mask: manage(=mwrscxd) 562eb075 => slap_access_allowed: delete access granted by manage(=mwrscxd) 562eb075 => access_allowed: delete access granted by manage(=mwrscxd) 562eb075 => access_allowed: result not in cache (oathFailureCount) 562eb075 => access_allowed: add access to "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de" "oathFailureCount" requested 562eb075 => dn: [5] dc=stroeder,dc=de 562eb075 => acl_get: [5] matched 562eb075 => acl_get: [5] attr oathFailureCount 562eb075 => acl_mask: access to entry "cn=test-hotp-token-42,ou=Testing,dc=stroeder,dc=de", attr "oathFailureCount" requested 562eb075 => acl_mask: to value by "cn=michael ströder+mail=michael(a)stroeder.com,ou=private,dc=stroeder,dc=de", (=0) 562eb075 <= check a_group_pat: cn=slapd admins,ou=groups,dc=stroeder,dc=de 562eb075 <= acl_mask: [1] applying manage(=mwrscxd) (stop) 562eb075 <= acl_mask: [1] mask: manage(=mwrscxd) 562eb075 => slap_access_allowed: add access granted by manage(=mwrscxd) 562eb075 => access_allowed: add access granted by manage(=mwrscxd) 562eb075 acl: internal mod entryCSN: modify access granted 562eb075 acl: internal mod modifiersName: modify access granted 562eb075 acl: internal mod modifyTimestamp: modify access granted 562eb075 mdb_modify_internal: increment oathFailureCount Segmentation fault

1 0

(ITS#8289) slapd seg faults with MOD_INCREMENT on derived attribute
by michael＠stroeder.com 26 Oct '15

26 Oct '15

Full_Name: Version: re24 OS: openSUSE Linux URL: Submission from: (NULL) (213.240.180.113) Attribute type declaration 'bar' with Integer syntax. 'foo' SUP 'bar' makes slapd crash when sending LDAP_MOD_INCREMENT on 'foo'. LDAP_MOD_INCREMENT on 'foo' works if it's not SUP 'bar' but directly declared with Integer syntax.

1 0

Re: (ITS#8216) Windows 'make test' failures
by hyc＠symas.com 26 Oct '15

26 Oct '15

h.b.furuseth(a)usit.uio.no wrote: > On 25/10/15 09:57, hyc(a)symas.com wrote: >> mhardin(a)symas.com wrote: >>> test0-c-concurrency: problems reported by slapd-tester >> > test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 >> >> libtool incompatibility; it leaves shell scripts for the actual tester >> programs in the progs directory, with the real executables under progs/.libs. >> Windows' spawn can't execute shell scripts. Solution is to manually copy the >> real executables from .libs before running the test. >> >> Simple workaround. Won't fix this. > > Does it work to change tests/scripts/defines.sh:PROGDIR to > "./progs/.libs"? If so we just need a test for whether or > not to do that, in configure.in and/or in defines.sh. Tried that, it turned out to not be the problem. Windows just wanted the .exe suffix on the command names. Fixed now in master. -- -- 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#8274) Review lmdb cyrus-sasl backend changes
by nacho.resa＠gmail.com 26 Oct '15

26 Oct '15

--f46d04218485a9382e0522fea6a1 Content-Type: text/plain; charset=UTF-8 Done: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2015-October/002846.html On Mon, Oct 26, 2015 at 10:06 AM, Howard Chu <hyc(a)symas.com> wrote: > nacho.resa(a)gmail.com wrote: > >> Full_Name: Ignacio Casal Quinteiro >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (89.202.223.30) >> >> >> Hi Howard Chu, >> >> since you made the backend for cyrus-sasl, any chance you could review the >> patches here: >> https://github.com/nice-software/cyrus-sasl/commits/wip/lmdb >> before they get upstream? >> > > Patches for Cyrus SASL should be discussed on the Cyrus SASL mailing list. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Ignacio Casal Quinteiro --f46d04218485a9382e0522fea6a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Done: <a href=3D"http://lists.andrew.cmu.edu/pipermail/cyr= us-sasl/2015-October/002846.html">http://lists.andrew.cmu.edu/pipermail/cyr= us-sasl/2015-October/002846.html</a><br></div><div class=3D"gmail_extra"><b= r><div class=3D"gmail_quote">On Mon, Oct 26, 2015 at 10:06 AM, Howard Chu <= span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc= @symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href= =3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nacho.resa(a)gmail.com</a>= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Ignacio Casal Quinteiro<br> Version:<br> OS:<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" target= =3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> Submission from: (NULL) (89.202.223.30)<br> <br> <br> Hi Howard Chu,<br> <br> since you made the backend for cyrus-sasl, any chance you could review the<= br> patches here: <a href=3D"https://github.com/nice-software/cyrus-sasl/commit= s/wip/lmdb" rel=3D"noreferrer" target=3D"_blank">https://github.com/nice-so= ftware/cyrus-sasl/commits/wip/lmdb</a><br> before they get upstream?<br> </blockquote> <br> Patches for Cyrus SASL should be discussed on the Cyrus SASL mailing list.<= span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas= s=3D"gmail_signature">Ignacio Casal Quinteiro</div> </div> --f46d04218485a9382e0522fea6a1--

1 0

Re: (ITS#8274) Review lmdb cyrus-sasl backend changes
by hyc＠symas.com 26 Oct '15

26 Oct '15

nacho.resa(a)gmail.com wrote: > Full_Name: Ignacio Casal Quinteiro > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.202.223.30) > > > Hi Howard Chu, > > since you made the backend for cyrus-sasl, any chance you could review the > patches here: https://github.com/nice-software/cyrus-sasl/commits/wip/lmdb > before they get upstream? Patches for Cyrus SASL should be discussed on the Cyrus SASL mailing list. -- -- 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#8270) win32: fix conversion error
by nacho.resa＠gmail.com 26 Oct '15

26 Oct '15

--f46d042184850fb03c0522fcd987 Content-Type: text/plain; charset=UTF-8 Howard, any chance to get this in or should I change something else? Also, any chance you could have a look at "ITS#8274"? Thanks in advance! On Tue, Oct 20, 2015 at 10:37 PM, Ignacio Casal Quinteiro < nacho.resa(a)gmail.com> wrote: > > > On Tue, Oct 20, 2015 at 10:09 PM, Howard Chu <hyc(a)symas.com> wrote: > >> nacho.resa(a)gmail.com wrote: >> >>> --047d7bb03a5ac118d20522842ead >>> Content-Type: text/plain; charset=UTF-8 >>> >>> So I took another closer look at this issue and I went for this possible >>> solution: >>> >>> https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… >>> >> >> That looks OK. >> >> Basically it errors out because MSVC needs stdcall on that method. >>> >> >> You realize of course, that this change actually has no effect on the >> code here? stdcall uses Pascal argument order instead of C order but it's >> moot since the function only has 1 argument. >> > > yeah... but if this fixes the error I am fine with it, after all it end > ups being just a define > > >> >> >>> Cheers. >>> >>> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro < >>> nacho.resa(a)gmail.com> wrote: >>> >>> Sorry! I did indeed meant to change just the windows part, for some >>>> reason >>>> I thought it was already ifdeffed that part. >>>> >>>> >>>> https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… >>>> >>>> This is the right patch. >>>> >>>> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < >>>> h.b.furuseth(a)usit.uio.no> wrote: >>>> >>>> On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: >>>>> >>>>> I do not understand, I tested also with mingw64 (...) >>>>>> >>>>>> >>>>> There's no LPTHREAD_START_ROUTINE type on non-Windows machines. >>>>> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' >>>>> in the _WIN32 variant of '#define THREAD_CREATE...'. >>>>> >>>>> However, it's still wrong to call a function via another prototype. >>>>> Maybe that'd fall on 32-bit Windows or something, I don't know >>>>> how LPTHREAD_START_ROUTINE is defined. The safe way would be to >>>>> give mdb_env_copythr() a prototype which does not need a cast. >>>>> There is some code for that already. Maybe it can be improved. >>>>> >>>>> -- >>>>> Hallvard >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ignacio Casal Quinteiro >>>> >>>> >>> >>> >>> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > > > -- > Ignacio Casal Quinteiro > -- Ignacio Casal Quinteiro --f46d042184850fb03c0522fcd987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Howard, any chance to get this in or should I ch= ange something else?<br></div>Also, any chance you could have a look at &qu= ot;ITS#8274"?<br><br></div>Thanks in advance!<br></div><div class=3D"g= mail_extra"><br><div class=3D"gmail_quote">On Tue, Oct 20, 2015 at 10:37 PM= , Ignacio Casal Quinteiro <span dir=3D"ltr"><<a href=3D"mailto:nacho.res= a(a)gmail.com" target=3D"_blank">nacho.resa(a)gmail.com</a>></span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_e= xtra"><br><div class=3D"gmail_quote"><span class=3D"">On Tue, Oct 20, 2015 = at 10:09 PM, Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.c= om" target=3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"><a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">= nacho.resa(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --047d7bb03a5ac118d20522842ead<br> Content-Type: text/plain; charset=3DUTF-8<span><br> <br> So I took another closer look at this issue and I went for this possible<br= > solution:<br> <a href=3D"https://github.com/nice-software/lmdb/commit/03987789735141dc68a= e8b2d0e5ad52d82cc80d0" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0</a><= br> </span></blockquote> <br> That looks OK.<span><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Basically it errors out because MSVC needs stdcall on that method.<br> </blockquote> <br></span> You realize of course, that this change actually has no effect on the code = here? stdcall uses Pascal argument order instead of C order but it's mo= ot since the function only has 1 argument.<span><br></span></blockquote><di= v><br></div></span><div>yeah... but if this fixes the error I am fine with = it, after all it end ups being just a define<br></div><div><div class=3D"h5= "><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><span> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Cheers.<br> <br> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro <<br> <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nacho.resa(a)gmail.= com</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Sorry! I did indeed meant to change just the windows part, for some reason<= br> I thought it was already ifdeffed that part.<br> <br> <a href=3D"https://github.com/nice-software/lmdb/commit/42577fe173923c1166f= 8382a53523a31479f9d43" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a31479f9d43</a><= br> <br> This is the right patch.<br> <br> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth <<br> <a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth@= usit.uio.no</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 19. okt. 2015 08:57, <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_= blank">nacho.resa(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do not understand, I tested also with mingw64 (...)<br> <br> </blockquote> <br> There's no LPTHREAD_START_ROUTINE type on non-Windows machines.<br> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)= '<br> in the _WIN32 variant of '#define THREAD_CREATE...'.<br> <br> However, it's still wrong to call a function via another prototype.<br> Maybe that'd fall on 32-bit Windows or something, I don't know<br> how LPTHREAD_START_ROUTINE is defined.=C2=A0 The safe way would be to<br> give mdb_env_copythr() a prototype which does not need a cast.<br> There is some code for that already. Maybe it can be improved.<br> <br> --<br> Hallvard<br> <br> </blockquote> <br> <br> <br> --<br> Ignacio Casal Quinteiro<br> <br> </blockquote> <br> <br> <br> </blockquote> <br> <br> -- <br></span><div><div> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </div></div></blockquote></div></div></div><span class=3D"HOEnZb"><font col= or=3D"#888888"><br><br clear=3D"all"><br>-- <br><div>Ignacio Casal Quinteir= o</div> </font></span></div></div> </blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig= nature">Ignacio Casal Quinteiro</div> </div> --f46d042184850fb03c0522fcd987--

1 0

(ITS#8288) Asyncronous Disconnect Handlers Not Firing
by jeremyc＠ssimicro.com 26 Oct '15

26 Oct '15

Full_Name: Jeremy Childs Version: 2.4.42 OS: FreeBSD/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.247.138.35) Im seeing an issue with async reconnects in libldap 2.4.42 - when the remote server disconnects unexpectedly and there are requests in the queue, request.c:196 calls ldap_free_connection with the force parameter set to 0. Since apap_free_connection wont actually free anything (or call the disconnect handler) until the refcount is zero, nothing happens. Testing with the force parameter set to 1 addresses the issue, the pending requests get freed, and the connection itself frees, calling the disconnect handler in the process.

1 0

Re: (ITS#8216) Windows 'make test' failures
by h.b.furuseth＠usit.uio.no 25 Oct '15

25 Oct '15

On 25/10/15 09:57, hyc(a)symas.com wrote: > mhardin(a)symas.com wrote: >> test0-c-concurrency: problems reported by slapd-tester > > test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 > > libtool incompatibility; it leaves shell scripts for the actual tester > programs in the progs directory, with the real executables under progs/.libs. > Windows' spawn can't execute shell scripts. Solution is to manually copy the > real executables from .libs before running the test. > > Simple workaround. Won't fix this. Does it work to change tests/scripts/defines.sh:PROGDIR to "./progs/.libs"? If so we just need a test for whether or not to do that, in configure.in and/or in defines.sh.

1 0

Re: (ITS#8216) Windows 'make test' failures
by h.b.furuseth＠usit.uio.no 25 Oct '15

25 Oct '15

On 25/10/15 09:57, hyc(a)symas.com wrote: >> test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes > > Attribute ordering, the replicated data is correct. Won't fix this. Sounds like you can just replace "$LDIFFILTER -s bdb=a,hdb=a" with "$LDIFFILTER -s a" or add ",mdb=a".

1 0

Re: (ITS#8204) rfc2782 shuffle implementation doesn't treat equal-weight records equally
by hyc＠symas.com 25 Oct '15

25 Oct '15

Sergio.Gelato(a)astro.su.se wrote: > Full_Name: Sergio Gelato > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.225.123.9) > > > As currently implemented (since ITS#7027, > 5de85b922aaa5bfa6eb53db6000adf01ebdb0736) the algorithm to shuffle DNS SRV > records of a given priority according to their weights is flawed: if all records > have the same weight, the implementation is biased towards the first record and > against the last. In the most extreme case of two records of weight 1, the > current implementation will never swap them (whereas one would have hoped for a > swap 50% of the time). The problem can be cured by changing (r <= 0) to (r < 0). > (The wording of the RFC may have contributed to this error; I suspect it was > written with real random deviates in mind, not integer ones. In any event, the > principle that records of equal weight should have the same probability of being > picked trumps the RFC since the latter only says what algorithm SHOULD be > used.) > > I've written and tested a patch for this and found it to solve the above > problem. My patch also addresses another (operationally minor, which is why I'm > not reporting it separately) issue in the same piece of code: what if at least > two, but not all, of the records of a given priority have weight zero? One > should be prepared to switch to a Fisher-Yates shuffle if "total" becomes zero > during the iteration. > > (Yet another potential issue is overflow of "total" on platforms where > INT_MAX==32767 if the sum of the weights exceeds that value. Consider declaring > it uint32_t or u_long.) I see no patch nor URL. -- -- 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#8194) Service slapd falldown in a search with client ldapsearch
by hyc＠symas.com 25 Oct '15

25 Oct '15

richard.larrieu-manan(a)cgi.com wrote: > Ok. > > Here is the command line to do the research with the client ldapsearch : > /opt/openldap/bin/ldapsearch -xLLL -h ldapp02 -p 389 -D cn=3Dadmin,ou=3Dsys= > tem,dc=3Dent,dc=3Dfr -b ou=3Dsupp,ou=3Dpersonnes,ou=3DCRRA,dc=3Dent,dc=3Dfr= > -w jungle dn | wc -l > > After 1 or 2 search the slapd server goes. I believe this was fixed as ITS#8203 in 2.4.42. Please try that and followup again, thanks. > > Thx. > > -----Message d'origine----- > De=A0: Michael Str=F6der [mailto:michael@stroeder.com]=20 > Envoy=E9=A0: vendredi 10 juillet 2015 12:35 > =C0=A0: LARRIEU-MANAN, Richard; openldap-its(a)OpenLDAP.org > Objet=A0: Re: (ITS#8194) Service slapd falldown in a search with client lda= > psearch > > Maybe I missed something but I can't which search requests are causing this= > . > > Could you please also add some information about your ldapsearch commands? > > Ciao, Michael. > > > > -- -- 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#8191) mdb_txn_commit(empty txn) does not sync
by hyc＠symas.com 25 Oct '15

25 Oct '15

h.b.furuseth(a)usit.uio.no wrote: > On 07/07/15 21:44, h.b.furuseth(a)usit.uio.no wrote: >> My feeling is that this is a quirk the user should not need to >> know about, and it's cleaner to sy r rather than to document it. > > ...cleaner to sync rather than... The doc should say that committing an empty txn is a no-op. If you want to do a sync without writing data, use mdb_env_sync() yourself. -- -- 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#8205)
by hyc＠symas.com 25 Oct '15

25 Oct '15

peter(a)adpm.de wrote: > Hi, > > I extended the patch series with a manual page for pbkdf2 > * https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f649ca… > contrib/passwd/pbkdf2: add man page, install it too Please use format-patch to submit patches, thanks. -- -- 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#8211) ssf does not reflect actual security of connection
by hyc＠symas.com 25 Oct '15

25 Oct '15

hkario(a)redhat.com wrote: > Full_Name: Hubert Kario > Version: all > OS: Linux > URL: > Submission from: (NULL) (213.175.37.10) > > > Section "14.2.1. Security Strength Factors"[1] states "A SSF greater than one > (>1) roughly correlates to the effective encryption key length.". This is not > the case more often than not. > > Problem is that ssf as it is calculated now doesn't take into consideration > all the cryptographic primitives in use. > > In other words, a connection that uses a 512 bit RSA certificates and > negotiates TLS_RSA_WITH_AES_128_CBC_SHA (AES256-SHA) certainly does not > provide security equivalent to "modern strong ciphers"[2][3] and should be > awarded "256". > > Similarly a connection that uses 512 bit DH parameters and negotiates > TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DHE-RSA-AES256-SHA) does not provide > security that should be awarded "256"[5]. > > In fact, recommending use of high key sizes[2] will cause the connection to > use _less_ secure CBC ciphersuites[5] with clients that support AEAD > ciphersuites with AES-128 only (like Thunderbird and Firefox do). > > Section 8.4.9[2] also calls RC4 a "modern strong cipher", most cryptographers > disagree[6]. > > > So I think either: > 1). ssf needs to be redefined to consider any value higher that "2" to be > equal, and requiring the server administrators to enable only > ciphersuites they consider secure, or > 2). the whole code that calculates ssf needs to be updated to take into > account many more things: > * use of AEAD > * use of Encrypt-then-MAC > * the protocol version used (both because TLS1.0 specific attacks[7] as > wewell as the use of SHA1+MD5 for signatures which limits the connection > security to 80 bits[8] (optimistically) if client certificates are in > use in TLS < 1.2) > * encryption algorithm on session tickets > * current state of attacks on a given ciphersuite > * the size of ECDHE curve, FFDHE prime or server certificate key size, > depending on ciphersuite negotiated > * the signature algorithm used in Certificate Verify message > * the key size of client certificate > * the signature on the client certificate and key sizes in CA > certificates > * the HMAC used > * key size of the symmetric cipher > * (probably other things I didn't think about) > > 1 - http://www.openldap.org/doc/admin24/security.html > 2 - http://w.w.openldap.org/doc/admin24/access-control.html section 8.4.9 > 3 - https://freakattack.com/ > 4 - https://weakdh.org/ > 5 - http://www.isg.rhul.ac.uk/tls/Lucky13.html > 6 - https://tools.ietf.org/html/rfc7465 > 7 - https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack > 8 - https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf Patch welcome. Either a doc patch describing your option (1) or a code patch for your (2). Note that SSF generally comes to us from SASL, so a code patch most likely needs to be submitted to the Cyrus-SASL Project, not us. Overall the definition of SSF has been in use in the industry for many years; it's not something we created or control. Changing the description or definition of it likely needs to also happen elsewhere. -- -- 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#8114) [WIP] WiredTiger Backend for OpenLDAP
by hyc＠symas.com 25 Oct '15

25 Oct '15

HAMANO Tsukasa wrote: > Thanks for merging. > Also I've added LDAP MODIFY. > Please merge the patches: > https://www.osstech.co.jp/download/hamano/openldap/0007-suppress-warn-messa… > https://www.osstech.co.jp/download/hamano/openldap/0008-LDAP-MODIFY-handlin… Added in master. -- -- 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#8215) Slapmodify delete support and documentation
by hyc＠symas.com 25 Oct '15

25 Oct '15

ondra(a)mistotebe.net wrote: > Full_Name: Ond&#345;ej Kuzn.k > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150811-slapmodify-delete-su… > Submission from: (NULL) (62.84.155.99) > > > It is only possible to delete entries in a back-ldif database. This patchset > implements the equivalent functionality in the other core databases, enables the > same in back-config and adds a slapmodify manpage. With that in place, > test007-slapmodify is switched to fail on errors now. ModRDN stays unimplemented > at this point. > > An outstanding issue is that valgrind complains about a memory leak in bdb on > entry delete, which I have not been able to pinpoint nor fix. Thanks. Committed to master. We'll keep this ITS open until the leak is fixed. > > The above patch is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the above patches were > developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned > rights and/or interest in this work to any party. > > I, Ondřej Kuzník, hereby place the above modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. > > -- -- 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#8216) Windows 'make test' failures
by hyc＠symas.com 25 Oct '15

25 Oct '15

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.40 > OS: Windows 7/64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.43.206.100) > > > Many 'make test' test fail, for a variety of reasons, with LMDB and BDB/HDB > backends. > > OpenLDAP 2.4.40 > Berkeley DB 4.8.30 > > > Environment: > MSYS from MinGW/MSYS 2013072300 > Win-Builds MinGW 32- and 64-bit toolchain > > The following tests fail: > test0-c-concurrency: problems reported by slapd-tester > test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 libtool incompatibility; it leaves shell scripts for the actual tester programs in the progs directory, with the real executables under progs/.libs. Windows' spawn can't execute shell scripts. Solution is to manually copy the real executables from .libs before running the test. Simple workaround. Won't fix this. > test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes Attribute ordering, the replicated data is correct. Won't fix this. > test049-sync-config: config parsing problems > test050-syncrepl-multimaster: config parsing problems Fixed as ITS#8273 > test056-monitor: incorrect monitor output Fixed as ITS#8280 > test058-syncrepl-asymmetric: parsing problems > test059-slave-config: parsing problems > test061-syncreplication-initiation: parsing prlelems > test063-delta-multimaster: undetermined > test064-constraint: include file processing (parsing?) All ITS#8273. Closing this ITS. -- -- 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#8237) Crash with MDB_MAXKEYSIZE=1500
by hyc＠symas.com 25 Oct '15

25 Oct '15

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root(): > > The paste got munged. Test program at > <ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150906.c>. Fixed. -- -- 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#8267) contributing a new overlay unicodepw
by hyc＠symas.com 25 Oct '15

25 Oct '15

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. 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. This code cannot be accepted in its current form. -- -- 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#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com 24 Oct '15

24 Oct '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> hyc(a)symas.com wrote: >>>> Michael Ströder wrote: >>>>> hyc(a)symas.com wrote: >>>>>> Generating a new contextCSN at startup is of questionable worth. We discussed >>>>>> this a bit 'way back in 2004 >>>>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we >>>>>> should just not do it; >>>>> >>>>> +1 >>>>> >>>>>> if a single-master provider starts up empty and a >>>>>> consumer tries to talk to it and both have an empty cookie, the provider >>>>>> should just respond "you're up to date". >>>>> >>>>> Why not return an error to the consumer? >>>> >>>> Typically if a consumer receives an error it will disconnect and retry later. >>>> There's not much point making the consumer reconnect - which may be costly for >>>> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on >>>> and wait for some real data to arrive. >>> >>> Is the cost really that high compared to the rest of the initialization? >> >> I meant "TLS" there. > > As I'm solely using TLS secured LDAP connection *everywhere* I also implied > TLS. Still I assume opening the syncrepl connection a few times again is > nothing compared to the majority LDAP clients opening connections for every > single LDAP simple bind request. So if it simplifies error handling which > likely results in more robustness, I'd strongly prefer that. As it turns out, it greatly simplified things to handle this condition as you suggest. Fixed now in git master. -- -- 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#8287) ldap server address book
by ikshafi＠yahoo.com 23 Oct '15

23 Oct '15

------=_Part_1734554_1852910388.1445610910369 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear=C2=A0Ciao, Michael could you please refer any link ? =C2=A0i can not find anything regarding t= his issue . please ..=C2=A0 =20 On Friday, October 23, 2015 3:10 AM, Michael Str=C3=B6der <michael@str= oeder.com> wrote: =20 ikshafi(a)yahoo.com wrote: > Full_Name: sifat ara nil > Version: 2.4.39 > OS: centros > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.230.63.94) >=20 >=20 > I have create a Ldap server for Email address book purpose .Its running w= ell and > i am able to search by name . But it's not showing all address in microso= ft > outlook address book without search . how can i make it visible .=C2=A0= =20 The ITS is for reporting bugs only. You can ask usage questions on the openldap-technical mailing list. For Outlook try to search for suitable LDAP attribute mappings. It has been discussed numerous times before. Ciao, Michael. ------=_Part_1734554_1852910388.1445610910369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div style=3D"color:#000; background-color:#fff; f= ont-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, = sans-serif;font-size:16px"><div id=3D"yui_3_16_0_1_1445610560158_2897" dir= =3D"ltr"><font face=3D"times new roman, new york, times, serif" id=3D"yui_3= _16_0_1_1445610560158_3048">Dear <span style=3D"font-size: 13px;" id= =3D"yui_3_16_0_1_1445610560158_2920" class=3D"">Ciao, M</span><span style= =3D"font-size: 13px;" class=3D"" id=3D"yui_3_16_0_1_1445610560158_3035"><fo= nt id=3D"yui_3_16_0_1_1445610560158_3034">icha</font></span><span style=3D"= font-size: 13px;" class=3D"">el</span></font></div><div id=3D"yui_3_16_0_1_= 1445610560158_2896"><font face=3D"times new roman, new york, times, serif">= <br></font></div><div dir=3D"ltr" id=3D"yui_3_16_0_1_1445610560158_2921"><f= ont face=3D"times new roman, new york, times, serif" id=3D"yui_3_16_0_1_144= 5610560158_3050">could you please refer any link ?  i can not find any= thing regarding this issue . please .. </font><br></div> <br><div cla= ss=3D"qtdSeparateBR"><br><br></div><div class=3D"yahoo_quoted" style=3D"dis= play: block;"> <div style=3D"font-family: HelveticaNeue, Helvetica Neue, He= lvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style=3D= "font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grand= e, sans-serif; font-size: 16px;"> <div dir=3D"ltr"> <font size=3D"2" face= =3D"Arial"> On Friday, October 23, 2015 3:10 AM, Michael Str=C3=B6der <m= ichael(a)stroeder.com> wrote:<br> </font> </div> <br><br> <div class=3D"y= _msg_container"><a ymailto=3D"mailto:ikshafi@yahoo.com" href=3D"mailto:iksh= afi(a)yahoo.com">ikshafi(a)yahoo.com</a> wrote:<br>> Full_Name: sifat ara ni= l<br>> Version: 2.4.39<br>> OS: centros<br>> URL: <a href=3D"ftp:/= /ftp.openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/incom= ing/</a><br>> Submission from: (NULL) (103.230.63.94)<br>> <br>> <= br>> I have create a Ldap server for Email address book purpose .Its run= ning well and<br>> i am able to search by name . But it's not showing al= l address in microsoft<br>> outlook address book without search . how ca= n i make it visible .  <br><br>The ITS is for reporting bugs only.<br= >You can ask usage questions on the openldap-technical mailing list.<br><br= >For Outlook try to search for suitable LDAP attribute mappings.<br>It has = been discussed numerous times before.<br><br>Ciao, Michael.<br><br><br></di= v> </div> </div> </div></div></body></html> ------=_Part_1734554_1852910388.1445610910369--

1 0

Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by michael＠stroeder.com 23 Oct '15

23 Oct '15

hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> Michael Ströder wrote: >>>> hyc(a)symas.com wrote: >>>>> Generating a new contextCSN at startup is of questionable worth. We discussed >>>>> this a bit 'way back in 2004 >>>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we >>>>> should just not do it; >>>> >>>> +1 >>>> >>>>> if a single-master provider starts up empty and a >>>>> consumer tries to talk to it and both have an empty cookie, the provider >>>>> should just respond "you're up to date". >>>> >>>> Why not return an error to the consumer? >>> >>> Typically if a consumer receives an error it will disconnect and retry later. >>> There's not much point making the consumer reconnect - which may be costly for >>> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on >>> and wait for some real data to arrive. >> >> Is the cost really that high compared to the rest of the initialization? > > I meant "TLS" there. As I'm solely using TLS secured LDAP connection *everywhere* I also implied TLS. Still I assume opening the syncrepl connection a few times again is nothing compared to the majority LDAP clients opening connections for every single LDAP simple bind request. So if it simplifies error handling which likely results in more robustness, I'd strongly prefer that. Ciao, Michael.

1 0

Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com 23 Oct '15

23 Oct '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> hyc(a)symas.com wrote: >>>> Generating a new contextCSN at startup is of questionable worth. We discussed >>>> this a bit 'way back in 2004 >>>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we >>>> should just not do it; >>> >>> +1 >>> >>>> if a single-master provider starts up empty and a >>>> consumer tries to talk to it and both have an empty cookie, the provider >>>> should just respond "you're up to date". >>> >>> Why not return an error to the consumer? >> >> Typically if a consumer receives an error it will disconnect and retry later. >> There's not much point making the consumer reconnect - which may be costly for >> a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on >> and wait for some real data to arrive. > > Is the cost really that high compared to the rest of the initialization? I meant "TLS" 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

Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by michael＠stroeder.com 23 Oct '15

23 Oct '15

hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> Generating a new contextCSN at startup is of questionable worth. We discussed >>> this a bit 'way back in 2004 >>> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we >>> should just not do it; >> >> +1 >> >>> if a single-master provider starts up empty and a >>> consumer tries to talk to it and both have an empty cookie, the provider >>> should just respond "you're up to date". >> >> Why not return an error to the consumer? > > Typically if a consumer receives an error it will disconnect and retry later. > There's not much point making the consumer reconnect - which may be costly for > a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on > and wait for some real data to arrive. Is the cost really that high compared to the rest of the initialization? >> Does the provider know whether it's running as single-master? > > Generally yes. A single-master setup has serverID=0. Hmm, this introduces more semantics on serverID. I have some doubts about corner-cases. Maybe I misunderstood but IMO the issue was about changing a provider to a MMR replica which would need serverID!=0 anyway. Ciao, Michael.

1 0

Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com 23 Oct '15

23 Oct '15

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Generating a new contextCSN at startup is of questionable worth. We discussed >> this a bit 'way back in 2004 >> http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we >> should just not do it; > > +1 > >> if a single-master provider starts up empty and a >> consumer tries to talk to it and both have an empty cookie, the provider >> should just respond "you're up to date". > > Why not return an error to the consumer? Typically if a consumer receives an error it will disconnect and retry later. There's not much point making the consumer reconnect - which may be costly for a TCP session. If it's a refreshAndPersist consumer, it just needs to hang on and wait for some real data to arrive. > Does the provider know whether it's running as single-master? Generally yes. A single-master setup has serverID=0. -- -- 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#8281) Syncrepl refresh failure when slapd is restarted midstream
by michael＠stroeder.com 23 Oct '15

23 Oct '15

This is a cryptographically signed message in MIME format. --------------ms040207060304010508030608 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > Generating a new contextCSN at startup is of questionable worth. We dis= cussed=20 > this a bit 'way back in 2004=20 > http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perha= ps we=20 > should just not do it; +1 > if a single-master provider starts up empty and a=20 > consumer tries to talk to it and both have an empty cookie, the provide= r=20 > should just respond "you're up to date". Why not return an error to the consumer? Does the provider know whether it's running as single-master? Ciao, Michael. --------------ms040207060304010508030608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTAyMzA2MTIxMlowLwYJKoZIhvcNAQkEMSIEIJ1bOIoAw+/k1uuBzuvpmtdm9eMbylsfYVQJ +up45kF5MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBMHz+sfRalN5J1irhn M18JNKr1bgzkIZSQEXt1Qmpfn35F8KsflZ38NBUKlX/N+WuyyuV3FnGCge3gY3w9aerdQ0W6 fGH77h6KZdNcFvYA8iAqVqn1GmxVqI5jovL9VuPHbfVHpqkdCOFMrhryefvnMUg25M6iPyxj Bu6KVnLh+JXZn1kpxqhkl7hFdLfLbXQL9pNLmw11L8UjHCNffvvfzBKNjxn4d3Ube4YV/etz PL41Ceg7/uTx8P6qI3Hhh2hVBRVaO3J84GLLOnoHIrEXnfUhkRNM1ST30MNWgtN3ng0+LCDE oBXKt5qEM0g9MWVtZpvRzsEj+DhAh+wzkfhcAAAAAAAA --------------ms040207060304010508030608--

1 0

Re: (ITS#8281) Syncrepl refresh failure when slapd is restarted midstream
by hyc＠symas.com 23 Oct '15

23 Oct '15

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 Sept 11, 2015 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > Seeing a scenario where if slapd is stopped on a new MMR node while a full > REFRESH is occurring, the state of that refresh is not tracked, and the wrong > CSN value is stored. > This dataset has 15,000 users. We see it get up to user 625: > > Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_search (0) > Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 > uid=user625,ou=people,dc=q1,dc=aon,dc=zimbraview,dc=com > Oct 20 16:13:09 q2 slapd[18724]: slap_queue_csn: queueing 0x44c7e30 > 20151020185526.862768Z#000000#000#000000 > Oct 20 16:13:09 q2 slapd[18724]: slap_graduate_commit_csn: removing 0x44c87c0 > 20151020185526.862768Z#000000#000#000000 > Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_add > uid=user625,ou=people,dc=q2C2Cdc=aon,dc=zimbraview,dc=com (0) > Oct 20 16:13:09 q2 slapd[18724]: slapd stopped. > > > Then when slapd is restarted: > > Oct 20 16:13:16 q2 slapd[18970]: do_syncrep2: rid=100 > cookie=rid=100,sid=001,csn=20151020201231.263989Z#000000#001#000000 > Oct 20 16:13:16 q2 slapd[18970]: sp_p_queue_csn: queueing 0x309dfd8 > 20151020201231.263989Z#000000#001#000000 > Oct 20 16:13:16 q2 slapd[18970]: slap_queue_csn: queueing 0x5054008 > 20151020201231.263989Z#000000#001#000000 > Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x49353c0 > 20151020201231.263989Z#000000#001#000000 > Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x4935060 > 20151020201231.263989Z#000000#001#000000 > Oct 20 16:13:16 q2 slapd[18970]: syncrepl_message_to_op: rid=100 be_add > cn=q2.aon.zimbraview.com,cn=servers,cn=zimbra (0) > > which causes it to skip the other 14,000+ users. After investigating the server setup, there are a few problems here. The new server was being configured with sid=001 which was already assigned to the original master. That's clearly going to screw things up. Aside from that, the new server was converted to MMR using dynamic config and we have a sequencing problem - it adds the syncprov overlay first, and then adds the syncrepl config. This is actually the only safe order, since the consumer will start as soon as it's added and syncprov will already be in place, ready to propagate changes as needed. But .. syncprov does a check in syncprov_db_open() to decide whether it should generate an initial contextCSN on a new DB. This step is ignored if the backend is configured for MMR (and must be ignored). The problem is that this node *will be* configured for MMR, but it isn't yet, because the consumer hasn't been dynamically configured yet. So syncprov generates its own contextCSN, which is checkpointed on shutdown. The real contextCSN from the master hasn't been received yet since the refresh is still in progress when the server is stopped, so on next restart this consumer will present its generated contextCSN, which is newer than the original master's, and so it won't resume refreshing from where it left off. Generating a new contextCSN at startup is of questionable worth. We discussed this a bit 'way back in 2004 http://www.openldap.org/lists/openldap-devel/200408/msg00035.html Perhaps we should just not do it; if a single-master provider starts up empty and a consumer tries to talk to it and both have an empty cookie, the provider should just respond "you're up to date". -- -- 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#8287) ldap server address book
by michael＠stroeder.com 22 Oct '15

22 Oct '15

ikshafi(a)yahoo.com wrote: > Full_Name: sifat ara nil > Version: 2.4.39 > OS: centros > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.230.63.94) > > > I have create a Ldap server for Email address book purpose .Its running well and > i am able to search by name . But it's not showing all address in microsoft > outlook address book without search . how can i make it visible . The ITS is for reporting bugs only. You can ask usage questions on the openldap-technical mailing list. For Outlook try to search for suitable LDAP attribute mappings. It has been discussed numerous times before. Ciao, Michael.

1 0

(ITS#8287) ldap server address book
by ikshafi＠yahoo.com 22 Oct '15

22 Oct '15

Full_Name: sifat ara nil Version: 2.4.39 OS: centros URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.230.63.94) I have create a Ldap server for Email address book purpose .Its running well and i am able to search by name . But it's not showing all address in microsoft outlook address book without search . how can i make it visible .

1 0

(ITS#8286) Add missing matching rule for olcMirrorMode
by quanah＠openldap.org 21 Oct '15

21 Oct '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) The olcMirrorMode attribute in cn=config is missing an EQUALITY matching rule, which breaks the ability to use it for ldapcompare and other operations. That should be fixed.

1 0

Re: (ITS#8285) RFE slapo-ppolicy: fall back to createTimestamp
by hyc＠symas.com 21 Oct '15

21 Oct '15

michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: > OS: > URL: > Submission from: (NULL) (213.240.180.113) > > > If pwdMaxAge is set in a pwdPolicy entry but the user's entry does not contain > pwdChangedTime attribute createTimestamp should be used instead to determine > whether password is expired or not. > > The case above can happen if there are already existing entries with > userPassword and slapo-ppolicy gets installed and activated later. > No. The spec says for pwdChangedTime "If this attribute does not exist, the password will never expire." Closing this ITS. -- -- 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#8285) RFE slapo-ppolicy: fall back to createTimestamp
by michael＠stroeder.com 21 Oct '15

21 Oct '15

Full_Name: Michael Str.der Version: OS: URL: Submission from: (NULL) (213.240.180.113) If pwdMaxAge is set in a pwdPolicy entry but the user's entry does not contain pwdChangedTime attribute createTimestamp should be used instead to determine whether password is expired or not. The case above can happen if there are already existing entries with userPassword and slapo-ppolicy gets installed and activated later.

1 0

Re: (ITS#8284) back-relay: olcRelay issues with values containing white spaces
by michael＠stroeder.com 21 Oct '15

21 Oct '15

hyc(a)symas.com wrote: >> To reproduce the problem just configure back_relay with a value containing white >> spaces >> (i.e. olcRelay: ou=Dipartimento di Fisica,o=Università degli Studi di >> Milano,c=IT) > > Use double-quotes around arguments containing whitespace. Attribute 'olcRelay' is of LDAP syntax Distinguished Name (1.3.6.1.4.1.1466.115.121.1.12). So your statement is pretty surprising. > Closing this ITS. Really? Ciao, Michael.

1 0

Re: (ITS#8284) back-relay: olcRelay issues with values containing white spaces
by michele.bensi＠fisica.unimi.it 21 Oct '15

21 Oct '15

Well this was the first thing I tried, but when I use olcRelay: "ou=Dipartimento di Fisica,o=Università degli Studi di Milano,c=IT" I got ldap_add: Invalid syntax (21) additional info: olcRelay: value #0 invalid per syntax Then I tried with olcRelay: ou="Dipartimento di Fisica",o="Università degli Studi di Milano",c=IT I had the same error of extra cruft. I solved patching servers/slapd/back-relay/init.c this way --- a/servers/slapd/back-relay/init.c 2015-10-20 15:22:20.511667130 +0200 +++ b/servers/slapd/back-relay/init.c 2015-10-21 10:27:02.649251347 +0200 @@ -32,7 +32,7 @@ static ConfigTable relaycfg[] = { { "relay", "relay", 2, 2, 0, - ARG_MAGIC|ARG_DN, + ARG_MAGIC|ARG_DN|ARG_QUOTE, relay_back_cf, "( OLcfgDbAt:5.1 " "NAME 'olcRelay' " "DESC 'Relay DN' " On Wed, Oct 21, 2015 at 03:12:14PM +0100, Howard Chu wrote: > michele.bensi(a)fisica.unimi.it wrote: > >Full_Name: Michele Bensi > >Version: 2.4.42 > >OS: Linux > >URL: ftp://ftp.openldap.org/incoming/ > >Submission from: (NULL) (159.149.47.246) > > > > > >When configuring realy backend using a relay suffix containg spaces I got this > >error: > > > >ldap_add: Constraint violation (19) > > additional info: <olcRelay> extra cruft after <relay> > >A%A > >To reproduce the problem just configure back_relay with a value containing white > >spaces > >(i.e. olcRelay: ou=Dipartimento di Fisica,o=Università degli Studi di > >Milano,c=IT) > > Use double-quotes around arguments containing whitespace. > > Closing this ITS. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Michele Bensi Unità Calcolo Dipartimento di Fisica Università degli Studi di Milano Via Celoria, 16 20133 Milano (MI) ITALY Phone: +39 02503 17341 Fax: +39 02503 17280 Room: I/T/4 "Unix is user-friendly. It's just very selective about who its friends are."

1 0

Re: (ITS#8284) back-relay: olcRelay issues with values containing white spaces
by hyc＠symas.com 21 Oct '15

21 Oct '15

michele.bensi(a)fisica.unimi.it wrote: > Full_Name: Michele Bensi > Version: 2.4.42 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (159.149.47.246) > > > When configuring realy backend using a relay suffix containg spaces I got this > error: > > ldap_add: Constraint violation (19) > additional info: <olcRelay> extra cruft after <relay> > A%A > To reproduce the problem just configure back_relay with a value containing white > spaces > (i.e. olcRelay: ou=Dipartimento di Fisica,o=Università degli Studi di > Milano,c=IT) Use double-quotes around arguments containing whitespace. Closing this ITS. -- -- 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#8284) back-relay: olcRelay issues with values containing white spaces
by michele.bensi＠fisica.unimi.it 21 Oct '15

21 Oct '15

Full_Name: Michele Bensi Version: 2.4.42 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (159.149.47.246) When configuring realy backend using a relay suffix containg spaces I got this error: ldap_add: Constraint violation (19) additional info: <olcRelay> extra cruft after <relay> A%A To reproduce the problem just configure back_relay with a value containing white spaces (i.e. olcRelay: ou=Dipartimento di Fisica,o=Università degli Studi di Milano,c=IT)

1 0

(ITS#8283) Incomplete documentation
by hadmut＠danisch.de 21 Oct '15

21 Oct '15

Full_Name: Hadmut Danisch Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.145.25.4) Hi, the openssl docs as http://www.openldap.org/doc/admin24/access-control.html describe the syntax of access rules in detail, but not as much about semantics. There is an access right "manage", but no description about what this is good for beyond reading and writing. According to Google, noone has ever asked, what this is good for. regards

1 0

(ITS#8282) WEB: Devel/tools page is out of date
by hyc＠openldap.org 21 Oct '15

21 Oct '15

Full_Name: Howard Chu Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.14) Submitted by: hyc http://www.openldap.org/devel/tools.html Still points to BerkeleyDB at www.sleepycat.com - this whole section should probably just be deleted now. I was looking on this page because I was wondering if we listed the Windows build tools. We should probably add links for MSYS/MinGW/MinGW64. I don't think anyone has used ePerl in ages. We haven't been on FreeBSD for a couple of years now. We haven't been using sendmail for years.

1 0

Re: (ITS#8270) win32: fix conversion error
by hyc＠symas.com 21 Oct '15

21 Oct '15

Леонид Юрьев wrote: > 2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com <mailto:hyc@symas.com>>: > > nacho.resa(a)gmail.com <mailto:nacho.resa@gmail.com> wrote: > > --047d7bb03a5ac118d20522842ead > > Content-Type: text/plain; charset=UTF-8 > > > > So I took another closer look at this issue and I went for this possible > > solution: > > > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… > > That looks OK. > > > Basically it errors out because MSVC needs stdcall on that method. > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > No, there is another important difference: > cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N); > stdcall = the callee is responsible to clean stack from args (e.g. retn N); True, but not relevant here. This is a ThreadProc, and threads never return to their caller. Windows implicitly calls ExitThread() when this function returns, and the stack will be destroyed anyway. -- -- 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#8281) Syncrepl refresh failure when slapd is restarted midstream
by quanah＠openldap.org 21 Oct '15

21 Oct '15

Full_Name: Quanah Gibson-Mount Version: RE24 Sept 11, 2015 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) Seeing a scenario where if slapd is stopped on a new MMR node while a full REFRESH is occurring, the state of that refresh is not tracked, and the wrong CSN value is stored. This dataset has 15,000 users. We see it get up to user 625: Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_search (0) Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 uid=user625,ou=people,dc=q1,dc=aon,dc=zimbraview,dc=com Oct 20 16:13:09 q2 slapd[18724]: slap_queue_csn: queueing 0x44c7e30 20151020185526.862768Z#000000#000#000000 Oct 20 16:13:09 q2 slapd[18724]: slap_graduate_commit_csn: removing 0x44c87c0 20151020185526.862768Z#000000#000#000000 Oct 20 16:13:09 q2 slapd[18724]: syncrepl_entry: rid=100 be_add uid=user625,ou=people,dc=q2C2Cdc=aon,dc=zimbraview,dc=com (0) Oct 20 16:13:09 q2 slapd[18724]: slapd stopped. Then when slapd is restarted: Oct 20 16:13:16 q2 slapd[18970]: do_syncrep2: rid=100 cookie=rid=100,sid=001,csn=20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: sp_p_queue_csn: queueing 0x309dfd8 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: slap_queue_csn: queueing 0x5054008 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x49353c0 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: slap_graduate_commit_csn: removing 0x4935060 20151020201231.263989Z#000000#001#000000 Oct 20 16:13:16 q2 slapd[18970]: syncrepl_message_to_op: rid=100 be_add cn=q2.aon.zimbraview.com,cn=servers,cn=zimbra (0) which causes it to skip the other 14,000+ users.

1 0

(ITS#8280) test056 fails due to EOL differences
by hyc＠openldap.org 21 Oct '15

21 Oct '15

Full_Name: Howard Chu Version: 2.4 OS: Win32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.14) Submitted by: hyc The 2nd comparison in test056 diffs ldapsearch output against the static testdata/monitor2.out file. The output from ldapsearch contains DOS \r\n EOLs while the static file contains Unix \n EOLs and so the diff fails. In all the tests up to this point, comparisons are always between equally processed files, instead of 1 processed file and 1 static file, so there were no EOL differences to contend with.

1 0

Re: (ITS#8270) win32: fix conversion error
by leo＠yuriev.ru 20 Oct '15

20 Oct '15

2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com>: > > nacho.resa(a)gmail.com wrote: > > --047d7bb03a5ac118d20522842ead > > Content-Type: text/plain; charset=UTF-8 > > > > So I took another closer look at this issue and I went for this possible > > solution: > > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… > > That looks OK. > > > Basically it errors out because MSVC needs stdcall on that method. > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > Oops, sorry (dummy gmail...). No, there is another important difference: cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N); stdcall = the callee is responsible to clean stack from args (e.g. retn N);

1 0

Re: (ITS#8270) win32: fix conversion error
by leo＠yuriev.ru 20 Oct '15

20 Oct '15

--001a11c23788b1353405228fbfbd Content-Type: text/plain; charset=UTF-8 2015-10-20 23:09 GMT+03:00 <hyc(a)symas.com>: > nacho.resa(a)gmail.com wrote: > > --047d7bb03a5ac118d20522842ead > > Content-Type: text/plain; charset=UTF-8 > > > > So I took another closer look at this issue and I went for this possible > > solution: > > > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… > > That looks OK. > > > Basically it errors out because MSVC needs stdcall on that method. > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > > No, there is another important difference: cdecl = the caller is responsible to clean stack from args (e.g. addl esp, N); stdcall = the callee is responsible to clean stack from args (e.g. retn N); --001a11c23788b1353405228fbfbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015= -10-20 23:09 GMT+03:00 <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.c= om" target=3D"_blank">hyc(a)symas.com</a>></span>:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde= r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><a = href=3D"mailto:nacho.resa@gmail.com">nacho.resa(a)gmail.com</a> wrote:<br> > --047d7bb03a5ac118d20522842ead<br> > Content-Type: text/plain; charset=3DUTF-8<br> ><br> > So I took another closer look at this issue and I went for this possib= le<br> > solution:<br> > <a href=3D"https://github.com/nice-software/lmdb/commit/03987789735141= dc68ae8b2d0e5ad52d82cc80d0" rel=3D"noreferrer" target=3D"_blank">https://gi= thub.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0= </a><br> <br> That looks OK.<br> <br> > Basically it errors out because MSVC needs stdcall on that method.<br> <br> You realize of course, that this change actually has no effect on the code<= br> here? stdcall uses Pascal argument order instead of C order but it's mo= ot<br> since the function only has 1 argument.<br> <br></blockquote><div><br><div>No, there is another important difference:</= div><div>cdecl =3D the caller is responsible to clean stack from args (e.g.= addl esp, N);</div>stdcall =3D the callee is responsible to clean stack fr= om args (e.g. retn N);=C2=A0</div></div></div></div> --001a11c23788b1353405228fbfbd--

1 0

Re: (ITS#8270) win32: fix conversion error
by nacho.resa＠gmail.com 20 Oct '15

20 Oct '15

--f46d043895179821ec05228f3c91 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 20, 2015 at 10:09 PM, Howard Chu <hyc(a)symas.com> wrote: > nacho.resa(a)gmail.com wrote: > >> --047d7bb03a5ac118d20522842ead >> Content-Type: text/plain; charset=UTF-8 >> >> So I took another closer look at this issue and I went for this possible >> solution: >> >> https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… >> > > That looks OK. > > Basically it errors out because MSVC needs stdcall on that method. >> > > You realize of course, that this change actually has no effect on the code > here? stdcall uses Pascal argument order instead of C order but it's moot > since the function only has 1 argument. > yeah... but if this fixes the error I am fine with it, after all it end ups being just a define > > >> Cheers. >> >> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro < >> nacho.resa(a)gmail.com> wrote: >> >> Sorry! I did indeed meant to change just the windows part, for some reason >>> I thought it was already ifdeffed that part. >>> >>> >>> https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… >>> >>> This is the right patch. >>> >>> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < >>> h.b.furuseth(a)usit.uio.no> wrote: >>> >>> On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: >>>> >>>> I do not understand, I tested also with mingw64 (...) >>>>> >>>>> >>>> There's no LPTHREAD_START_ROUTINE type on non-Windows machines. >>>> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' >>>> in the _WIN32 variant of '#define THREAD_CREATE...'. >>>> >>>> However, it's still wrong to call a function via another prototype. >>>> Maybe that'd fall on 32-bit Windows or something, I don't know >>>> how LPTHREAD_START_ROUTINE is defined. The safe way would be to >>>> give mdb_env_copythr() a prototype which does not need a cast. >>>> There is some code for that already. Maybe it can be improved. >>>> >>>> -- >>>> Hallvard >>>> >>>> >>> >>> >>> -- >>> Ignacio Casal Quinteiro >>> >>> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Ignacio Casal Quinteiro --f46d043895179821ec05228f3c91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Tue, Oct 20, 2015 at 10:09 PM, Howard Chu <span dir=3D"ltr"><<a h= ref=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:nacho.resa@gmai= l.com" target=3D"_blank">nacho.resa(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --047d7bb03a5ac118d20522842ead<br> Content-Type: text/plain; charset=3DUTF-8<span class=3D""><br> <br> So I took another closer look at this issue and I went for this possible<br= > solution:<br> <a href=3D"https://github.com/nice-software/lmdb/commit/03987789735141dc68a= e8b2d0e5ad52d82cc80d0" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad52d82cc80d0</a><= br> </span></blockquote> <br> That looks OK.<span class=3D""><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Basically it errors out because MSVC needs stdcall on that method.<br> </blockquote> <br></span> You realize of course, that this change actually has no effect on the code = here? stdcall uses Pascal argument order instead of C order but it's mo= ot since the function only has 1 argument.<span class=3D"im HOEnZb"><br></s= pan></blockquote><div><br></div><div>yeah... but if this fixes the error I = am fine with it, after all it end ups being just a define<br></div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"><span class=3D"im HOEnZb"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Cheers.<br> <br> On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro <<br> <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_blank">nacho.resa(a)gmail.= com</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Sorry! I did indeed meant to change just the windows part, for some reason<= br> I thought it was already ifdeffed that part.<br> <br> <a href=3D"https://github.com/nice-software/lmdb/commit/42577fe173923c1166f= 8382a53523a31479f9d43" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a31479f9d43</a><= br> <br> This is the right patch.<br> <br> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth <<br> <a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth@= usit.uio.no</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 19. okt. 2015 08:57, <a href=3D"mailto:nacho.resa@gmail.com" target=3D"_= blank">nacho.resa(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do not understand, I tested also with mingw64 (...)<br> <br> </blockquote> <br> There's no LPTHREAD_START_ROUTINE type on non-Windows machines.<br> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)= '<br> in the _WIN32 variant of '#define THREAD_CREATE...'.<br> <br> However, it's still wrong to call a function via another prototype.<br> Maybe that'd fall on 32-bit Windows or something, I don't know<br> how LPTHREAD_START_ROUTINE is defined.=C2=A0 The safe way would be to<br> give mdb_env_copythr() a prototype which does not need a cast.<br> There is some code for that already. Maybe it can be improved.<br> <br> --<br> Hallvard<br> <br> </blockquote> <br> <br> <br> --<br> Ignacio Casal Quinteiro<br> <br> </blockquote> <br> <br> <br> </blockquote> <br> <br> -- <br></span><div class=3D"HOEnZb"><div class=3D"h5"> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class= =3D"gmail_signature">Ignacio Casal Quinteiro</div> </div></div> --f46d043895179821ec05228f3c91--

1 0

Re: (ITS#8270) win32: fix conversion error
by hyc＠symas.com 20 Oct '15

20 Oct '15

nacho.resa(a)gmail.com wrote: > --047d7bb03a5ac118d20522842ead > Content-Type: text/plain; charset=UTF-8 > > So I took another closer look at this issue and I went for this possible > solution: > https://github.com/nice-software/lmdb/commit/03987789735141dc68ae8b2d0e5ad5… That looks OK. > Basically it errors out because MSVC needs stdcall on that method. You realize of course, that this change actually has no effect on the code here? stdcall uses Pascal argument order instead of C order but it's moot since the function only has 1 argument. > > Cheers. > > On Mon, Oct 19, 2015 at 2:55 PM, Ignacio Casal Quinteiro < > nacho.resa(a)gmail.com> wrote: > >> Sorry! I did indeed meant to change just the windows part, for some reason >> I thought it was already ifdeffed that part. >> >> https://github.com/nice-software/lmdb/commit/42577fe173923c1166f8382a53523a… >> >> This is the right patch. >> >> On Mon, Oct 19, 2015 at 1:43 PM, Hallvard Breien Furuseth < >> h.b.furuseth(a)usit.uio.no> wrote: >> >>> On 19. okt. 2015 08:57, nacho.resa(a)gmail.com wrote: >>> >>>> I do not understand, I tested also with mingw64 (...) >>>> >>> >>> There's no LPTHREAD_START_ROUTINE type on non-Windows machines. >>> You could replace 'start' with '(LPTHREAD_START_ROUTINE)(start)' >>> in the _WIN32 variant of '#define THREAD_CREATE...'. >>> >>> However, it's still wrong to call a function via another prototype. >>> Maybe that'd fall on 32-bit Windows or something, I don't know >>> how LPTHREAD_START_ROUTINE is defined. The safe way would be to >>> give mdb_env_copythr() a prototype which does not need a cast. >>> There is some code for that already. Maybe it can be improved. >>> >>> -- >>> Hallvard >>> >> >> >> >> -- >> Ignacio Casal Quinteiro >> > > > -- -- 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#8278) slapd fails to start when built with --enable-slp on freebsd
by h.b.furuseth＠usit.uio.no 20 Oct '15

20 Oct '15

On 20. okt. 2015 00:28, quanah(a)openldap.org wrote: > slapd will not start, exits with "slap_schema_init: Error registering matching > rule ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX > 1.3.6.1.4.1.1466.115.121.1.24 )" Reported to OpenSLP: <http://sourceforge.net/p/openslp/bugs/149/>. libslp 2.0.0 redefines strncasecmp() unless HAVE_STRNCASECMP, which it does not #define. Building OpenSLP (not OpenLDAP) with './configure CPPFLAGS=-DHAVE_STRNCASECMP' fixes it. -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs