openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

RE: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB failssometimes
by kriszyp＠gmail.com 21 Feb '19

21 Feb '19

--_36998F79-0E7E-483F-8FFD-6401D532832A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I see it now! I really did check even earlier this morning and wasn=E2=80= =99t there until recently! Anyway, thank you, sorry for the noise. Thanks, Kris From: Quanah Gibson-Mount Sent: February 21, 2019 10:12 AM To: kriszyp(a)gmail.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB failssom= etimes Hi, It is literally the first set of commits listed at that URL, so it's=20 clearly already there. Hope that helps! --Quanah --On Thursday, February 21, 2019 4:45 PM +0000 kriszyp(a)gmail.com wrote: > --0000000000000dacee05826a34a9 > Content-Type: text/plain; charset=3D"UTF-8" > > Thank you, I appreciate it! Do you know how often or when this will get > into the github mirror https://github.com/LMDB/lmdb/commits/mdb.RE/0.9 (o= r > if I am misunderstanding how the branches are synced)? > > On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <hyc(a)symas.com> wrote: > >> kriszyp(a)gmail.com wrote: >> > Full_Name: Kristopher William Zyp >> > Version: LMDB 0.9.23 >> > OS: Windows Server 2012 R2, Windows 10 >> > URL: >> https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45b >> d32ab4e8e1f2.patch >> > Submission from: (NULL) (71.199.6.148) >> > >> >> Thanks for the report and patch, added to mdb.RE/0.9 >> >> > Calling mdb_env_set_mapsize to increase the map size, when a DB is als= o >> in use >> > by other processes, when MDB_WRITEMAP is enabled (and the db file has >> been >> > opened with PAGE_READWRITE access), on Windows, will occasionally >> > (seems >> like >> > about 1/100 attempts fails) produce an error "The requested operation >> cannot be >> > performed on a file with a user-mapped section open", or segfaults. Th= e >> error >> > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map tha= t >> is >> > performed to increase the allocated file size to the map size, prior t= o >> > CreateFileMapping. >> > >> > As it turns out this is pretty easy to solve, because manually >> > expanding >> the >> > file size is not necessary when calling CreateFileMapping with >> PAGE_READWRITE >> > access, as Windows will automatically expand the file size for us, whe= n >> opened >> > with the page write access enabled. Of course, this means all processe= s >> must be >> > consistent in use of MDB_WRITEMAP, but the documentation already makes >> this >> > explicit and clear. >> > >> > I believe this can be fixed by simply adding a check for MDB_WRITEMAP >> > in >> the if >> > statement that calls SetFilePointer: >> > >> > if (!(flags & MDB_WRITEMAP) && >> > (SetFilePointer(env->me_fd, >> sizelo, &sizehi, 0) >> > !=3D (DWORD)sizelo >> > || !SetEndOfFile(env->me_fd) >> > || SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0= )) >> > return ErrCode(); >> > >> > The attached URL has the change as a patch/diff as applied to our node >> package. >> > >> > I am certainly happy to just keep this change on our own branches. >> > There >> may be >> > nuances of this that I might not be aware of, but it seems to be >> > working >> great >> > for us and I have tested this with MDB_WRITEMAP enabled and disabled. >> > So >> I >> > thought I would offer/suggest this change, as it seems like it is >> > straightforward change to improve stability. Thank you! >> > >> > >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > --0000000000000dacee05826a34a9 > Content-Type: text/html; charset=3D"UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D3D"ltr"><div dir=3D3D"ltr">Thank you, I appreciate it! Do you = know > h=3D ow often or when this will get into the github mirror <a > href=3D3D"https://gi=3D > thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB/lmdb/commi > ts=3D /mdb.RE/0.9</a> (or if I am misunderstanding how the branches are > synced)?<=3D /div></div> <div class=3D3D"gmail_quote"><div dir=3D3D"lt= r" > class=3D3D"gmail_a=3D ttr">On Sun, Feb 10, 2019 at 3:14 AM Howard Chu &lt= ;<a > href=3D3D"mailto:hyc@s=3D ymas.com">hyc(a)symas.com</a>> > wrote: </div><blockquote class=3D3D"gmail_=3D quote" style=3D3D"margin= :0px > 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=3D > 204);padding-left:1ex"><a href=3D3D"mailto:kriszyp@gmail.com" > target=3D3D"_blan=3D k">kriszyp(a)gmail.com</a> wrote: > > Full_Name: Kristopher William Zyp > > Version: LMDB 0.9.23 > > OS: Windows Server 2012 R2, Windows 10 > > URL: <a > href=3D3D"https://github.com/kriszyp/node-lmdb/commit/6df903907f=3D > 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D3D"noreferrer" > target=3D3D"_blank">=3D > https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd > 32=3D ab4e8e1f2.patch</a> > > Submission from: (NULL) (71.199.6.148) > > > > Thanks for the report and patch, added to mdb.RE/0.9 > > > Calling mdb_env_set_mapsize to increase the map size, when a DB is > als=3D o in use > > by other processes, when MDB_WRITEMAP is enabled (and the db file > has =3D been > > opened with PAGE_READWRITE access), on Windows, will occasionally > (see=3D ms like > > about 1/100 attempts fails) produce an error "The requested > opera=3D tion cannot be > > performed on a file with a user-mapped section open", or > segfault=3D s. The error > > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map > tha=3D t is > > performed to increase the allocated file size to the map size, prior > t=3D o > > CreateFileMapping. > > > > As it turns out this is pretty easy to solve, because manually > expandi=3D ng the > > file size is not necessary when calling CreateFileMapping with > PAGE_RE=3D ADWRITE > > access, as Windows will automatically expand the file size for us, > whe=3D n opened > > with the page write access enabled. Of course, this means all > processe=3D s must be > > consistent in use of MDB_WRITEMAP, but the documentation already > makes=3D this > > explicit and clear. > > > > I believe this can be fixed by simply adding a check for > MDB_WRITEMAP =3D in the if > > statement that calls SetFilePointer: > > > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0if (!(flags > &amp=3D ; MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, > &size=3D hi, 0) > > !=3D3D (DWORD)sizelo > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3D =3DC2=3DA0 =3DC2=3DA0|| !SetEndOfFile(env->me_fd) > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3D =3DC2=3DA0 =3DC2=3DA0|| SetFilePointer(env->me_fd, 0, NULL, 0) != =3D3D 0)) > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3D =3DC2=3DA0 =3DC2=3DA0return ErrCode(); > > > > The attached URL has the change as a patch/diff as applied to our > node=3D package. > > > > I am certainly happy to just keep this change on our own branches. > The=3D re may be > > nuances of this that I might not be aware of, but it seems to be > worki=3D ng great > > for us and I have tested this with MDB_WRITEMAP enabled and > disabled. =3D So I > > thought I would offer/suggest this change, as it seems like it is<br= > > > straightforward change to improve stability. Thank you! > > > > > > > -- > =3DC2=3DA0 -- Howard Chu > =3DC2=3DA0 CTO, Symas Corp.=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0<a > href=3D3D"=3D http://www.symas.com" rel=3D3D"noreferrer" > target=3D3D"_blank">http://www.symas=3D .com</a> > =3DC2=3DA0 Director, Highland Sun=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0<a > href=3D3D"http://highland=3D sun.com/hyc/" rel=3D3D"noreferrer" > target=3D3D"_blank">http://highlandsun.com/h=3D yc/</a> > =3DC2=3DA0 Chief Architect, OpenLDAP=3DC2=3DA0 <a > href=3D3D"http://www.openldap.org/p=3D roject/" rel=3D3D"noreferrer" > target=3D3D"_blank">http://www.openldap.org/proje=3D ct/</a> > </blockquote></div> > > --0000000000000dacee05826a34a9-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --_36998F79-0E7E-483F-8FFD-6401D532832A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1>I see it now! I really did check eve= n earlier this morning and wasn=E2=80=99t there until recently! Anyway, tha= nk you, sorry for the noise.<o:p> </o:p><= p class=3DMsoNormal>Thanks, Kris<o:p> </o:= p><div style=3D'mso-element:para-border-div;border:none;border-top:soli= d #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'>From: <a href=3D"mailto:quanah@symas.com">Qua= nah Gibson-Mount</a> Sent: February 21, 2019 10:12 AM To: <= /b><a href=3D"mailto:kriszyp@gmail.com">kriszyp(a)gmail.com</a>; <a href=3D"m= ailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a> Subjec= t: Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB failssomet= imes</div><o:p> </o:p>Hi,<o:p> </o:p>It = is literally the first set of commits listed at that URL, so it's clearly already there.<o:p> <= /o:p>Hope that helps!<o:p= > </o:p>--Quanah<o:p= > </o:p>--On Thursday, February 21, 2019 4:45= PM +0000 kriszyp(a)gmail.com wrote:<o:p> </o:p= >> --0000000000000dacee05826a34a9> Content-Type: text/plain; charset=3D"UTF-8"= ><o:p> </o:p>> Tha= nk you, I appreciate it! Do you know how often or when this will get> into the github mirror https://github.com/LMDB/lmdb/= commits/mdb.RE/0.9 (or> if I am misunderstandin= g how the branches are synced)?><o:p> </o:= p>> On Sun, Feb 10, 2019 at 3:14 AM Howard Chu = <hyc(a)symas.com> wrote:><o:p> </o:p><= /p>>> kriszyp(a)gmail.com wrote:>> > Full_Name: Kristopher William Zyp>> > Version: LMDB 0.9.23>> &gt= ; OS: Windows Server 2012 R2, Windows 10>> &= gt; URL:>> https://github.com/kriszyp/node-l= mdb/commit/6df903907f5516320e9a8afce45b>> d3= 2ab4e8e1f2.patch>> > Submission from: (NU= LL) (71.199.6.148)>> >>><o:p> </o:p>>> Thanks for= the report and patch, added to mdb.RE/0.9>>= <o:p> </o:p>>> > Calling mdb_env_set= _mapsize to increase the map size, when a DB is also>> in use>> > by other processes,= when MDB_WRITEMAP is enabled (and the db file has= >> been>> > opened with PAGE_READWR= ITE access), on Windows, will occasionally>>= > (seems>> like= >> > about 1/100 attempts fails) produce an error "The reques= ted operation>> cannot be>> > performed on a file with a user-mapped section open&quo= t;, or segfaults. The>> error>> > occurs in the SetFilePointer (or SetEndOfFile) call= in mdb_env_map that>> is>> > performed to increase the allocated file size to the ma= p size, prior to>> > CreateFileMapping.</= p>>> >>> > = As it turns out this is pretty easy to solve, because manually>> > expanding>> the</= p>>> > file size is not necessary when callin= g CreateFileMapping with>> PAGE_READWRITE</p= >>> > access, as Windows will automatically e= xpand the file size for us, when>> opened</p= >>> > with the page write access enabled. Of = course, this means all processes>> must be</= p>>> > consistent in use of MDB_WRITEMAP, but= the documentation already makes>> this<= p class=3DMsoNormal>>> > explicit and clear.>> >>> > I believe this can b= e fixed by simply adding a check for MDB_WRITEMAP&= gt;> > in>> the if>> > statement that calls SetFilePointer:>> >>> >=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!(fl= ags & MDB_WRITEMAP) &&>> >=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (SetFilePointer(env->me_fd,>> size= lo, &sizehi, 0)>> > !=3D (DWORD)sizel= o>> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 || !SetEndOfFile(env->me_fd)>> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= || SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0))>> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= return ErrCode();>> >>> > The attached URL has the change as a patch/diff as appl= ied to our node>> package.>> >>> > I am certainly h= appy to just keep this change on our own branches.= >> > There>> may be>> > nuances of this that I might not be aware of, but it= seems to be>> > working>> great>> > for us and I h= ave tested this with MDB_WRITEMAP enabled and disabled.>> > So>> I>> > thought I would offer/suggest this change, as it seems = like it is>> > straightforward change to = improve stability. Thank you!>> >>> >>><o:p> <= /o:p>>><o:p> </o:p>>> -->>=C2=A0=C2=A0 -- Howard Chu= >>=C2=A0=C2=A0 CTO, Symas Corp.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.symas.com<p= class=3DMsoNormal>>>=C2=A0=C2=A0 Director, Highland Sun=C2=A0=C2=A0= =C2=A0=C2=A0 http://highlandsun.com/hyc/>>= =C2=A0=C2=A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/projec= t/>><o:p> </o:p>><o:p> </o:p>> --0000000000000dacee05= 826a34a9> Content-Type: text/html; charset=3D&q= uot;UTF-8"> Content-Transfer-Encoding: quo= ted-printable><o:p> </o:p>> <div dir=3D3D"ltr"><div dir=3D3D"ltr&= quot;>Thank you, I appreciate it! Do you know&g= t; h=3D ow often or when this will get into the github mirror <a> href=3D3D"https://gi=3D= > thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB= /lmdb/commi> ts=3D /mdb.RE/0.9</a> (or if= I am misunderstanding how the branches are> sy= nced)?<=3D /div></div> <div class=3D3D"gmail_q= uote"><div dir=3D3D"ltr"> = class=3D3D"gmail_a=3D ttr">On Sun, Feb 10, 2019 at 3:14 AM How= ard Chu &lt;<a> href=3D3D"mailto:hy= c@s=3D ymas.com">hyc(a)symas.com</a>&gtm</a>&gt;> wrote: </div><blockquote class=3D3D"gmail= _=3D quote" style=3D3D"margin:0px> 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,=3D&= gt; 204);padding-left:1ex"><a href=3D3D"mailto:kriszyp@gmai= l.com"> target=3D3D"_blan=3D k"&= gt;kriszyp(a)gmail.com</a> wrote: &gt= ; &gt; Full_Name: Kristopher William Zyp > &gt; Version: LMDB 0.9.23 &g= t; &gt; OS: Windows Server 2012 R2, Windows 10 > &gt; URL: <a> href=3D3D&q= uot;https://github.com/kriszyp/node-lmdb/commit/6df903907f=3D> 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D3D"= noreferrer"> target=3D3D"_blank"= >=3D> https://github.com/kriszyp/node-lmdb/c= ommit/6df903907f5516320e9a8afce45bd> 32=3D ab4e= 8e1f2.patch</a> > &gt; Submi= ssion from: (NULL) (71.199.6.148) > &a= mp;gt; > > Thanks for the report and patch, added to mdb.RE/0.9 <= /p>> > &g= t; Calling mdb_env_set_mapsize to increase the map size, when a DB is<p= class=3DMsoNormal>> als=3D o in use &= gt; &gt; by other processes, when MDB_WRITEMAP is enabled (and the db f= ile> has =3D been > &gt; opened with PAGE_READWRITE access), on Windows, will occ= asionally> (see=3D ms like > &gt; about 1/100 attempts fails) produce an error &a= mp;quot;The requested> opera=3D tion cannot be&= lt;br>> &gt; performed on a file with a = user-mapped section open&quot;, or> segfaul= t=3D s. The error > &gt; occurs in= the SetFilePointer (or SetEndOfFile) call in mdb_env_map> tha=3D t is > &gt; per= formed to increase the allocated file size to the map size, prior> t=3D o > &gt; = CreateFileMapping. > &gt; <br&g= t;> &gt; As it turns out this is pretty eas= y to solve, because manually> expandi=3D ng the= > &gt; file size is not necessary= when calling CreateFileMapping with> PAGE_RE= =3D ADWRITE > &gt; access, as Wind= ows will automatically expand the file size for us,> whe=3D n opened > &gt; with = the page write access enabled. Of course, this means all> processe=3D s must be > &am= p;gt; consistent in use of MDB_WRITEMAP, but the documentation already<= p class=3DMsoNormal>> makes=3D=C2=A0 this > &gt; explicit and clear. &gt= ; &gt; > &gt; I believe this = can be fixed by simply adding a check for> MDB_= WRITEMAP =3D in the if > &gt; stat= ement that calls SetFilePointer: > &am= p;gt; > &gt;=3DC2=3DA0 =3DC2=3DA0= =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0if (!(fla= gs> &amp=3D ; MDB_WRITEMAP) &amp;&a= mp; (SetFilePointer(env-&gt;me_fd, sizelo,>= &amp;size=3D hi, 0) > &gt; != =3D3D (DWORD)sizelo > &gt;=3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0> =3D =3DC2=3DA0 =3D= C2=3DA0|| !SetEndOfFile(env-&gt;me_fd) > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&= gt; =3D =3DC2=3DA0 =3DC2=3DA0|| SetFilePointer(env-&gt;me_fd, 0, NULL, = 0) !=3D3D 0)) > &gt;=3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0> =3D =3DC2=3DA0 =3DC2=3DA= 0return ErrCode(); > &gt; <br&g= t;> &gt; The attached URL has the change as= a patch/diff as applied to our> node=3D=C2=A0 = package. > &gt; > &gt; I am certainly happy to just keep this chang= e on our own branches.> The=3D re may be<br&= gt;> &gt; nuances of this that I might not = be aware of, but it seems to be> worki=3D ng gr= eat > &gt; for us and I have teste= d this with MDB_WRITEMAP enabled and> disabled.= =3D So I > &gt; thought I would o= ffer/suggest this change, as it seems like it is > &gt; straightforward change to improve stability. Thank yo= u! > &gt; > &gt; > <br&g= t;> > -- = > =3DC2=3DA0 -- Howard Chu <= /p>> =3DC2=3DA0 CTO, Symas Corp.=3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0<a> href=3D3D"=3D http://www.symas.com" rel=3D3D"noreferre= r"> target=3D3D"_blank">http:= //www.symas=3D .com</a> > =3DC2= =3DA0 Director, Highland Sun=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0<a> href=3D3D"http://highland=3D sun.com/hyc/" re= l=3D3D"noreferrer"> target=3D3D"= _blank">http://highlandsun.com/h=3D yc/</a> > =3DC2=3DA0 Chief Architect, OpenLDAP=3DC2=3DA0 <a<= /p>> href=3D3D"http://www.openldap.org/p=3D ro= ject/" rel=3D3D"noreferrer"> tar= get=3D3D"_blank">http://www.openldap.org/proje=3D ct/</a&gt= ; > </blockquote></div></p= >><o:p> </o:p>> --= 0000000000000dacee05826a34a9--><o:p> </o:p= >><o:p> </o:p>&gt= ;<o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><p= class=3DMsoNormal>--<o:p> </o:p>Quanah Gibson-MountProduct Architect<= /p>Symas CorporationPackaged,= certified, and supported LDAP solutions powered by OpenLDAP:<http://www.symas.com><o:p>&nbs= p;</o:p><o:p> </o:p></div></body></html>= --_36998F79-0E7E-483F-8FFD-6401D532832A_--

