No symbol table info available.

#4 =C2=A00x000000000043898b in ?? ()

No symbol table info= available.

#5 =C2=A00x00000000005306f9 in ?? ()

No sym= bol table info available.

#6 =C2=A00x00007f6f7d8fbdc5 in start_th= read () from /lib64/libpthread.so.0

No symbol table info availabl= e.

#7 =C2=A00x00007f6f7d62c17d in clone () from /lib64/libc.so.6<= /div>

No symbol table info available.

Thread 2= (Thread 0x7f6f75e4c700 (LWP 30979)):

#0 =C2=A00x00007f6f7d8ff6d5= in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0

No symbol table info available.

#1 =C2=A00x000000000053074b in ?= ? ()

No symbol table info available.

#2 =C2=A00x00007f6= f7d8fbdc5 in start_thread () from /lib64/libpthread.so.0

No symbo= l table info available.

#3 =C2=A00x00007f6f7d62c17d in clone () f= rom /lib64/libc.so.6

No symbol table info available.

--= -Type <return> to continue, or q <return> to quit---

Thread 1 (Thread 0x7f6f7eb53840 (LWP 30975)):

#0 = =C2=A00x00007f6f7d8fcef7 in pthread_join () from /lib64/libpthread.so.0

No symbol table info available.

#1 =C2=A00x000000000043590= 9 in slapd_daemon ()

No symbol table info available.

#2= =C2=A00x000000000041eccf in main ()

No symbol table info availab= le.

---

Regard= s,

Kevin Martin

On Fri, Feb 12, 2016 at 11:01 AM, Quanah Gib= son-Mount <quanah(a)zimbra.com> wrote:

--On Friday, February 12, 2016 4:30 PM +0000 ktmdms(a)gmail.com wrote:

Full_Name: Kevin Martin
Version: 2.4.44
OS: Oracle Linux 7
URL:
Submission from: (NULL) (160.34.110.215)

What else would you like to help figure this out?

As noted in <http://www.openldap.org/faq/data/cache= /59.html>, when slapd crashes, one should provide a backtrace from g= db.

I.e.:

Start slapd

gdb /path/to/slapd pid

(gdb) cont

Then execute your ldappasswd command in another window.=C2=A0 When slapd cr= ashes, it'll drop back into gdb.

(gdb) thr apply all bt full

Provide that output back to the ITS.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::=C2=A0 the leader in open source messaging and collaboration
A division of Synacor, Inc

--001a113a557a0b02ca052b95eb6f-- --===============7020611176922286660==-- From quanah@zimbra.com Fri Feb 12 17:33:47 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8371) slapd crashes with ldappasswd Date: Fri, 12 Feb 2016 17:33:45 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5627596198690164769==" --===============5627596198690164769== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, February 12, 2016 11:22 AM -0600 kevin martin wrote: > > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7f6f7664d700 (LWP 30978)] > 0x0000000000467f2f in passwd_extop () > (gdb) thr apply all bt full Hi Kevin, You appear to be running a stripped binary lacking debug symbols. You need to ensure your slapd build is not stripped nor lacking debug symbols (-g as one of the CFLAGS). Adding STRIP="" to the make install bits will prevent the stripping. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============5627596198690164769==-- From ktmdms@gmail.com Fri Feb 12 17:38:21 2016 From: ktmdms@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8371) slapd crashes with ldappasswd Date: Fri, 12 Feb 2016 17:38:19 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6683594411600736168==" --===============6683594411600736168== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --001a113a557a968d8d052b96215c Content-Type: text/plain; charset=UTF-8 Should I add STRIP="" in the Makefile or is there a way to add that on the configure line? Thanks. Kevin --- Regards, Kevin Martin On Fri, Feb 12, 2016 at 11:32 AM, Quanah Gibson-Mount wrote: > --On Friday, February 12, 2016 11:22 AM -0600 kevin martin < > ktmdms(a)gmail.com> wrote: > > >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7f6f7664d700 (LWP 30978)] >> 0x0000000000467f2f in passwd_extop () >> (gdb) thr apply all bt full >> > > Hi Kevin, > > You appear to be running a stripped binary lacking debug symbols. You > need to ensure your slapd build is not stripped nor lacking debug symbols > (-g as one of the CFLAGS). Adding STRIP="" to the make install bits will > prevent the stripping. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > --001a113a557a968d8d052b96215c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Should I add STRIP=3D"" in the Makefile or is th= ere a way to add that on the configure line?

Thanks.

Kevin

---

Regards,

Kevin Martin

On Fri, Feb 12, 2016 at 11:32 AM, Quanah Gib= son-Mount <quanah(a)zimbra.com> wrote:

