openldap-bugs April 2016

openldap-bugs@openldap.org

19 participants
66 discussions

Re: (ITS#8399) Access to LDAP Server with a wrong password
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 3:00 PM +0000 cheu.kuoch(a)4tpm.fr wrote: > Full_Name: Cheu KUOCH > Version: 2.4.43 > OS: WINDOWS 7 > URL: > Submission from: (NULL) (109.1.238.212) > > > Hi, > > I am a new OpenLDAP 2.4.43 library user. > > My application binds to a customer's LDAP Server and get attributs no > problem, even with a wrong password. > > Could you tell me how to make LDAP Server controls the password ? The ITS system is for reporting software bugs, not asking usage questions. If you have questions on how to properly install and secure OpenLDAP, you should send those questions to the openldap-technical(a)openldap.org list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8399) Access to LDAP Server with a wrong password
by cheu.kuoch＠4tpm.fr 07 Apr '16

07 Apr '16

Full_Name: Cheu KUOCH Version: 2.4.43 OS: WINDOWS 7 URL: Submission from: (NULL) (109.1.238.212) Hi, I am a new OpenLDAP 2.4.43 library user. My application binds to a customer's LDAP Server and get attributs no problem, even with a wrong password. Could you tell me how to make LDAP Server controls the password ? Thank in advance. Cheu KUOCH ================================== Summary of my code: ldap_initialize (&ldap, ldap_urls) ldap_set_option (ldap, LDAP_OPT_PROTOCOL_VERSION, &ldap_version) ldap_set_option (ldap, LDAP_OPT_SIZELIMIT, &size_limit) ldap_sasl_bind_s (ldap, bind_dnp, LDAP_SASL_SIMPLE, &cred, NULL, NULL, NULL) ldap_search_ext (...) for (msgcount = 0; ...) { ldap_result (...) ldap_first_attribute (...) while (...) { ldap_get_values_len (...) ldap_next_attribute (...) } } ldap_unbind_ext_s (...)

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 11:18 AM +0000 charisse.ann.m.jorge(a)accenture.com wrote: > --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Hi, > We already contacted Hyperion Support regarding this, > However, still failed to start the OpenLDAP service. > And we're thinking if it's in the setup of OpenLDAP. > > Kindly advise. Thank you The OpenLDAP project only provides code, no builds. I would note that the version reported (2.3.7) is over 10 years old: OpenLDAP 2.3.7 Release (2005/08/31) I would note that the OpenLDAP project stopped supporting the 2.3 release nearly 7 years ago. I would note that the 2.3.7 release was only the second GA release for OpenLDAP 2.3, with the final 2.3 release being 2.3.43. I.e., you're using ancient, completely software that had years of fixes past the release. You need to work with your vendor on a solution. Alternatively, you could contact Symas to obtain modern, updated OpenLDAP 2.4 based builds and a support contract (http://www.symas.com). There is nothing the project can do for you, given all of the above. Regards, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by frank.swasey＠gmail.com 07 Apr '16

07 Apr '16

--001a113f999e8de01b052fe42f4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Quanah, I do see in the consumer log that it is retrieving and applying the updates. So the do_syncrep2 log entries also show the missing ,csn=3D... condition. Therefore, yes, there is no delay in data the actual replication being performed - there is a delay (as evidenced by the check of the CSN in the DSA of the provider and consumer report) in the CSN attribute for the DSA being updated. Clearly, syncrepl sees the CSN's coming across so it should be able to handle the lack of the CSN being in the response from the provider and get the DSA's CSN updated. I'll see if I can figure out a patch that will work. (sending from my personal address because I'm tired of gauss marking everything I send as probably spam - I'm not really that suspicious a character) - Frank On Thu, Apr 7, 2016 at 8:20 AM, Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > On 4/7/16, 12:04 AM, "openldap-bugs on behalf of quanah(a)zimbra.com" < > openldap-bugs-bounces(a)openldap.org on behalf of quanah(a)zimbra.com> wrote: > > >--On Thursday, April 07, 2016 4:22 AM +0000 quanah(a)zimbra.com wrote: > > > >> So the change is still correctly replicated to the replicating MMR nod= e. > > > >I see the same behavior with the example configuration that was provided > as > >well. While the CSN bit may not be logged, the change is replicated as = it > >should be. > > <snip> > > > >So while the lack of the ,csn bit is annoying... I see no actual data > loss, > >etc. > > > Quanah, > > I=E2=80=99ll go peer deeper into the logs on the consumer side. > > If I find the same here, that indicates the provider is saying =E2=80= =9Cthere > are changes=E2=80=9D but not sending the CSN and syncrepl is retrieving a= nd > applying the changes, but not updating the CSN in the DSA of the consumer= . > Which suggests that syncrepl needs a patch or that I should not be trusti= ng > the CSN value in the consumer=E2=80=99s DSA in the check_syncrepl script = (although, > I can=E2=80=99t think of another quick way to assess whether the provider= and > consumer are in sync - off the top of my head). Eventually, syncprov doe= s > send the CSN and the consumer=E2=80=99s CSN gets updated, so things repor= t as > having caught up. > > - Frank > > --=20 I am not young enough to know everything. - Oscar Wilde (1854-1900) --001a113f999e8de01b052fe42f4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Quanah,<div><br></div><div>=C2=A0 I do see in the consumer= log that it is retrieving and applying the updates.=C2=A0 So the do_syncre= p2 log entries also show the missing ,csn=3D... condition. =C2=A0</div><div= ><br></div><div>=C2=A0 Therefore, yes, there is no delay in data the actual= replication being performed - there is a delay (as evidenced by the check = of the CSN in the DSA of the provider and consumer report) in the CSN attri= bute for the DSA being updated.=C2=A0 Clearly, syncrepl sees the CSN's = coming across so it should be able to handle the lack of the CSN being in t= he response from the provider and get the DSA's CSN updated.=C2=A0 I&#3= 9;ll see if I can figure out a patch that will work.</div><div><br></div><d= iv>(sending from my personal address because I'm tired of gauss marking= everything I send as probably spam - I'm not really that suspicious a = character)</div><div><br></div><div>- Frank</div></div><div class=3D"gmail_= extra"><br><div class=3D"gmail_quote">On Thu, Apr 7, 2016 at 8:20 AM, Frank= Swasey <span dir=3D"ltr"><<a href=3D"mailto:Frank.Swasey@uvm.edu" targe= t=3D"_blank">Frank.Swasey(a)uvm.edu</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex">On 4/7/16, 12:04 AM, "openldap-bugs on behalf of <a hre= f=3D"mailto:quanah@zimbra.com">quanah(a)zimbra.com</a>" <<a href=3D"m= ailto:openldap-bugs-bounces@openldap.org">openldap-bugs-bounces(a)openldap.or= g</a> on behalf of <a href=3D"mailto:quanah@zimbra.com">quanah(a)zimbra.com</= a>> wrote:<br> <br> >--On Thursday, April 07, 2016 4:22 AM +0000 <a href=3D"mailto:quanah@zi= mbra.com">quanah(a)zimbra.com</a> wrote:<br> ><br> >> So the change is still correctly replicated to the replicating MMR= node.<br> ><br> >I see the same behavior with the example configuration that was provide= d as<br> >well.=C2=A0 While the CSN bit may not be logged, the change is replicat= ed as it<br> >should be.<br> <br> <snip><br> ><br> >So while the lack of the ,csn bit is annoying... I see no actual data l= oss,<br> >etc.<br> <br> <br> Quanah,<br> <br> =C2=A0 I=E2=80=99ll go peer deeper into the logs on the consumer side.<br> <br> =C2=A0 If I find the same here, that indicates the provider is saying =E2= =80=9Cthere are changes=E2=80=9D but not sending the CSN and syncrepl is re= trieving and applying the changes, but not updating the CSN in the DSA of t= he consumer.=C2=A0 Which suggests that syncrepl needs a patch or that I sho= uld not be trusting the CSN value in the consumer=E2=80=99s DSA in the chec= k_syncrepl script (although, I can=E2=80=99t think of another quick way to = assess whether the provider and consumer are in sync - off the top of my he= ad).=C2=A0 Eventually, syncprov does send the CSN and the consumer=E2=80=99= s CSN gets updated, so things report as having caught up.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Frank<br> <br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r><div class=3D"gmail_signature">I am not young enough to know everything. = - Oscar Wilde (1854-1900)</div> </div> --001a113f999e8de01b052fe42f4a--

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 07 Apr '16

07 Apr '16

T24gNC83LzE2LCAxMjowNCBBTSwgIm9wZW5sZGFwLWJ1Z3Mgb24gYmVoYWxmIG9mIHF1YW5haEB6 aW1icmEuY29tIiA8b3BlbmxkYXAtYnVncy1ib3VuY2VzQG9wZW5sZGFwLm9yZyBvbiBiZWhhbGYg b2YgcXVhbmFoQHppbWJyYS5jb20+IHdyb3RlOg0KDQo+LS1PbiBUaHVyc2RheSwgQXByaWwgMDcs IDIwMTYgNDoyMiBBTSArMDAwMCBxdWFuYWhAemltYnJhLmNvbSB3cm90ZToNCj4NCj4+IFNvIHRo ZSBjaGFuZ2UgaXMgc3RpbGwgY29ycmVjdGx5IHJlcGxpY2F0ZWQgdG8gdGhlIHJlcGxpY2F0aW5n IE1NUiBub2RlLg0KPg0KPkkgc2VlIHRoZSBzYW1lIGJlaGF2aW9yIHdpdGggdGhlIGV4YW1wbGUg Y29uZmlndXJhdGlvbiB0aGF0IHdhcyBwcm92aWRlZCBhcyANCj53ZWxsLiAgV2hpbGUgdGhlIENT TiBiaXQgbWF5IG5vdCBiZSBsb2dnZWQsIHRoZSBjaGFuZ2UgaXMgcmVwbGljYXRlZCBhcyBpdCAN Cj5zaG91bGQgYmUuDQoNCjxzbmlwPg0KPg0KPlNvIHdoaWxlIHRoZSBsYWNrIG9mIHRoZSAsY3Nu IGJpdCBpcyBhbm5veWluZy4uLiBJIHNlZSBubyBhY3R1YWwgZGF0YSBsb3NzLCANCj5ldGMuDQoN Cg0KUXVhbmFoLA0KDQogIEnigJlsbCBnbyBwZWVyIGRlZXBlciBpbnRvIHRoZSBsb2dzIG9uIHRo ZSBjb25zdW1lciBzaWRlLiAgDQoNCiAgSWYgSSBmaW5kIHRoZSBzYW1lIGhlcmUsIHRoYXQgaW5k aWNhdGVzIHRoZSBwcm92aWRlciBpcyBzYXlpbmcg4oCcdGhlcmUgYXJlIGNoYW5nZXPigJ0gYnV0 IG5vdCBzZW5kaW5nIHRoZSBDU04gYW5kIHN5bmNyZXBsIGlzIHJldHJpZXZpbmcgYW5kIGFwcGx5 aW5nIHRoZSBjaGFuZ2VzLCBidXQgbm90IHVwZGF0aW5nIHRoZSBDU04gaW4gdGhlIERTQSBvZiB0 aGUgY29uc3VtZXIuICBXaGljaCBzdWdnZXN0cyB0aGF0IHN5bmNyZXBsIG5lZWRzIGEgcGF0Y2gg b3IgdGhhdCBJIHNob3VsZCBub3QgYmUgdHJ1c3RpbmcgdGhlIENTTiB2YWx1ZSBpbiB0aGUgY29u c3VtZXLigJlzIERTQSBpbiB0aGUgY2hlY2tfc3luY3JlcGwgc2NyaXB0IChhbHRob3VnaCwgSSBj YW7igJl0IHRoaW5rIG9mIGFub3RoZXIgcXVpY2sgd2F5IHRvIGFzc2VzcyB3aGV0aGVyIHRoZSBw cm92aWRlciBhbmQgY29uc3VtZXIgYXJlIGluIHN5bmMgLSBvZmYgdGhlIHRvcCBvZiBteSBoZWFk KS4gIEV2ZW50dWFsbHksIHN5bmNwcm92IGRvZXMgc2VuZCB0aGUgQ1NOIGFuZCB0aGUgY29uc3Vt ZXLigJlzIENTTiBnZXRzIHVwZGF0ZWQsIHNvIHRoaW5ncyByZXBvcnQgYXMgaGF2aW5nIGNhdWdo dCB1cC4NCg0KLSBGcmFuaw0K

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by charisse.ann.m.jorge＠accenture.com 07 Apr '16

07 Apr '16

--_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We already contacted Hyperion Support regarding this, However, still failed to start the OpenLDAP service. And we're thinking if it's in the setup of OpenLDAP. Kindly advise. Thank you ________________________________ This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise confidential information. If you have received= it in error, please notify the sender immediately and delete the original.= Any other use of the e-mail by you is prohibited. Where allowed by local l= aw, electronic communications with Accenture and its affiliates, including = e-mail and instant messaging (including content), may be scanned by our sys= tems for the purposes of information security and assessment of internal co= mpliance with Accenture policy. ___________________________________________________________________________= ___________ www.accenture.com --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema= s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html= 40"> <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"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi,<o:p></o:p></p> <p class=3D"MsoNormal">We already contacted Hyperion Support regarding this= , <o:p></o:p></p> <p class=3D"MsoNormal">However, still failed to start the OpenLDAP service.= <o:p></o:p></p> <p class=3D"MsoNormal">And we're thinking if it's in the setup of OpenLDAP.= <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Kindly advise. Thank you<o:p></o:p></p> </div> <br> <hr> <font face=3D"Arial" color=3D"Gray" size=3D"1"><br> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise confidential information. If you have received= it in error, please notify the sender immediately and delete the original.= Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications w= ith Accenture and its affiliates, including e-mail and instant messaging (i= ncluding content), may be scanned by our systems for the purposes of inform= ation security and assessment of internal compliance with Accenture policy. <br> ___________________________________________________________________________= ___________<br> <br> www.accenture.com<br> </font> </body> </html> --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_--

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Thursday, April 07, 2016 4:22 AM +0000 quanah(a)zimbra.com wrote: > So the change is still correctly replicated to the replicating MMR node. I see the same behavior with the example configuration that was provided as well. While the CSN bit may not be logged, the change is replicated as it should be. Provider: Apr 6 22:59:28 zre-ldap002 slapd[22212]: slap_queue_csn: queueing 0x4ab3600 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap002 slapd[22212]: slap_graduate_commit_csn: removing 0x4ab3600 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap002 slapd[22212]: syncprov_sendresp: cookie=rid=100 Apr 6 22:59:28 zre-ldap002 slapd[22212]: conn=1003 op=1 RESULT tag=103 err=0 etime=0.084274 text= Replica: Apr 6 22:59:28 zre-ldap003 slapd[7947]: do_syncrep2: rid=100 cookie=rid=100 Apr 6 22:59:28 zre-ldap003 slapd[7947]: slap_queue_csn: queueing 0x37403c0 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap003 slapd[7947]: slap_graduate_commit_csn: removing 0x37403c0 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap003 slapd[7947]: syncrepl_message_to_op: rid=100 be_modify uid=fcs,ou=People,dc=uvm,dc=edu (0) So while the lack of the ,csn bit is annoying... I see no actual data loss, etc. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Thursday, April 07, 2016 4:05 AM +0000 quanah(a)zimbra.com wrote: > --On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey(a)uvm.edu wrote: > > Hi Frank, > > Actually, I see this affects all forms of replication. On my ldap > servers it is much more frequent than hourly: > Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, > cookie=rid=102,sid=003 Interestingly, for MMR, this does not result in any data loss, as the changes are replicated w/o problem: MMR node taking writes: Apr 6 21:56:47 ldap01 slapd[34514]: slap_queue_csn: queueing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: slap_graduate_commit_csn: removing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: conn=2909 op=286509 RESULT tag=103 err=0 etime=0.000935 text= Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 MMR node receiving writes: Apr 6 21:56:47 ldap02 slapd[61570]: do_syncrep2: rid=102 cookie=rid=102,sid=003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x80ee240 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: syncprov_matchops: skipping original sid 003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x80ee240 20160407025647.107497Z#000000#003#000000 So the change is still correctly replicated to the replicating MMR node. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey(a)uvm.edu wrote: Hi Frank, Actually, I see this affects all forms of replication. On my ldap servers it is much more frequent than hourly: Apr 6 20:57:51 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 20:58:33 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:00:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:00:28 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:01:24 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:03:29 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:04:32 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:06:02 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:07:02 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:07:51 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:09:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:10:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:11:03 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:11:26 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:13:03 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:17:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:18:27 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:21:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:23:55 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:25:00 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:25:36 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:26:57 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:27:55 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:29:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:30:38 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:31:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:31:10 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:32:20 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:33:27 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:35:16 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:37:07 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:38:21 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:39:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:40:16 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:41:11 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:42:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:42:59 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:43:32 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:44:31 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:45:50 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:48:01 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:48:36 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:51:00 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:51:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:53:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:54:28 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:55:21 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:56:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:58:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:59:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:01:01 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:01:33 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:02:30 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:03:41 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Thursday, April 07, 2016 12:04 AM +0000 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > On 4/6/16, 4:01 PM, "openldap-bugs on behalf of quanah(a)zimbra.com" > <openldap-bugs-bounces(a)openldap.org on behalf of quanah(a)zimbra.com> wrote: > >> Hi Frank, >> >> I'm going to see if I can reproduce this in my setup with your >> configurations. I did notice that you don't have the syncprov overlay >> loaded on your replica, which is generally recommended. > > Quanah, > > I've never heard that recommendation. Nor, do I find it in the > slapo-syncprov man page or the Administrator's guide discussion of the > syncprov overlay and delta-syncrepl configuration. Please provide a > reference to that recommendation. You just read it. ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2016