1 0

Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB fails sometimes
by quanah＠symas.com 21 Feb '19

21 Feb '19

Hi, It is literally the first set of commits listed at that URL, so it's clearly already there. Hope that helps! --Quanah --On Thursday, February 21, 2019 4:45 PM +0000 kriszyp(a)gmail.com wrote: > --0000000000000dacee05826a34a9 > Content-Type: text/plain; charset="UTF-8" > > Thank you, I appreciate it! Do you know how often or when this will get > into the github mirror https://github.com/LMDB/lmdb/commits/mdb.RE/0.9 (or > if I am misunderstanding how the branches are synced)? > > On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <hyc(a)symas.com> wrote: > >> kriszyp(a)gmail.com wrote: >> > Full_Name: Kristopher William Zyp >> > Version: LMDB 0.9.23 >> > OS: Windows Server 2012 R2, Windows 10 >> > URL: >> https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45b >> d32ab4e8e1f2.patch >> > Submission from: (NULL) (71.199.6.148) >> > >> >> Thanks for the report and patch, added to mdb.RE/0.9 >> >> > Calling mdb_env_set_mapsize to increase the map size, when a DB is also >> in use >> > by other processes, when MDB_WRITEMAP is enabled (and the db file has >> been >> > opened with PAGE_READWRITE access), on Windows, will occasionally >> > (seems >> like >> > about 1/100 attempts fails) produce an error "The requested operation >> cannot be >> > performed on a file with a user-mapped section open", or segfaults. The >> error >> > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map that >> is >> > performed to increase the allocated file size to the map size, prior to >> > CreateFileMapping. >> > >> > As it turns out this is pretty easy to solve, because manually >> > expanding >> the >> > file size is not necessary when calling CreateFileMapping with >> PAGE_READWRITE >> > access, as Windows will automatically expand the file size for us, when >> opened >> > with the page write access enabled. Of course, this means all processes >> must be >> > consistent in use of MDB_WRITEMAP, but the documentation already makes >> this >> > explicit and clear. >> > >> > I believe this can be fixed by simply adding a check for MDB_WRITEMAP >> > in >> the if >> > statement that calls SetFilePointer: >> > >> > if (!(flags & MDB_WRITEMAP) && >> > (SetFilePointer(env->me_fd, >> sizelo, &sizehi, 0) >> > != (DWORD)sizelo >> > || !SetEndOfFile(env->me_fd) >> > || SetFilePointer(env->me_fd, 0, NULL, 0) != 0)) >> > return ErrCode(); >> > >> > The attached URL has the change as a patch/diff as applied to our node >> package. >> > >> > I am certainly happy to just keep this change on our own branches. >> > There >> may be >> > nuances of this that I might not be aware of, but it seems to be >> > working >> great >> > for us and I have tested this with MDB_WRITEMAP enabled and disabled. >> > So >> I >> > thought I would offer/suggest this change, as it seems like it is >> > straightforward change to improve stability. Thank you! >> > >> > >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > --0000000000000dacee05826a34a9 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr"><div dir=3D"ltr">Thank you, I appreciate it! Do you know > h= ow often or when this will get into the github mirror <a > href=3D"https://gi= > thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB/lmdb/commi > ts= /mdb.RE/0.9</a> (or if I am misunderstanding how the branches are > synced)?<= /div></div> <div class=3D"gmail_quote"><div dir=3D"ltr" > class=3D"gmail_a= ttr">On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <<a > href=3D"mailto:hyc@s= ymas.com">hyc(a)symas.com</a>> > wrote: </div><blockquote class=3D"gmail_= quote" style=3D"margin:0px > 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= > 204);padding-left:1ex"><a href=3D"mailto:kriszyp@gmail.com" > target=3D"_blan= k">kriszyp(a)gmail.com</a> wrote: > > Full_Name: Kristopher William Zyp > > Version: LMDB 0.9.23 > > OS: Windows Server 2012 R2, Windows 10 > > URL: <a > href=3D"https://github.com/kriszyp/node-lmdb/commit/6df903907f= > 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D"noreferrer" > target=3D"_blank">= > https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd > 32= ab4e8e1f2.patch</a> > > Submission from: (NULL) (71.199.6.148) > > > > Thanks for the report and patch, added to mdb.RE/0.9 > > > Calling mdb_env_set_mapsize to increase the map size, when a DB is > als= o in use > > by other processes, when MDB_WRITEMAP is enabled (and the db file > has = been > > opened with PAGE_READWRITE access), on Windows, will occasionally > (see= ms like > > about 1/100 attempts fails) produce an error "The requested > opera= tion cannot be > > performed on a file with a user-mapped section open", or > segfault= s. The error > > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map > tha= t is > > performed to increase the allocated file size to the map size, prior > t= o > > CreateFileMapping. > > > > As it turns out this is pretty easy to solve, because manually > expandi= ng the > > file size is not necessary when calling CreateFileMapping with > PAGE_RE= ADWRITE > > access, as Windows will automatically expand the file size for us, > whe= n opened > > with the page write access enabled. Of course, this means all > processe= s must be > > consistent in use of MDB_WRITEMAP, but the documentation already > makes= this > > explicit and clear. > > > > I believe this can be fixed by simply adding a check for > MDB_WRITEMAP = in the if > > statement that calls SetFilePointer: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!(flags > &amp= ; MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, > &size= hi, 0) > > !=3D (DWORD)sizelo > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = =C2=A0 =C2=A0|| !SetEndOfFile(env->me_fd) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = =C2=A0 =C2=A0|| SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0)) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = =C2=A0 =C2=A0return ErrCode(); > > > > The attached URL has the change as a patch/diff as applied to our > node= package. > > > > I am certainly happy to just keep this change on our own branches. > The= re may be > > nuances of this that I might not be aware of, but it seems to be > worki= ng great > > for us and I have tested this with MDB_WRITEMAP enabled and > disabled. = So I > > thought I would offer/suggest this change, as it seems like it is > > straightforward change to improve stability. Thank you! > > > > > > > -- > =C2=A0 -- Howard Chu > =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> > =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> > =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> > </blockquote></div> > > --0000000000000dacee05826a34a9-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB fails sometimes
by kriszyp＠gmail.com 21 Feb '19