--On Friday, February 12, 2016 11:22 AM -0600 k= evin martin <ktmdm= s(a)gmail.com> wrote:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f6f7664d700 (LWP 30978)]
0x0000000000467f2f in passwd_extop ()
(gdb) thr apply all bt full

Hi Kevin,

You appear to be running a stripped binary lacking debug symbols.=C2=A0 You= need to ensure your slapd build is not stripped nor lacking debug symbols = (-g as one of the CFLAGS).=C2=A0 Adding STRIP=3D"" to the make in= stall bits will prevent the stripping.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::=C2=A0 the leader in open source messaging and collaboration
A division of Synacor, Inc

--001a113a557a968d8d052b96215c-- --===============6683594411600736168==-- From michael@stroeder.com Fri Feb 12 17:41:45 2016 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8371) slapd crashes with ldappasswd Date: Fri, 12 Feb 2016 17:41:43 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2024554490654677560==" --===============2024554490654677560== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ktmdms(a)gmail.com wrote: > Should I add STRIP="" in the Makefile or is there a way to add that on the > configure line? You can simply use make install STRIP="" Ciao, Michael. --===============2024554490654677560==-- From ktmdms@gmail.com Fri Feb 12 19:29:37 2016 From: ktmdms@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8371) slapd crashes with ldappasswd Date: Fri, 12 Feb 2016 19:29:35 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5421856710143559727==" --===============5421856710143559727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --001a113f36ea7f617e052b97afc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So after installing with STRIP=3D"" I noticed that the pw-sha2.a and .so were a bit older than the openldap software so I recompiled that as well and installed it and the crashing stopped. I've since installed the stripped version again and it doesn't crash so I think the problem ended up being in the pw-sha2 module. Kevin --- Regards, Kevin Martin On Fri, Feb 12, 2016 at 11:41 AM, Michael Str=C3=B6der wrote: > ktmdms(a)gmail.com wrote: > > Should I add STRIP=3D"" in the Makefile or is there a way to add that o= n > the > > configure line? > > You can simply use > > make install STRIP=3D"" > > Ciao, Michael. > --001a113f36ea7f617e052b97afc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So after installing with STRIP=3D"" =C2=A0I noti= ced that the pw-sha2.a and .so were a bit older than the openldap software = so I recompiled that as well and installed it and the crashing stopped.=C2= =A0 I've since installed the stripped version again and it doesn't = crash so I think the problem ended up being in the pw-sha2 module.

Kevin

---

Regards,

Kevin Martin

On Fri, Feb 12, 2016 at 11:41 AM, Michael St= r=C3=B6der <michael(a)stroeder.com> wrote:

ktmd= ms(a)gmail.com wrote:
> Should I add STRIP=3D"" in the Makefile or is there a way to= add that on the
> configure line?

You can simply use

make install STRIP=3D""

Ciao, Michael.

--001a113f36ea7f617e052b97afc7-- --===============5421856710143559727==-- From quanah@zimbra.com Fri Feb 12 19:34:25 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8371) slapd crashes with ldappasswd Date: Fri, 12 Feb 2016 19:34:23 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8549996191927760499==" --===============8549996191927760499== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, February 12, 2016 7:29 PM +0000 ktmdms(a)gmail.com wrote: > --001a113f36ea7f617e052b97afc7 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > So after installing with STRIP=3D"" I noticed that the pw-sha2.a and .so > were a bit older than the openldap software so I recompiled that as well > and installed it and the crashing stopped. I've since installed the > stripped version again and it doesn't crash so I think the problem ended > up being in the pw-sha2 module. Sounds like your build process doesn't correctly install/update all the components you're using then. ;) Closing this ITS. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============8549996191927760499==-- From ktmdms@gmail.com Fri Feb 12 19:41:17 2016 From: ktmdms@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8371) slapd crashes with ldappasswd Date: Fri, 12 Feb 2016 19:41:16 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9062681906782192830==" --===============9062681906782192830== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --001a113f36ea472c2d052b97d94d Content-Type: text/plain; charset=UTF-8 Hmm, the configure command I used was: ./configure --with-tls=openssl --enable-modules --enable-syncprov --enable-seqmod --enable-sssvlv --enable-ppolicy --enable-accesslog --enable-passwd --enable-monitor --enable-bdb --enable-syslog but when I get to "make install" no contrib get's made or installed. sha2 is part of contrib/slapd-modules/passwd and I don't see anything in configure that allows you to source in any of the contrib stuff so yes, I appear to have missed compiling and installing the updated sha2 modules. Thanks for the help; I was hard pressed to figure this out myself! Kevin --- Regards, Kevin Martin On Fri, Feb 12, 2016 at 1:33 PM, Quanah Gibson-Mount wrote: > --On Friday, February 12, 2016 7:29 PM +0000 ktmdms(a)gmail.com wrote: > > --001a113f36ea7f617e052b97afc7 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: quoted-printable >> >> So after installing with STRIP=3D"" I noticed that the pw-sha2.a and .so >> were a bit older than the openldap software so I recompiled that as well >> and installed it and the crashing stopped. I've since installed the >> stripped version again and it doesn't crash so I think the problem ended >> up being in the pw-sha2 module. >> > > Sounds like your build process doesn't correctly install/update all the > components you're using then. ;) > > Closing this ITS. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > --001a113f36ea472c2d052b97d94d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hmm, the configure command I used was:

