openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

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

08 Apr '16

Thank you, Quanah for the clear description. I'm not sure if the problem is in syncprov or accesslog (the two overlays touched by the patch for ITS 8281). I do believe that the patch for ITS 8281 is the cause (since the problem goes away if that patch is removed). How can I help at this point? -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

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

07 Apr '16

--On Thursday, April 07, 2016 11:57 PM +0000 quanah(a)zimbra.com wrote: Full summary: the syncprov checkpoint operation causes the CSN to be lost for the first write operation to occur after the checkpoint. It is important to note that no data is lost, all changes replicate as they should. However, the replica CSN is not updated in this scenario, making it appear that the replica is out of sync with the master. Adding the syncprov overlay to a replica database works around this issue by forcing the replica to track its internal CSNs, rather than relying on broadcasts from the master. It is trivial to reproduce this issue by setting a short checkpoint interval with the syncprov-checkpoint parameter. Example of the problem: We have a script modifying the userPassword attribute of an entry every 45 seconds. We have a syncprov-checkpoint set to happen every 5 minutes. >From the log we can see: Apr 7 18:00:38 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:05:53 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:11:09 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:16:25 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:17:55 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:21:41 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:26:57 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Apr 7 18:32:13 zre-ldap002 slapd[29904]: syncprov_sendresp: cookie=rid=100 Stopping the script after the 18:32:13 operation, and examining the CSN values on each server, we see the following. master: [zimbra@zre-ldap003 scripts]$ ldapsearch -x -LLL -H ldap://zre-ldap002.eng.zimbra.com -s base -b "dc=uvm,dc=edu" contextCSN dn: dc=uvm,dc=edu contextCSN: 20160407233212.979013Z#000000#000#000000 replica: [zimbra@zre-ldap003 scripts]$ ldapsearch -x -LLL -H ldapi:// -s base -b "dc=uvm,dc=edu" contextCSN dn: dc=uvm,dc=edu contextCSN: 20160407233127.886702Z#000000#000#000000 Note that the CSNs are 45 seconds apart -- The interval of how often our writes are occurring. So the write op /prior/ to the checkpoint is the CSN value that is left on the replica in this case, as it ignores the empty CSN syncprov send response (thus not updating its CSN). While it is of course best practice to run the syncprov overlay on the replica to enforce internal CSN cohesion, it still should not be required, and this is clearly a bug that can cause admins to incorrectly believe that their servers are having replication issues. --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 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 2:53 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Hi Frank, > > Great to hear!!! I knew there was a reason behind doing so... I've done > so for years, but the exact reasons behind it have drifted into the fog > of time. I did recall it was related to CSNs though, so thought that > this might be it. Hi Frank, This is being caused by the syncprov checkpoint, which is why you see it every hour: syncprov-checkpoint 1000 60 I had one happen in between once... I think it was because it had hit 1000 operations, but not 100% on that.. It would imply that the operations counter is not being reset when the time counter syncs. --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 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 9:22 PM +0000 Frank.Swasey(a)uvm.edu wrote: > Quanah, > > Before I put any time into putting together a patch for syncrepl.c, I > listened to what you said was generally recommended. I added the > syncprov overlay to the consumer, even though it will never be a > provider. I found that with the syncprov overlay after the syncrepl > overlay in the config file, the DSA's CSN will still get out of sync. > However, with the syncprov overlay before the syncrepl overlay - I have > been running for the last three hours without any reports of the DSA's > CSN being wrong on the replica (with one exception that was a check in > the middle of an update and did not coincide with the missing csn value > in the logs). > > Therefore, I'm going to develop a doc patch to fix the guide and man > pages rather than a code patch. Hi Frank, Great to hear!!! I knew there was a reason behind doing so... I've done so for years, but the exact reasons behind it have drifted into the fog of time. I did recall it was related to CSNs though, so thought that this might be 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

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

07 Apr '16

Quanah, Before I put any time into putting together a patch for syncrepl.c, I listened to what you said was generally recommended. I added the syncprov overlay to the consumer, even though it will never be a provider. I found that with the syncprov overlay after the syncrepl overlay in the config file, the DSA's CSN will still get out of sync. However, with the syncprov overlay before the syncrepl overlay - I have been running for the last three hours without any reports of the DSA's CSN being wrong on the replica (with one exception that was a check in the middle of an update and did not coincide with the missing csn value in the logs). Therefore, I'm going to develop a doc patch to fix the guide and man pages rather than a code patch. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

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

07 Apr '16

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 release you're using, 2.3.7, is 11 years old. Nobody on the OpenLDAP Project supports such old versions. Also, no one on the Project knows anything about how Hyperion built this code. The only people who can help you with this are the Hyperion staff. The current OpenLDAP release is 2.4.44. I suggest you upgrade if you want assistance from anyone in the community. Otherwise, I suggest you buy support from a company that actually supports its customers, since it appears that Hyperion Foundation hasn't helped you with their own product. > ________________________________ > > 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_-- > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#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

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