21 Feb '19

--0000000000000dacee05826a34a9 Content-Type: text/plain; charset="UTF-8" Thank you, I appreciate it! Do you know how often or when this will get into the github mirror https://github.com/LMDB/lmdb/commits/mdb.RE/0.9 (or if I am misunderstanding how the branches are synced)? On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <hyc(a)symas.com> wrote: > kriszyp(a)gmail.com wrote: > > Full_Name: Kristopher William Zyp > > Version: LMDB 0.9.23 > > OS: Windows Server 2012 R2, Windows 10 > > URL: > https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd32… > > Submission from: (NULL) (71.199.6.148) > > > > Thanks for the report and patch, added to mdb.RE/0.9 > > > Calling mdb_env_set_mapsize to increase the map size, when a DB is also > in use > > by other processes, when MDB_WRITEMAP is enabled (and the db file has > been > > opened with PAGE_READWRITE access), on Windows, will occasionally (seems > like > > about 1/100 attempts fails) produce an error "The requested operation > cannot be > > performed on a file with a user-mapped section open", or segfaults. The > error > > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map that > is > > performed to increase the allocated file size to the map size, prior to > > CreateFileMapping. > > > > As it turns out this is pretty easy to solve, because manually expanding > the > > file size is not necessary when calling CreateFileMapping with > PAGE_READWRITE > > access, as Windows will automatically expand the file size for us, when > opened > > with the page write access enabled. Of course, this means all processes > must be > > consistent in use of MDB_WRITEMAP, but the documentation already makes > this > > explicit and clear. > > > > I believe this can be fixed by simply adding a check for MDB_WRITEMAP in > the if > > statement that calls SetFilePointer: > > > > if (!(flags & MDB_WRITEMAP) && (SetFilePointer(env->me_fd, > sizelo, &sizehi, 0) > > != (DWORD)sizelo > > || !SetEndOfFile(env->me_fd) > > || SetFilePointer(env->me_fd, 0, NULL, 0) != 0)) > > return ErrCode(); > > > > The attached URL has the change as a patch/diff as applied to our node > package. > > > > I am certainly happy to just keep this change on our own branches. There > may be > > nuances of this that I might not be aware of, but it seems to be working > great > > for us and I have tested this with MDB_WRITEMAP enabled and disabled. So > I > > thought I would offer/suggest this change, as it seems like it is > > straightforward change to improve stability. Thank you! > > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --0000000000000dacee05826a34a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Thank you, I appreciate it! Do you know h= ow often or when this will get into the github mirror <a href=3D"https://gi= thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB/lmdb/commits= /mdb.RE/0.9</a> (or if I am misunderstanding how the branches are synced)?<= /div></div> <div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a= ttr">On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <<a href=3D"mailto:hyc@s= ymas.com">hyc(a)symas.com</a>> wrote: </div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"><a href=3D"mailto:kriszyp@gmail.com" target=3D"_blan= k">kriszyp(a)gmail.com</a> wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows Server 2012 R2, Windows 10 > URL: <a href=3D"https://github.com/kriszyp/node-lmdb/commit/6df903907f= 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D"noreferrer" target=3D"_blank">= https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd32= ab4e8e1f2.patch</a> > Submission from: (NULL) (71.199.6.148) > Thanks for the report and patch, added to mdb.RE/0.9 > Calling mdb_env_set_mapsize to increase the map size, when a DB is als= o in use > by other processes, when MDB_WRITEMAP is enabled (and the db file has = been > opened with PAGE_READWRITE access), on Windows, will occasionally (see= ms like > about 1/100 attempts fails) produce an error "The requested opera= tion cannot be > performed on a file with a user-mapped section open", or segfault= s. The error > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map tha= t is > performed to increase the allocated file size to the map size, prior t= o > CreateFileMapping. > > As it turns out this is pretty easy to solve, because manually expandi= ng the > file size is not necessary when calling CreateFileMapping with PAGE_RE= ADWRITE > access, as Windows will automatically expand the file size for us, whe= n opened > with the page write access enabled. Of course, this means all processe= s must be > consistent in use of MDB_WRITEMAP, but the documentation already makes= this > explicit and clear. > > I believe this can be fixed by simply adding a check for MDB_WRITEMAP = in the if > statement that calls SetFilePointer: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!(flags &amp= ; MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, &size= hi, 0) > !=3D (DWORD)sizelo >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|| !SetEndOfFile(env->me_fd) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|| SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0)) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0return ErrCode(); > > The attached URL has the change as a patch/diff as applied to our node= package. > > I am certainly happy to just keep this change on our own branches. The= re may be > nuances of this that I might not be aware of, but it seems to be worki= ng great > for us and I have tested this with MDB_WRITEMAP enabled and disabled. = So I > thought I would offer/suggest this change, as it seems like it is > straightforward change to improve stability. Thank you! > > -- =C2=A0 -- Howard Chu =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> =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> =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> </blockquote></div> --0000000000000dacee05826a34a9--