= ./configure --with-tls=3Dopenssl --enable-modules --enable-syncprov --enabl= e-seqmod =C2=A0--enable-sssvlv --enable-ppolicy --enable-accesslog --enable= -passwd --enable-monitor --enable-bdb --enable-syslog

but when I get to "make install" no contrib get's mad= e or installed. =C2=A0sha2 is part of contrib/slapd-modules/passwd and I do= n't see anything in configure that allows you to source in any of the c= ontrib stuff so yes, I appear to have missed compiling and installing the u= pdated sha2 modules.

Thanks for the help; I was ha= rd pressed to figure this out myself!

Kevin

<= /div>

---

Regards,

= Kevin Martin

On Fri, Feb 12, 2016 at 1:33 PM, Quanah Gibs= on-Mount <quanah(a)zimbra.com> wrote:

--On Friday, February 12, 2016 7:29 PM +0000 ktmdms(a)gmail.com wrote:

--001a113f36ea7f617e052b97afc7
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: quoted-printable

So after installing with STRIP=3D3D""=C2=A0 I noticed that the pw= -sha2.a and .so
were a bit older than the openldap software so I recompiled that as well and installed it and the crashing stopped.=C2=A0 I've since installed t= he
stripped version again and it doesn't crash so I think the problem ende= d
up being in the pw-sha2 module.

Sounds like your build process doesn't correctly install/update all the= components you're using then. ;)

Closing this ITS.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::=C2=A0 the leader in open source messaging and collaboration
A division of Synacor, Inc

