Re: (ITS#8399) Access to LDAP Server with a wrong password
by quanah＠zimbra.com
--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
7 years, 2 months
(ITS#8399) Access to LDAP Server with a wrong password
by cheu.kuoch＠4tpm.fr
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 (...)
7 years, 2 months
Re: (ITS#8397) Unable to start LDAP Service in Windows
by quanah＠zimbra.com
--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
7 years, 2 months
Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by frank.swasey＠gmail.com
--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=
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--
7 years, 2 months
Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu
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
7 years, 2 months
Re: (ITS#8397) Unable to start LDAP Service in Windows
by charisse.ann.m.jorge＠accenture.com
--_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><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</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_--
7 years, 2 months
Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com
--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
7 years, 2 months
Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com
--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
7 years, 2 months
Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com
--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
7 years, 2 months
Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com
--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
7 years, 2 months