1 0

RE: (ITS#8970) bind fails when length value is multi-byte
by quanah＠symas.com 21 Feb '19

21 Feb '19

Decoded message: frame captures follow. Ldap message begins at offset 0x36 (after ethernet, ip, tcp headers) success: 00 FF 06 16 E6 E1 00 FF 05 16 E6 E1 08 00 45 00 00 53 6B FE 40 00 80 06 4F F4 0A 01 28 2A 0A 78 02 10 D5 08 01 85 32 FB 2B E6 50 15 47 F1 50 18 01 00 90 48 00 00 30 29 02 01 01 60 24 02 01 03 04 19 63 6E 3D 55 73 65 72 31 2C 64 63 3D 6D 61 78 63 72 63 2C 64 63 3D 63 6F 6D 80 04 69 6E 69 74 failure: 00 FF 06 16 E6 E1 00 FF 05 16 E6 E1 08 00 45 00 00 5B 05 3A 40 00 80 06 B7 E2 0A 01 28 2A 0A 01 01 55 D6 0A 01 85 4F 4D F1 F0 57 2F 51 3C 50 18 01 00 19 06 00 00 30 84 00 00 00 2D 02 01 01 60 84 00 00 00 24 02 01 03 04 19 63 6E 3D 75 73 65 72 31 2C 64 63 3D 6D 61 78 63 72 63 2C 64 63 3D 63 6F 6D 80 04 69 6E 69 74 For your convenience (not needed?), here is the network monitor UI labeling for each frame (starting at ldap message) success: Frame: Number = 118, Captured Frame Length = 97, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-FF-06-16-E6-E1],SourceAddress:[00-FF-05-16-E6-E1] + Ipv4: Src = 10.1.40.42, Dest = 10.120.2.16, Next Protocol = TCP, Packet ID = 27646, Total IP Length = 83 + Tcp: Flags=...AP..., SrcPort=54536, DstPort=LDAP(389), PayloadLen=43, Seq=855321574 - 855321617, Ack=1343571953, Win=256 (scale factor 0x8) = 65536 Ldap: Bind Request, MessageID: 1, Version: 3 - LDAPMessage: Bind Request, MessageID: 1 - ParserHeader: - AsnId: Sequence and SequenceOf types (Universal 16) - LowTag: Class: (00......) Universal (0) Type: (..1.....) Constructed TagValue: (...10000) 16 - AsnLen: Length = 41, LengthOfLength = 0 Length: 41 bytes, LengthOfLength = 0 - MessageID: 1 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 1 (0x1) - OperationHeader: Bind Request, 0(0) - AsnId: Application Constructed Tag (0) - LowTag: Class: (01......) Application (1) Type: (..1.....) Constructed TagValue: (...00000) 0 - AsnLen: Length = 36, LengthOfLength = 0 Length: 36 bytes, LengthOfLength = 0 - BindRequest: Version:3, Name:cn=User1,dc=maxcrc,dc=com, UserName: init, Authentication type = simple - Version: 3 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 3 (0x3) - Name: cn=User1,dc=maxcrc,dc=com - AsnOctetStringHeader: - AsnId: OctetString type (Universal 4) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00100) 4 - AsnLen: Length = 25, LengthOfLength = 0 Length: 25 bytes, LengthOfLength = 0 OctetStream: cn=User1,dc=maxcrc,dc=com - Authentication: UserName: init, Authentication type = simple - AuthenticationTypeHeader: Authentication type = simple - AsnId: Context Specific Primitive Tag (0) - LowTag: Class: (10......) ConText specific (2) Type: (..0.....) Primitive TagValue: (...00000) 0 - AsnLen: Length = 4, LengthOfLength = 0 Length: 4 bytes, LengthOfLength = 0 SimpleAuthentication: init failure: Frame: Number = 30, Captured Frame Length = 105, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-FF-06-16-E6-E1],SourceAddress:[00-FF-05-16-E6-E1] + Ipv4: Src = 10.1.40.42, Dest = 10.1.1.85, Next Protocol = TCP, Packet ID = 1338, Total IP Length = 91 + Tcp: Flags=...AP..., SrcPort=54794, DstPort=LDAP(389), PayloadLen=51, Seq=1330508272 - 1330508323, Ack=1462718780, Win=256 (scale factor 0x8) = 65536 Ldap: Bind Request, MessageID: 1, Version: 3 - LDAPMessage: Bind Request, MessageID: 1 - ParserHeader: - AsnId: Sequence and SequenceOf types (Universal 16) - LowTag: Class: (00......) Universal (0) Type: (..1.....) Constructed TagValue: (...10000) 16 - AsnLen: Length = 45, LengthOfLength = 4 LengthType: LengthOfLength = 4 Length: 45 bytes - MessageID: 1 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 1 (0x1) - OperationHeader: Bind Request, 0(0) - AsnId: Application Constructed Tag (0) - LowTag: Class: (01......) Application (1) Type: (..1.....) Constructed TagValue: (...00000) 0 - AsnLen: Length = 36, LengthOfLength = 4 LengthType: LengthOfLength = 4 Length: 36 bytes - BindRequest: Version:3, Name:cn=user1,dc=maxcrc,dc=com, UserName: init, Authentication type = simple - Version: 3 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 3 (0x3) - Name: cn=user1,dc=maxcrc,dc=com - AsnOctetStringHeader: - AsnId: OctetString type (Universal 4) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00100) 4 - AsnLen: Length = 25, LengthOfLength = 0 Length: 25 bytes, LengthOfLength = 0 OctetStream: cn=user1,dc=maxcrc,dc=com - Authentication: UserName: init, Authentication type = simple - AuthenticationTypeHeader: Authentication type = simple - AsnId: Context Specific Primitive Tag (0) - LowTag: Class: (10......) ConText specific (2) Type: (..0.....) Primitive TagValue: (...00000) 0 - AsnLen: Length = 4, LengthOfLength = 0 Length: 4 bytes, LengthOfLength = 0 SimpleAuthentication: init --On Monday, February 04, 2019 4:29 AM +0000 lit(a)CBORD.com wrote: > ZnJhbWUgY2FwdHVyZXMgZm9sbG93LiAgTGRhcCBtZXNzYWdlIGJlZ2lucyBhdCBvZmZzZXQgM > Hgz > NiAoYWZ0ZXIgZXRoZXJuZXQsIGlwLCB0Y3AgaGVhZGVycykNCnN1Y2Nlc3M6DQowMCBGRiAwN > iAx > NiBFNiBFMSAwMCBGRiAwNSAxNiBFNiBFMSAwOCAwMCA0NSAwMCAwMCA1MyA2QiBGRSA0MCAwM > CA4 > MCAwNiA0RiBGNCAwQSAwMSAyOCAyQSAwQSA3OCAwMiAxMCBENSAwOCAwMSA4NSAzMiBGQiAyQ > iBF > NiA1MCAxNSA0NyBGMSA1MCAxOCAwMSAwMCA5MCA0OCAwMCAwMCAzMCAyOSAwMiAwMSAwMSA2M > CAy > NCAwMiAwMSAwMyAwNCAxOSA2MyA2RSAzRCA1NSA3MyA2NSA3MiAzMSAyQyA2NCA2MyAzRCA2R > CA2 > MSA3OCA2MyA3MiA2MyAyQyA2NCA2MyAzRCA2MyA2RiA2RCA4MCAwNCA2OSA2RSA2OSA3NCANC > g0K > ZmFpbHVyZToNCjAwIEZGIDA2IDE2IEU2IEUxIDAwIEZGIDA1IDE2IEU2IEUxIDA4IDAwIDQ1I > DAw > IDAwIDVCIDA1IDNBIDQwIDAwIDgwIDA2IEI3IEUyIDBBIDAxIDI4IDJBIDBBIDAxIDAxIDU1I > EQ2 > IDBBIDAxIDg1IDRGIDREIEYxIEYwIDU3IDJGIDUxIDNDIDUwIDE4IDAxIDAwIDE5IDA2IDAwI > DAw > IDMwIDg0IDAwIDAwIDAwIDJEIDAyIDAxIDAxIDYwIDg0IDAwIDAwIDAwIDI0IDAyIDAxIDAzI > DA0 > IDE5IDYzIDZFIDNEIDc1IDczIDY1IDcyIDMxIDJDIDY0IDYzIDNEIDZEIDYxIDc4IDYzIDcyI > DYz > IDJDIDY0IDYzIDNEIDYzIDZGIDZEIDgwIDA0IDY5IDZFIDY5IDc0IA0KDQpGb3IgeW91ciBjb > 252 > ZW5pZW5jZSAobm90IG5lZWRlZD8pLCBoZXJlIGlzIHRoZSBuZXR3b3JrIG1vbml0b3IgVUkgb > GFi > ZWxpbmcgZm9yIGVhY2ggZnJhbWUgKHN0YXJ0aW5nIGF0IGxkYXAgbWVzc2FnZSkNCg0Kc3VjY > 2Vz > czoNCiAgRnJhbWU6IE51bWJlciA9IDExOCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gOTcsI > E1l > ZGlhVHlwZSA9IEVUSEVSTkVUDQorIEV0aGVybmV0OiBFdHlwZSA9IEludGVybmV0IElQIChJU > HY0 > KSxEZXN0aW5hdGlvbkFkZHJlc3M6WzAwLUZGLTA2LTE2LUU2LUUxXSxTb3VyY2VBZGRyZXNzO > lsw > MC1GRi0wNS0xNi1FNi1FMV0NCisgSXB2NDogU3JjID0gMTAuMS40MC40MiwgRGVzdCA9IDEwL > jEy > MC4yLjE2LCBOZXh0IFByb3RvY29sID0gVENQLCBQYWNrZXQgSUQgPSAyNzY0NiwgVG90YWwgS > VAg > TGVuZ3RoID0gODMNCisgVGNwOiBGbGFncz0uLi5BUC4uLiwgU3JjUG9ydD01NDUzNiwgRHN0U > G9y > dD1MREFQKDM4OSksIFBheWxvYWRMZW49NDMsIFNlcT04NTUzMjE1NzQgLSA4NTUzMjE2MTcsI > EFj > az0xMzQzNTcxOTUzLCBXaW49MjU2IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkY > XA6 > IEJpbmQgUmVxdWVzdCwgTWVzc2FnZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlO > iBC > aW5kIFJlcXVlc3QsIE1lc3NhZ2VJRDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzb > klk > OiBTZXF1ZW5jZSBhbmQgU2VxdWVuY2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gT > G93 > VGFnOiANCiAgICAgICBDbGFzczogICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgI > CAg > VHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uL > jEw > MDAwKSAxNg0KICAgLSBBc25MZW46IExlbmd0aCA9IDQxLCBMZW5ndGhPZkxlbmd0aCA9IDANC > iAg > ICAgIExlbmd0aDogNDEgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAtIE1lc3NhZ2VJR > Dog > MQ0KICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgK > FVu > aXZlcnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uL > i4p > IFVuaXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlD > Qog > ICAgICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gM > Swg > TGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlb > md0 > aCA9IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kI > FJl > cXVlc3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoM > CkN > CiAgICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb > 24g > KDEpDQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUY > WdW > YWx1ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mT > GVu > Z3RoID0gMA0KICAgICAgTGVuZ3RoOiAzNiBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogI > C0g > QmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tL > CBV > c2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgLSBWZXJza > W9u > OiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc25JZDogSW50ZWdlciB0e > XBl > IChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoM > DAu > Li4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFBya > W1p > dGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KICAgICAtIEFzbkxlbjogT > GVu > Z3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlbmd0aDogMSBieXRlcywgT > GVu > Z3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNCiAgIC0gTmFtZTogY249V > XNl > cjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpbmdIZWFkZXI6IA0KICAgI > CAt > IEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNCiAgICAgIC0gTG93VGFnO > iAN > CiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgI > FR5 > cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wM > DEw > MCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0aE9mTGVuZ3RoID0gMA0KI > CAg > ICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9IDANCiAgICAgIE9jdGV0U > 3Ry > ZWFtOiBjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1dGhlbnRpY2F0aW9uOiBVc > 2Vy > TmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgIC0gQXV0aGVud > Glj > YXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc2ltcGxlDQogICAgIC0gQ > XNu > SWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNCiAgICAgIC0gTG93VGFnO > iAN > CiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc3BlY2lmaWMgKDIpDQogI > CAg > ICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgICAgICAgIFRhZ1ZhbHVlO > iAo > Li4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsIExlbmd0aE9mTGVuZ3RoI > D0g > MA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAgICAgU > 2lt > cGxlQXV0aGVudGljYXRpb246IGluaXQNCg0KDQpmYWlsdXJlOg0KDQogIEZyYW1lOiBOdW1iZ > XIg > PSAzMCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gMTA1LCBNZWRpYVR5cGUgPSBFVEhFUk5FV > A0K > KyBFdGhlcm5ldDogRXR5cGUgPSBJbnRlcm5ldCBJUCAoSVB2NCksRGVzdGluYXRpb25BZGRyZ > XNz > OlswMC1GRi0wNi0xNi1FNi1FMV0sU291cmNlQWRkcmVzczpbMDAtRkYtMDUtMTYtRTYtRTFdD > Qor > IElwdjQ6IFNyYyA9IDEwLjEuNDAuNDIsIERlc3QgPSAxMC4xLjEuODUsIE5leHQgUHJvdG9jb > 2wg > PSBUQ1AsIFBhY2tldCBJRCA9IDEzMzgsIFRvdGFsIElQIExlbmd0aCA9IDkxDQorIFRjcDogR > mxh > Z3M9Li4uQVAuLi4sIFNyY1BvcnQ9NTQ3OTQsIERzdFBvcnQ9TERBUCgzODkpLCBQYXlsb2FkT > GVu > PTUxLCBTZXE9MTMzMDUwODI3MiAtIDEzMzA1MDgzMjMsIEFjaz0xNDYyNzE4NzgwLCBXaW49M > jU2 > IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkYXA6IEJpbmQgUmVxdWVzdCwgTWVzc > 2Fn > ZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlOiBCaW5kIFJlcXVlc3QsIE1lc3NhZ > 2VJ > RDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzbklkOiBTZXF1ZW5jZSBhbmQgU2Vxd > WVu > Y2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gTG93VGFnOiANCiAgICAgICBDbGFzc > zog > ICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgICAgVHlwZTogICAgICguLjEuLi4uL > ikg > Q29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uLjEwMDAwKSAxNg0KICAgLSBBc25MZ > W46 > IExlbmd0aCA9IDQ1LCBMZW5ndGhPZkxlbmd0aCA9IDQNCiAgICAgIExlbmd0aFR5cGU6IExlb > md0 > aE9mTGVuZ3RoID0gNA0KICAgICAgTGVuZ3RoOiA0NSBieXRlcw0KICAtIE1lc3NhZ2VJRDogM > Q0K > ICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgKFVua > XZl > cnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pI > FVu > aXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlDQogI > CAg > ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgT > GVu > Z3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlbmd0a > CA9 > IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kIFJlc > XVl > c3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoMCkNC > iAg > ICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb24gK > DEp > DQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWY > Wx1 > ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mTGVuZ > 3Ro > ID0gNA0KICAgICAgTGVuZ3RoVHlwZTogTGVuZ3RoT2ZMZW5ndGggPSA0DQogICAgICBMZW5nd > Gg6 > IDM2IGJ5dGVzDQogIC0gQmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj11c2VyMSxkY > z1t > YXhjcmMsZGM9Y29tLCBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpb > XBs > ZQ0KICAgLSBWZXJzaW9uOiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc > 25J > ZDogSW50ZWdlciB0eXBlIChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgI > CAg > IENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgI > CAo > Li4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KI > CAg > ICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlb > md0 > aDogMSBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNC > iAg > IC0gTmFtZTogY249dXNlcjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpb > mdI > ZWFkZXI6IA0KICAgICAtIEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNC > iAg > ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhb > CAo > MCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgV > GFn > VmFsdWU6ICguLi4wMDEwMCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0a > E9m > TGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9I > DAN > CiAgICAgIE9jdGV0U3RyZWFtOiBjbj11c2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1d > Ghl > bnRpY2F0aW9uOiBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZ > Q0K > ICAgIC0gQXV0aGVudGljYXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc > 2lt > cGxlDQogICAgIC0gQXNuSWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNC > iAg > ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc > 3Bl > Y2lmaWMgKDIpDQogICAgICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgI > CAg > ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsI > Exl > bmd0aE9mTGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ > 3Ro > ID0gMA0KICAgICAgU2ltcGxlQXV0aGVudGljYXRpb246IGluaXQNCiAgDQoNCi0tLS0tT3JpZ > 2lu > YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb3dhcmQgQ2h1IDxoeWNAc3ltYXMuY29tPiANClNlb > nQ6 > IFN1bmRheSwgRmVicnVhcnkgMywgMjAxOSAxMDoyNSBQTQ0KVG86IExlbyBUb2hpbGwgPGxpd > EBD > Qk9SRC5jb20+OyBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnDQpTdWJqZWN0OiBSZTogKElUU > yM4 > OTcwKSBiaW5kIGZhaWxzIHdoZW4gbGVuZ3RoIHZhbHVlIGlzIG11bHRpLWJ5dGUNCg0KbGl0Q > GNi > b3JkLmNvbSB3cm90ZToNCj4gRnVsbF9OYW1lOiBMZW8gVG9oaWxsDQo+IFZlcnNpb246IDIuN > C4z > MA0KPiBPUzogV2luZG93cyAxMA0KPiBVUkw6IA0KPiBodHRwczovL2RvY3MuZ29vZ2xlLmNvb > S9k > b2N1bWVudC9kLzEwdUtnOU5oM0hMaXVPelRiTGZpNlo3YkNmVWI4eF9BaTZXDQo+IEs1THFOe > mJ3 > QS9lZGl0P3VzcD1zaGFyaW5nDQo+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICg3NC43OS44L > jQx > KQ0KPiANCj4gDQo+IFN1bW1hcnk6IG9wZW5sZGFwIDIuNC4zMCBkb2VzIG5vdCBhY2NvbW1vZ > GF0 > ZSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZSANCj4gb24gYmluZCByZXF1ZXN0Lg0KPiANCj4gD > Qo+ > IEZpcnN0LCBJJ2xsIGFkbWl0IHRoYXQgSSdtIG91dCBvZiBteSBkZXB0aCBoZXJlLCBJJ20gc > nVu > bmluZyBhIG9sZGVyIA0KPiB2ZXJzaW9uLCBJJ20gb24gV2luZG93cywgYW5kIG15IHBhY2thZ > 2Ug > d2FzIGJ1aWx0IGJ5IEkgZG9uJ3Qga25vdy4gIA0KPiBCdXQgSSB3b3JrZWQgaGFyZCBlbm91Z > 2gg > dG8gdHJhY2sgdGhpcyBkb3duIHRoYXQgSSB3YW50IHlvdSB0byBrbm93IA0KPiB3aGF0IEkgZ > m91 > bmQuICBJIG1pZ2h0IHVwZ3JhZGUsIGJ1dCB0aGF0J3MgcHJvYmxlbWF0aWMuDQo+IA0KPiBBd > CBz > b21lIHBvaW50IG15IGJpbmRpbmdzIGZyb20gLm5ldCBiZWdhbiBmYWlsaW5nIHdpdGggInRoZ > SB1 > c2VybmFtZSANCj4gb3IgcGFzc3dvcmQgaXMgaW5jb3JyZWN0IiBCdXQgdGhleSB3ZXJlIGNvc > nJl > Y3QuICBJIGNvdWxkIGNvbmZpcm0gd2l0aCB2YXJpb3VzIG90aGVyIHRvb2xzLg0KPiBJIGNhc > HR1 > cmVkIHRoZSB3aXJlIHRyYWZmaWMgdG8gaXNvbGF0ZSB0aGUgcHJvYmxlbS4gSXQgdHVybnMgb > 3V0 > IHRoYXQgDQo+IFdpbmRvd3MgZm9ybXMgdGhlIGJpbmRpbmcgcmVxdWVzdCB1c2luZyAgYSBtd > Wx0 > aS1ieXRlIGxlbmd0aCBpbmRpY2F0b3IgaW4gdGhlIHJlcXVlc3QuDQo+IE9wZW5MZGFwIGFwc > GFy > ZW50bHkgZG9lcyBub3QgYWNjb21tb2RhdGUgdGhpcy4gIEkgY29tcGFyZWQgdG8gYSANCj4gc > mVx > dWVzdCBnZW5lcmF0ZWQgYnkgIGxkYXBzZWFyY2guZXhlLiAgVGhhdCByZXF1ZXN0LCB3aGlja > CBz > dWNjZWVkcywgIA0KPiB2YXJpZXMgb25seSBieSB1c2luZyBhIHNpbmdsZS1ieXRlIGxlbmd0a > CBp > bmRpY2F0b3IuDQo+IA0KPiBUaGUgbXVsdGktYnl0ZSBsZW5ndGggdmFsdWUgc2hvdWxkIGJlI > GFs > bG93ZWQsIHJpZ2h0PyAgSXNuJ3QgaXQgDQo+IHBvc3NpYmxlIHRvIGhhdmUgYSBiaW5kIHJlc > XVl > c3QgZGF0YSBwYWNrZXQgb2YgbGVuZ3RoID4gMTI3PyAgV2hpY2ggDQo+IHdvdWxkIHJlcXVpc > mUg > YSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZS4gIFBlcmhhcHMgdGhpcyB3YXMgZml4ZWQgaW4gY > SBs > YXRlciB2ZXJzaW9uLg0KPiANCj4gU2NyZWVuc2hvdHMgb2YgdGhlIHdpcmUgY2FwdHVyZSBoZ > XJl > OiANCj4gDQo+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2QvMTB1S2c5TmgzS > Exp > dU96VGJMZmk2WjdiQ2ZVYjh4X0FpNlcNCj4gSzVMcU56YndBL2VkaXQ/dXNwPXNoYXJpbmcNC > g0K > VGhpcyBVUkwgaXMgaW5hY2Nlc3NpYmxlLCBwZXJtaXNzaW9uIGRlbmllZC4NCg0KSnVzdCBjb > 3B5 > IGhleCBkdW1wcyBvZiBib3RoIHJlcXVlc3RzIGhlcmUgaW4gdGV4dC4NCg0KLS0NCiAgLS0gS > G93 > YXJkIENodQ0KICBDVE8sIFN5bWFzIENvcnAuICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzL > mNv > bQ0KICBEaXJlY3RvciwgSGlnaGxhbmQgU3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL > 2h5 > Yy8NCiAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vc > mcv cHJvamVjdC8NCg== > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8970) bind fails when length value is multi-byte
by lit＠CBORD.com 21 Feb '19