--001a113f36ea472c2d052b97d94d-- --===============9062681906782192830==-- From quanah@zimbra.com Fri Feb 12 19:47:09 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8371) slapd crashes with ldappasswd Date: Fri, 12 Feb 2016 19:47:07 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4095836671057081133==" --===============4095836671057081133== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, February 12, 2016 1:40 PM -0600 kevin martin=20 wrote: > > Hmm, the configure command I used was: > > > ./configure --with-tls=3Dopenssl --enable-modules --enable-syncprov > --enable-seqmod =C2=A0--enable-sssvlv --enable-ppolicy --enable-accesslog > --enable-passwd --enable-monitor --enable-bdb --enable-syslog > > > > but when I get to "make install" no contrib get's made or installed. > =C2=A0sha2 is part of contrib/slapd-modules/passwd and I don't see = anything > in configure that allows you to source in any of the contrib stuff so > yes, I appear to have missed compiling and installing the updated sha2 > modules. Right, contrib items are not built as part of the overall process. They=20 are contributions, not part of the core product. You have to individually=20 build and install the ones you want. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============4095836671057081133==-- From subbarao@computer.org Mon Feb 15 20:27:28 2016 From: subbarao@computer.org To: openldap-bugs@openldap.org Subject: (ITS#8372) Incomplete members from dynlist group when Paged Results control is specified Date: Mon, 15 Feb 2016 20:27:26 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8516146454660730048==" --===============8516146454660730048== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Kartik Subbarao Version: 2.4.41 OS: Ubuntu 14.04.3 LTS URL: ftp://ftp.openldap.org/incoming/kartik-subbarao-160215.tgz Submission from: (NULL) (173.75.228.155) When the Paged Results control (1.2.840.113556.1.4.319) is specified, dynlist groups after the first page return fewer numbers than should be present. I have uploaded slapd.conf and example.ldif files that can be used to reprodu= ce the problem. Search with a page size of 1 and the filter (objectclass=3DgroupOfURLs). The member for group1 is returned successfully, whereas no members for group2 are returned. If the page size is set to 2 or higher, the member for group2 is properly returned. ftp://ftp.openldap.org/incoming/kartik-subbarao-160215.tgz: slapd.conf example.ldif For additional context, see this post to the openldap-technical mailing list: http://www.openldap.org/lists/openldap-technical/201602/msg00102.html --===============8516146454660730048==-- From quanah@openldap.org Thu Feb 18 23:01:42 2016 From: quanah@openldap.org To: openldap-bugs@openldap.org Subject: (ITS#8373) replica with multiple providers hits errors Date: Thu, 18 Feb 2016 23:01:41 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7785534261556007859==" --===============7785534261556007859== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 3.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) I have a MMR setup, with two providers, zre-ldap003 and zre-ldap005. I have a single replica, zre-ldap002, which is configured to pull updates from both providers. However, it continually gets an error 53 from zre-ldap005 after writing an update to zre-ldap003. As far as I can tell, all contextCSN data = is correct on all nodes. replica: zimbra(a)zre-ldap002:~$ ldapsearch -x -LLL -H ldapi:// -D cn=3Dconfig -w zimb= ra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 Master SID1: [zimbra(a)zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=3Dconfig -w zi= mbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 [zimbra(a)zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=3Dconfig -w zi= mbra -s base -b "cn=3Daccesslog" contextCSN dn: cn=3Daccesslog contextCSN: 20160217223749.648918Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 Master SID2: [zimbra(a)zre-ldap003 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=3Dconfig -w zi= mbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 [zimbra(a)zre-ldap003 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=3Dconfig -w zi= mbra -s base -b "cn=3Daccesslog" contextCSN dn: cn=3Daccesslog contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000%%0 Note all contextCSNs have the same value everywhere. However, when the replica attempts to replicate off of zre-ldap005, we get the following error: Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 fd=3D18 ACCEPT from IP=3D10.137.242.52:38979 (IP=3D10.137.242.55:389) Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D0 EXT oid=3D1.3.6.1.4.1.1466.20037 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D0 STARTTLS Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D0 RESULT oid=3D er= r=3D0 etime=3D0.000071 text=3D Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 fd=3D18 TLS established tls_ssf=3D128 ssf=3D128 tls_proto=3DTLSv1.2 tls_cipher=3DSEED-SHA Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D1 BIND dn=3D"uid=3Dzmreplica,cn=3Dadmins,cn=3Dzimbra" metho3D3D128 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D1 BIND dn=3D"uid=3Dzmreplica,cn=3Dadmins,cn=3Dzimbra" mech=3DSIMPLE ssf=3D0 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D1 RESULT tag=3D97 = err=3D0 etime=3D0.000154 text=3D Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D2 SRCH base=3D"cn=3Daccesslog" scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DauditWriteObject)(reqResult=3D0))" Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D2 SRCH attr=3DreqD= N reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D2 SEARCH RESULT ta= g=3D101 err=3D53 etime=3D0.000177 nentries=3D0 text=3Dconsumer state is newer than pr= ovider! Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=3D1191 op=3D3 UNBIND Feb 18 16:50:34 zre-ldap5 5 slapd[10555]: conn=3D1191 fd=3D18 closed This started happening after I made a modification on zre-ldap005 followed by= a modification on zre-ldap003. In that case, the following was logged on zre-ldap002: Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=3D101 cookie=3Drid=3D101,sid=3D002,csn=3D20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3589880 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=3D100 cookie=3Dr%3=3D100,sid=3D001,csn=3D20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3589880 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: syncrepl_message_to_op: rid=3D101 be_modify cn=3Dadmins,cn=3Dzimbra (0) Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3589740 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3589740 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=3D100 CSN pending, ignoring 20160218220604.321502Z#000000#002#000000 (reqStart=3D20160218220604.326527Z,cn=3Daccesslog) So we see the write accepted from one master, and correctly rejected (not replayed) from the other. After this, there were no more modifications made to either master. However,= I *did* make a modification to cn=3Dconfig on the replica. After that was done= , is when the error(53) started getting triggered: Feb 18 16:27:12 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3587a40 20160218222712.155976Z#000000#000#000000 Feb 18 16:27:12 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3587a40 20160218222712.155976Z#000000#000#000000 Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=3D100 LDAP_RES_SEARCH_RESULT Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=3D100 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=3D100 (53) Server = is unwilling to perform Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrepl: rid=3D100 rc -2 retryi= ng --===============7785534261556007859==-- From quanah@zimbra.com Thu Feb 18 23:39:04 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8373) replica with multiple providers hits errors Date: Thu, 18 Feb 2016 23:39:03 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7855926646395124330==" --===============7855926646395124330== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: After stopping all servers, and restarting the masters, I see the same error (53) being returned when zre-ldap003 tries to connect to zre-ldap005. So this is not specific to the replica or the change to cn=config I made on the replica. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============7855926646395124330==-- From quanah@zimbra.com Fri Feb 19 00:37:19 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8373) replica with multiple providers hits errors Date: Fri, 19 Feb 2016 00:37:17 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4684994040201963337==" --===============4684994040201963337== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: > Master SID1: > [zimbra(a)zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w > zimbra -s base -b "" contextCSN > dn: > contextCSN: 20160218220547.523250Z#000000#001#000000 > contextCSN: 20160218220604.321502Z#000000#002#000000 > > [zimbra(a)zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w > zimbra -s base -b "cn=accesslog" contextCSN > dn: cn=accesslog > contextCSN: 20160217223749.648918Z#000000#001#000000 > contextCSN: 20160218220604.321502Z#000000#002#000000 Ooops, clearly a difference here between the main db and the accesslog DB. However, nothing was logged, error wise. Here is this modification: Feb 18 16:05:47 zre-ldap005 slapd[10555]: slap_queue_csn: queueing 0x3ce84c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap005 slapd[10555]: slap_graduate_commit_csn: removing 0x3ce84c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap005 slapd[10555]: syncprov_sendresp: cookie=rid=100,sid=001 Feb 18 16:05:47 zre-ldap005 slapd[10555]: syncprov_sendresp: to=002, cookie=rid=100,sid=001 On the other master, we have: Feb 18 16:05:47 zre-ldap003 slapd[6947]: do_syncrep2: rid=100 cookie=rid=100,sid=001 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_queue_csn: queueing 0x36d58c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_queue_csn: queueing 0x36d5800 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncprov_matchops: skipping original sid 001 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_graduate_commit_csn: removing 0x36d5800 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_graduate_commit_csn: removing 0x36d58c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncrepl_message_to_op: rid=100 be_modify cn=admins,cn=zimbra (0) Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncprov_sendresp: cookie=rid=101,sid=002,csn=20160218220547.523250Z#000000#001#000000 In the accesslog, we have: dn: reqStart=20160218220547.523064Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20160218220547.523064Z reqEnd: 20160218220547.523558Z reqType: modify reqSession: 1027 reqAuthzID: cn=config reqDN: cn=admins,cn=zimbra reqResult: 0 reqMod: description:= admin accounts reqMod: entryCSN:= 20160218220547.523250Z#000000#001#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20160218220547Z reqEntryUUID: c3fbf53a-6a0c-1035-9563-ef445d2cc3b6 entryCSN: 20160218220547.523250Z#000000#001#000000 entryUUID: 822e1680-6ad7-1035-8bac-2751986a6fb8 creatorsName: cn=config createTimestamp: 20160218220547Z modifiersName: cn=config modifyTimestamp: 20160218220547Z --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============4684994040201963337==-- From quanah@zimbra.com Fri Feb 19 01:33:58 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8373) replica with multiple providers hits errors Date: Fri, 19 Feb 2016 01:33:56 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4508180815057384528==" --===============4508180815057384528== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, February 19, 2016 12:37 AM +0000 quanah(a)zimbra.com wrote: > --On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: So I can trivially reproduce this. I make a change on each master, and boom, they go out of sync and everything's broken. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============4508180815057384528==-- From dog@pavlov.com Fri Feb 19 16:02:23 2016 From: dog@pavlov.com To: openldap-bugs@openldap.org Subject: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Fri, 19 Feb 2016 16:02:22 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5651997958048334186==" --===============5651997958048334186== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Martin O'Neal Version: openldap-2.4.31 OS: ubuntu wily URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.68.2.190) The handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with a self-signed certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK try Error: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK try OK --===============5651997958048334186==-- From michael@stroeder.com Sat Feb 20 15:13:50 2016 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Sat, 20 Feb 2016 15:13:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8748026550317201697==" --===============8748026550317201697== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 Note that 2.4.31 is almost for years old. Hence the standard question: Can you reproduce this with current release 2.4.44? Ciao, Michael. --===============8748026550317201697==-- From quanah@zimbra.com Sat Feb 20 17:51:25 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Sat, 20 Feb 2016 17:51:23 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1158134257813696795==" --===============1158134257813696795== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, February 19, 2016 4:02 PM +0000 dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 As already noted by Michael, that is an ancient release. In addition, since you're using a build provided by Debian/Ubuntu, it links to GnuTLS which has its own numerous issues. I'd strongly advise you: (a) Use a current OpenLDAP release (b) Use an OpenLDAP release that is linked to OpenSSL rather than GnuTLS If after both of those conditions are true you can still reproduce a problem, please follow up. If building OpenLDAP software is not in your line of expertise, you may wish to examine the options from the LTB project or Symas. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============1158134257813696795==-- From dog@pavlov.com Sat Feb 20 18:06:27 2016 From: dog@pavlov.com To: openldap-bugs@openldap.org Subject: RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Sat, 20 Feb 2016 18:06:25 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0488476989239089964==" --===============0488476989239089964== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.= 4.41, and the results are identical.=20 If I get time I'll run up a test platform and install from source, then drop = you a line with the results. Martin... --===============0488476989239089964==-- From quanah@zimbra.com Sat Feb 20 18:41:59 2016 From: quanah@zimbra.com To: openldap-bugs@openldap.org Subject: RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Sat, 20 Feb 2016 18:41:57 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6577602991853897874==" --===============6577602991853897874== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Saturday, February 20, 2016 6:06 PM +0000 dog(a)pavlov.com wrote: > > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap > to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then > drop you a line with the results. Again, you could just install the builds from the LTB project. In any case, all options work fine for me with a self-signed cert with ldaps:/// URIs. (2.4.44, linked to OpenSSL). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc --===============6577602991853897874==-- From hyc@symas.com Sat Feb 20 21:04:00 2016 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Sat, 20 Feb 2016 21:03:59 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6759887472146731553==" --===============6759887472146731553== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable dog(a)pavlov.com wrote: > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap to = 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then dro= p you a line with the results. What commands are you testing with? Are you using STARTTLS as a critical=20 extension? If not, failures will be ignored. Note that this is already docume= nted. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============6759887472146731553==-- From dog@pavlov.com Sat Feb 20 23:47:58 2016 From: dog@pavlov.com To: openldap-bugs@openldap.org Subject: RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Sat, 20 Feb 2016 23:47:57 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8355059272836940684==" --===============8355059272836940684== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, This is a piece of code that I'm working on, rather than any bundled commands= . The code works just fine (has for months) however I noticed in unit testing= the operations empirically that the LDAP_OPT_X_TLS_REQUIRE_CERT option was h= andled differently depending on whether the TLS was provided implicitly over = an ldaps: URI, or explicitly on an ldap: URI with STARTTLS. The pseudo sequence of functions is as follows: ldap_initialize ldap_set_option (various) if uri !=3D ldaps: then ldap_start_tls_s ldap_sasl_bind_s Martin... --===============8355059272836940684==-- From dog@pavlov.com Sun Feb 21 07:36:29 2016 From: dog@pavlov.com To: openldap-bugs@openldap.org Subject: RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS Date: Sun, 21 Feb 2016 07:36:27 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7864392083449382425==" --===============7864392083449382425== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ok, retested with latest code built from source. I also reconfirmed using a publicly available openldap server, to make sure i= t isn't something stupid I am doing locally.=20 So you can reproduce easily, the test pseudo code is: ldap_initialize (ldaps://ldap.andrew.cmu.edu) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_sasl_bind_s ldap_initialize (ldap://128.2.11.104) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_start_tls_s ldap_sasl_bind_s The results are: Server with valid certificate, all values of LDAP_OPT_X_TLS_REQUIRE_CERT for = both ldaps and ldap+starttls connect. This is what I would expect. Server with invalid certificate (IP does not match the cert FQDN), only NEVER= and ALLOW values of LDAP_OPT_X_TLS_REQUIRE_CERT succeed for ldaps (this is w= hat I would expect) however all values of LDAP_OPT_X_TLS_REQUIRE_CERT for ld= ap+starttls succeed, which is not what I would expect: I think that the certi= ficate check should fail the connection, as per the ldaps behaviour. Martin... --===============7864392083449382425==-- From geert@hendrickx.be Mon Feb 22 07:57:52 2016 From: geert@hendrickx.be To: openldap-bugs@openldap.org Subject: (ITS#8375) paged results control results in full db search? Date: Mon, 22 Feb 2016 07:57:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8512470767287748481==" --===============8512470767287748481== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Geert Hendrickx Version: 2.4.44 OS: Linux URL: http://www.openldap.org/lists/openldap-technical/201602/msg00094.html Submission from: (NULL) (2a02:1810:4d03:d00:18e9:3ca5:a68f:c7f4) We found an odd issue when using LDAP Admin (www.ldapadmin.org), which by defaults uses the paged results control (RFC 2696) to limit search results. This client initially issues an objectclass=* search with one-level scope to list the first-level objects/trees on the LDAP DIT, which you can then browse/expand by clicking on them. On a large db, we noticed this initial search hits the timelimit, even though the equivalent command line search is instant. I found the difference is in using the paged result control: ldapsearch -s one -E \!pr=100 objectclass=\* objectclass => slow ldapsearch -s one objectclass=\* objectclass => fast The slapd stats+trace logging of each is in attachment. Notice the large number of objects being skipped with "scope not okay" in the first, where this does not happen in the second. This slows down the search, and on a very large db, makes it exceed the configured 60 seconds timelimit. A third variant, setting the sizelimit explicitly, avoids the issue: ldapsearch -s one -E \!pr=100 -z 100 objectclass=\* objectclass => fast Is this expected behaviour? --===============8512470767287748481==-- From hguo@suse.com Mon Feb 22 10:59:49 2016 From: hguo@suse.com To: openldap-bugs@openldap.org Subject: (ITS#8376) Use getaddrinfo to resolve FQDN Date: Mon, 22 Feb 2016 10:59:47 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1794512930906997562==" --===============1794512930906997562== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Howard Guo Version: 2.4.44 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.135.221.2) In a pure IPv6 environment, if LDAP is used as the host resolve, the host may hang when it attempts to resolve its own host name due to usage of gethostbyname*, in the following sequence of events: nss_ldap: locks mutex nss_ldap: calls libldapA-A-> libldap: gethostbyname -> nss_ldap: lock mutex and hang See patch file "howard-guo-160222.patch". --===============1794512930906997562==-- From michael@stroeder.com Mon Feb 22 19:39:53 2016 From: michael@stroeder.com To: openldap-bugs@openldap.org Subject: (ITS#8377) Normalized 'olcDbIndex' values Date: Mon, 22 Feb 2016 19:39:51 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0106400149531737375==" --===============0106400149531737375== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name:=20 Version: master OS:=20 URL:=20 Submission from: (NULL) (213.240.182.49) A suggestion for 2.5: Index lines read from slapd.conf should be converted to normalized 'olcDbInde= x' values. With this approach it would be possible to determine index configurat= ion for a certain attribute type. Likewise the format of accepted attribute values should be constrained. Example from slapd.conf: index foo,bar eq,sub would be normalized to 4 values: olcDbIndex: foo eq olcDbIndex: foo sub olcDbIndex: bar eq olcDbIndex: bar sub --===============0106400149531737375==-- From jonathan@phillipoux.net Tue Feb 23 01:11:56 2016 From: jonathan@phillipoux.net To: openldap-bugs@openldap.org Subject: (ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results Date: Tue, 23 Feb 2016 01:11:55 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8165658074807149922==" --===============8165658074807149922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Jonathan Clarke Version: 2.4.44 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.182.31.158) Hi there, I found a bug in the handling of idl_cache when doing a MODRDN operation on an entry with children. The existing code to add an entry in hdb_dn2id_add (dn2id.c) cleverly updates any existing IDL caches on the new parent and any grand-parents, both for "on= e" and "sub" level searches by adding the new entry in those cache lists. However, if you MODRDN an entry that also has children, this same hdb_dn2id_a= dd function is called, and will erroneously update the "sub" level search caches= on the new parent and any grand-parents, adding only the new entry, and not it's children. The result is that a search that hits that IDL cache will return partial results, including the entry that was moved, but missing it's childre= n. You can observe this behaviour by compiling a standard OpenLDAP server, configuring a simple hdb backend, including a non-zero idlcachesize and runni= ng the following commands: 1) ldapadd < tesldldif 2) ldapsearch -b "ou=3DAccepted Inventories,ou=3DInventories,cn=3Drudder-configuration" -s sub objectClass=3DorganizationalUnit 3) ldapmodrdn -s "ou=3DAccepted Inventories,ou=3DInventories,cn=3Drudder-configuration" "ou=3D1234,ou=3DPendi= ng Inventories,ou=3DInventorie2C2Ccn=3Drudder-configuration" "ou=3D1234" 4) ldapsearch -b "ou=3DAccepted Inventories,ou=3DInventories,cn=3Drudder-configuration" -s sub objectClass=3DorganizationalUnit It is important to run the initial search in step 2, before the MODRDN operat= ion itself, to ensure an IDL cache entry is created for that search. The final search in step 4 will not show the sub-entry ou=3D1234-sub,ou=3D1234. The test.ldif file is here: ftp://ftp.openldap.org/incoming/test.ldif I've created a quick'n'dirty patch to hide this issue, which detects the situation (if adding an entry that already has children, this is when the bug occurs) and simply removes the IDL cache to avoid future searches using it. I= t's available here: ftp://ftp.openldap.org/incoming/openldap-dn2id-modrdn-idlcach= e-sub-delete.patch. A better solution would probably be to write the code to add each child of the new entry to existing caches, but I couldn't immediately see how to do this. Hopefully my patch above will easily show where this needs doing. Regards, Jonathan --===============8165658074807149922==-- From hyc@symas.com Fri Feb 26 14:13:24 2016 From: hyc@symas.com To: openldap-bugs@openldap.org Subject: Re: RE : Re: Fwd: (ITS#8331) Download mirror list needs updating Date: Fri, 26 Feb 2016 14:13:22 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3923103506571327368==" --===============3923103506571327368== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit For tracking: David Coutadeur wrote: > > Hi Howard, > > Job done. The repository is available at: > http://repository.linagora.com/OpenLDAP/ > > > Regards, > > David > > Le 17/02/2016 14:59, Howard Chu a écrit : >> David Coutadeur wrote: >>> >>> Hi Howard, >>> >>> I didn't came back on you with that, but the proposition is still opened >>> if it is ok for you. >> >> Sure, sounds great. >> >> It turns out to be very simple, just use rsync. The set of available >> targets can be seen using >> rsync --list-only rsync://openldap.org >> >> The releases are in OpenLDAP-ftp. The CVS repo is also available but >> that's only of historical interest since we're now on git. >> >>> >>> David >>> >>> >>> Le 10/12/2015 09:08, dcoutadeur a écrit : >>>> Ok, thank you for the reply. >>>> Let me know when you have the information. >>>> >>>> David >>>> >>>> >>>> >>>>

-------- Message d'origine --------
De : Howard Chu >>>> <hyc(a)symas.com>
Date : 08/12/2015 17:49 (GMT+01:00)
À >>>> : David Coutadeur <dcoutadeur(a)linagora.com>
Objet : Re: >>>> Fwd: (ITS#8331) Download mirror list needs updating

>>>> >>>> >>>> >>>> David Coutadeur wrote: >>>> > >>>> > Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>> > >>>> > Linagora (France) would be very interested to host a new mirror >>>> for OpenLDAP. >>>> > Do you have an idea of how many connections we should support ? >>>> And what >>>> > bandwidth ? I have made some statistics on an active mirror to >>>> find out the >>>> > data volume. For now it is about 1GB, so I assume 10 GB will be >>>> sufficient for >>>> > many years ? >>>> > >>>> > If you have one, can you also give me a procedure / indications >>>> for building >>>> > the platform ? >>>> > >>>> > Regards, >>>> > >>>> > >>>> > Le 04/12/2015 16:04, Howard Chu a écrit : >>>> >> A number of the mirror sites have gone offline over the years. >>>> Anyone >>>> >> interested in running a new mirror for us? >>>> >> >>>> >> -------- Forwarded Message -------- >>>> >> Subject: (ITS#8331) Download mirror list needs updating >>>> >> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>> >> From: andrew.findlay(a)skills-1st.co.uk >>>> >> To: openldap-its(a)OpenLDAP.org >>>> >> >>>> >> Full_Name: Andrew Findlay >>>> >> Version: >>>> >> OS: >>>> >> URL: ftp://ftp.openldap.org/incoming/ >>>> >> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>> >> >>>> >> >>>> >> The Netherlands mirror has vanished: ftp.nl.uu.net does not >>>> resolve in DNS. >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>>> -- >>>> -- Howard Chu >>>> CTO, Symas Corp. http://www.symas.com >>>> Director, Highland Sun http://highlandsun.com/hyc/ >>>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>>> >>>> >>>> >>>> David Coutadeur wrote: >>>>> >>>>> Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>>> >>>>> Linagora (France) would be very interested to host a new mirror for >>>>> OpenLDAP. >>>>> Do you have an idea of how many connections we should support ? And >>>>> what >>>>> bandwidth ? I have made some statistics on an active mirror to find >>>>> out the >>>>> data volume. For now it is about 1GB, so I assume 10 GB will be >>>>> sufficient for >>>>> many years ? >>>>> >>>>> If you have one, can you also give me a procedure / indications for >>>>> building >>>>> the platform ? >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Le 04/12/2015 16:04, Howard Chu a écrit : >>>>>> A number of the mirror sites have gone offline over the years. Anyone >>>>>> interested in running a new mirror for us? >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: (ITS#8331) Download mirror list needs updating >>>>>> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>>>> From: andrew.findlay(a)skills-1st.co.uk >>>>>> To: openldap-its(a)OpenLDAP.org >>>>>> >>>>>> Full_Name: Andrew Findlay >>>>>> Version: >>>>>> OS: >>>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>>> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>>>> >>>>>> >>>>>> The Netherlands mirror has vanished: ftp.nl.uu.net does not resolve >>>>>> in DNS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --===============3923103506571327368==-- From nivanova@symas.com Mon Feb 29 14:19:46 2016 From: nivanova@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP Date: Mon, 29 Feb 2016 14:19:45 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7938134108382267578==" --===============7938134108382267578== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This patch fixes a problem in the closing of timed-out connections to targets in back-asyncmeta. If a a_metaconn is still in use for another target, the connections to other targets might not be reset while the mc is still active, even if these targets are no longer in use. This patch introduces counters for pending operations per a_metasingleconn, and resets a metasingleconn if it has timed out and has no pending operations. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160229.patch --===============7938134108382267578==-- From jonathan@phillipoux.net Mon Feb 29 18:44:16 2016 From: jonathan@phillipoux.net To: openldap-bugs@openldap.org Subject: Re: (ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results Date: Mon, 29 Feb 2016 18:44:14 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6064241505411349482==" --===============6064241505411349482== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The patch I originally sent works only for MODRDN operations, but causes=20 a segfault on plain old ADD operations in some cases. This is caused by the hdb_dn2id_children function trying to update dkids=20 inside a non-initialised structure. I figure that if we don't have the=20 structure we don't need to update it, since this function is mostly a=20 "search" function. Hope that makes sense. A new patch is here:=20 ftp://www.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete-2.p= atch Jonathan --===============6064241505411349482==--