21 Feb '19

--_000_BN8PR04MB619684C2863825C59B475C24BC7E0BN8PR04MB6196namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, any chance somebody could take a look at this? --_000_BN8PR04MB619684C2863825C59B475C24BC7E0BN8PR04MB6196namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"#954F72"> <div class=3D"WordSection1"> <o:p> </o:p> Hello, any chance somebody could take a look at this= ? <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_BN8PR04MB619684C2863825C59B475C24BC7E0BN8PR04MB6196namp_--

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by vsmith＠interlinknetworks.com 20 Feb '19

20 Feb '19

<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Interlink Networks LLC. Interlink Networks LLC has not assigned rights and/or interest in this work to any party. I, Vernon Smith am authorized by Interlink Networks LLC, my employer, to release this work under the following terms. Interlink Networks LLC hereby place the following 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. Thanks, Vern <div class="moz-cite-prefix">On 2/20/2019 9:42 AM, Quanah Gibson-Mount wrote: </div> <blockquote type="cite" cite="mid:8A8B819A395EEAE290F20248@[192.168.1.39]">--On Tuesday, February 19, 2019 2:41 PM +0000 <a class="moz-txt-link-abbreviated" href="mailto:quanah@symas.com">quanah(a)symas.com</a> wrote: <blockquote type="cite">--On Tuesday, February 19, 2019 2:12 AM -0500 Vern Smith <a class="moz-txt-link-rfc2396E" href="mailto:vsmith@interlinknetworks.com"><vsmith(a)interlinknetworks.com></a> wrote: <blockquote type="cite">ITS#8957 and ITS#8968 are my submits and I was using those changes. ITS#8963 is for OpenLDAP servers and I only an using the libraries so it does not apply to my updates. </blockquote> Please keep replies to the ITS system. </blockquote> Hi, Although each change is individually tiny, the sum of changes is not. Can you please add an IPR to this ITS, as documented at <a class="moz-txt-link-rfc2396E" href="https://www.openldap.org/devel/contributing.html#notice"><https://www.openldap.org/devel/contributing.html#notice></a> Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <a class="moz-txt-link-rfc2396E" href="http://www.symas.com"><http://www.symas.com></a> </blockquote> </body> </html>

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by quanah＠symas.com 20 Feb '19

20 Feb '19

--On Tuesday, February 19, 2019 2:41 PM +0000 quanah(a)symas.com wrote: > --On Tuesday, February 19, 2019 2:12 AM -0500 Vern Smith > <vsmith(a)interlinknetworks.com> wrote: > >> ITS#8957 and ITS#8968 are my submits and I was using those changes. >> ITS#8963 is for OpenLDAP servers and I only an using the libraries so it >> does not apply to my updates. > > Please keep replies to the ITS system. Hi, Although each change is individually tiny, the sum of changes is not. Can you please add an IPR to this ITS, as documented at <https://www.openldap.org/devel/contributing.html#notice> Thanks! 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#8982) Fix OpenLDAP headers so they're useful for development
by hyc＠symas.com 20 Feb '19

20 Feb '19

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE25 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > It's currently difficult for downstream packagers to create a working > development package as some items required to build external modules are only > included what are considered "private" headers, such as slap.h (See ITS#7283). > SLAP_CB_{BYPASS,CONTINUE} are examples of items that are contained in slap.h > that are potentially required for building external modules. > > IIRC, it's also been discussed previously to rename "ldap_pvt.h" to "openldap.h" > to indicate it's ok to package this header file in a -devel package (I could > have the initial header name incorrect, it's been a while). This discussion is a bit awkward. OpenLDAP is an open source project. What we provide is a distribution of source code. It was never intended to be sliced and diced into individual binary packages. If you're developing modules for OpenLDAP, you're expected to have a complete OpenLDAP build tree in which your modules reside. Modules meant to run inside slapd are by definition *internal* - they are running inside slapd after all. The fact that they're written and maintained by 3rd parties doesn't change this. Header files marked "private" mean they're only for internal use within an OpenLDAP build tree. Applications that are generic LDAP clients should only use the public APIs. We can still discuss formally making some OpenLDAP-specific APIs public, but that should probably be done on a case by case basis. LDAP is supposed to be interoperable; we should not encourage broader use of OpenLDAP-specific APIs that rely on details of OpenLDAP's internal implementation. If they have no particular dependency on internals, then we may safely expose them. -- -- 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#8982) Fix OpenLDAP headers so they're useful for development
by quanah＠openldap.org 19 Feb '19

19 Feb '19

Full_Name: Quanah Gibson-Mount Version: RE25 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) It's currently difficult for downstream packagers to create a working development package as some items required to build external modules are only included what are considered "private" headers, such as slap.h (See ITS#7283). SLAP_CB_{BYPASS,CONTINUE} are examples of items that are contained in slap.h that are potentially required for building external modules. IIRC, it's also been discussed previously to rename "ldap_pvt.h" to "openldap.h" to indicate it's ok to package this header file in a -devel package (I could have the initial header name incorrect, it's been a while).

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by quanah＠symas.com 19 Feb '19

19 Feb '19

--On Tuesday, February 19, 2019 2:12 AM -0500 Vern Smith <vsmith(a)interlinknetworks.com> wrote: > ITS#8957 and ITS#8968 are my submits and I was using those changes. > ITS#8963 is for OpenLDAP servers and I only an using the libraries so it > does not apply to my updates. Please keep replies to the ITS system. When filing an ITS, please note specifically which commits past a release you've applied, so the ITS is a clear representation of the issue you're reporting (and thus avoiding questions such as those I posited). Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs