OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Documentation/8396
Full headers

From: Frank.Swasey@uvm.edu
Subject: syncprov hourly fails to answer syncrepl
Compose comment
Download message
State:
0 replies:
25 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 04 Apr 2016 18:57:35 +0000
From: Frank.Swasey@uvm.edu
To: openldap-its@OpenLDAP.org
Subject: syncprov hourly fails to answer syncrepl
Full_Name: Francis Swasey
Version: 2.4.44
OS: Red Hat Enterprise Linux Server release 7.2 (Maipo)
URL: http://www.uvm.edu/~fcs/openldap_its/syncprov_files.tar.gz
Submission from: (NULL) (132.198.104.198)


Once an hour, the primary server logs a syncprov_sendresp that does not include
a csn.  When that happens, the replica misses that there were changes and does
not update and therefore falls behind.

The URI provides files for the primary and replica.  

replica/slapd_db.ldif -- starting database
replica/slapd.conf -- replica's slapd configuration file (you'll need to create
your own ssl certs)
replica/syncrepl_audit.sh -- Runs on the replica (edit the email address and the
path to check_syncrepl
replica/check_syncrepl -- Used by nagios to report csn being in sync or not

primary/slapd_db.ldif -- starting database (almost exactly like the replica's
version)
primary/slapd.conf -- primary's slapd configuration file (you'll need to create
your own ssl certs)
primary/syncprov_audit.sh -- greps the system log (edit the path) looking for
the syncprov error
primary/makechanges.sh -- edit to change the name of the ldap server and run
this to make constant changes

The bad log entries that coincide with check_syncrepl finding the replica has
fallen behind are like:

Apr  4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
Apr  4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
Apr  4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
Apr  4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100

They appear once an hour.

Followup 1

Download message
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
Date: Tue, 5 Apr 2016 22:22:53 +0000
VG9kYXksIEkgaGF2ZSBidWlsdCBhbmQgdGVzdGVkIDIuNC40NCwgMi40LjQzLCBhbmQgMi40LjQy
IHdpdGhvdXQgdGhlIG5vcm1hbCBtb2RpZmljYXRpb25zIHRoYXQgSSBtYWtlIHRvIHRoZSBjb2Rl
IGJhc2UuICBJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUgdGhp
cyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZlciBh
bmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNvZGUg
aGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciB0d28gaG91cnMgbm93IChhbmQganVzdCBhcyBpbiBt
eSBwcm9kdWN0aW9uIGVudmlyb25tZW50KSBoYXMgbm90IGZhaWxlZCBhdCBhbGwuDQoNClRoZSBv
cHRpb25zIEkgYW0gdXNpbmcgd2l0aCBjb25maWd1cmUgYXJlOg0KDQpleHBvcnQgQ0ZMQUdTPSIt
RE5ERUJVRyAtRF9SRUVOVFJBTlQgLWZQSUMiDQpleHBvcnQgTElCUz0iLWxwdGhyZWFkIg0KLi9j
b25maWd1cmUgXA0KICAgICAgICAtcSBcDQogICAgICAgIC0tZW5hYmxlLWR5bmFtaWMgXA0KICAg
ICAgICAtLWVuYWJsZS1zdGF0aWMgXA0KICAgICAgICAtLXdpdGgtdGhyZWFkcz1wb3NpeCBcDQog
ICAgICAgIC0td2l0aC10bHM9b3BlbnNzbCBcDQogICAgICAgIC0td2l0aC1jeXJ1cy1zYXNsIFwN
CiAgICAgICAgLS1lbmFibGUtd3JhcHBlcnMgXA0KICAgICAgICAtLWVuYWJsZS1wYXNzd2QgXA0K
ICAgICAgICAtLWVuYWJsZS1jbGVhcnRleHQgXA0KICAgICAgICAtLWVuYWJsZS1jcnlwdCBcDQog
ICAgICAgIC0tZW5hYmxlLXNwYXNzd2QgXA0KICAgICAgICAtLWVuYWJsZS1sbXBhc3N3ZCBcDQog
ICAgICAgIC0tZW5hYmxlLW1vZHVsZXMgXA0KICAgICAgICAtLWVuYWJsZS1pcHY2IFwNCiAgICAg
ICAgXA0KICAgICAgICAtLWVuYWJsZS1zbGFwZCBcDQogICAgICAgIC0tZW5hYmxlLWJhY2tlbmRz
PW1vZCBcDQogICAgICAgIC0tZGlzYWJsZS1uZGIgXA0KICAgICAgICAtLWRpc2FibGUtc3FsIFwN
CiAgICAgICAgLS1kaXNhYmxlLXBlcmwgXA0KICAgICAgICAtLWRpc2FibGUtc2hlbGwgXA0KICAg
ICAgICAtLWVuYWJsZS1vdmVybGF5cz1tb2QNCg0KDQrigJQNCkZyYW5rIFN3YXNleQ0KU3lzdGVt
cyBBcmNoaXRlY3R1cmUgJiBBZG1pbmlzdHJhdGlvbg0KDQoNCg0KDQoNCg==



Followup 2

Download message
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
Date: Tue, 5 Apr 2016 22:34:42 +0000
U2Vjb25kIGF0dGVtcHQgLSBzb21ldGhpbmcgYWJvdXQgbXkgZmlyc3QgYXR0ZW1wdCBzZWVtcyB0
byBoYXZlIHRyaXBwZWQgdGhlIHNwYW0gZmlsdGVyIGF0IGdhdXNzLg0KDQpUb2RheSwgSSBoYXZl
IGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIgd2l0aG91dCB0aGUg
bm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUgYmFzZS4gIEkgaGF2
ZSBmb3VuZCB0aGF0IGJvdGggMi40LjQ0IGFuZCAyLjQuNDMgaGF2ZSB0aGlzIGZhaWx1cmUgd2l0
aGluIGFuIGhvdXIgb2Ygc3RhcnRpbmcgdGhlIHByaW1hcnkgc2VydmVyIGFuZCBvbmNlIGFuIGhv
dXIgYWZ0ZXIgaXQgZmlyc3QgaGFwcGVucy4gIFRoZSAyLjQuNDIgY29kZSBoYXMgYmVlbiBydW5u
aW5nIGZvciBvdmVyIHR3byBob3VycyBub3cgKGFuZCBqdXN0IGFzIGluIG15IHByb2R1Y3Rpb24g
ZW52aXJvbm1lbnQpIGhhcyBub3QgZmFpbGVkIGF0IGFsbC4NCg0KVGhlIG9wdGlvbnMgSSBhbSB1
c2luZyB3aXRoIGNvbmZpZ3VyZSBhcmU6DQoNCmV4cG9ydCBDRkxBR1M9Ii1ETkRFQlVHIC1EX1JF
RU5UUkFOVCAtZlBJQyINCmV4cG9ydCBMSUJTPSItbHB0aHJlYWQiDQouL2NvbmZpZ3VyZSBcDQog
ICAgICAgIC1xIFwNCiAgICAgICAgLS1lbmFibGUtZHluYW1pYyBcDQogICAgICAgIC0tZW5hYmxl
LXN0YXRpYyBcDQogICAgICAgIC0td2l0aC10aHJlYWRzPXBvc2l4IFwNCiAgICAgICAgLS13aXRo
LXRscz1vcGVuc3NsIFwNCiAgICAgICAgLS13aXRoLWN5cnVzLXNhc2wgXA0KICAgICAgICAtLWVu
YWJsZS13cmFwcGVycyBcDQogICAgICAgIC0tZW5hYmxlLXBhc3N3ZCBcDQogICAgICAgIC0tZW5h
YmxlLWNsZWFydGV4dCBcDQogICAgICAgIC0tZW5hYmxlLWNyeXB0IFwNCiAgICAgICAgLS1lbmFi
bGUtc3Bhc3N3ZCBcDQogICAgICAgIC0tZW5hYmxlLWxtcGFzc3dkIFwNCiAgICAgICAgLS1lbmFi
bGUtbW9kdWxlcyBcDQogICAgICAgIC0tZW5hYmxlLWlwdjYgXA0KICAgICAgICBcDQogICAgICAg
IC0tZW5hYmxlLXNsYXBkIFwNCiAgICAgICAgLS1lbmFibGUtYmFja2VuZHM9bW9kIFwNCiAgICAg
ICAgLS1kaXNhYmxlLW5kYiBcDQogICAgICAgIC0tZGlzYWJsZS1zcWwgXA0KICAgICAgICAtLWRp
c2FibGUtcGVybCBcDQogICAgICAgIC0tZGlzYWJsZS1zaGVsbCBcDQogICAgICAgIC0tZW5hYmxl
LW92ZXJsYXlzPW1vZA0KDQoNCuKAlA0KRnJhbmsgU3dhc2V5DQpTeXN0ZW1zIEFyY2hpdGVjdHVy
ZSAmIEFkbWluaXN0cmF0aW9uDQo=



Followup 3

Download message
Date: Tue, 05 Apr 2016 16:02:38 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank.Swasey@uvm.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Tuesday, April 05, 2016 11:35 PM +0000 Frank.Swasey@uvm.edu wrote:


It's ok, it is trivial to run through a mime decoder.  So the regression 
was added in 2.4.43.

--Quanah



--

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



Followup 4

Download message
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
Date: Wed, 6 Apr 2016 11:43:59 +0000
WWVzdGVyZGF5LCBJIGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIg
d2l0aG91dCB0aGUgbm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUg
YmFzZS4gIA0KDQpJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUg
dGhpcyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZl
ciBhbmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNv
ZGUgaGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciBmaWZ0ZWVuIGhvdXJzIG5vdyBoYXMgbm90IGZh
aWxlZCBhdCBhbGwuDQoNClRoZSBzY3JpcHQgSSB1c2VkIHRvIGJ1aWxkIHRoZXNlIGlzIGF2YWls
YWJsZSBoZXJlOg0KDQpodHRwOi8vd3d3LnV2bS5lZHUvfmZjcy9vcGVubGRhcF9pdHMvYnVpbGQt
b3BlbmxkYXAuc2gNCg0K4oCUDQpGcmFuayBTd2FzZXkNClN5c3RlbXMgQXJjaGl0ZWN0dXJlICYg
QWRtaW5pc3RyYXRpb24NCg0K



Followup 5

Download message
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
Date: Wed, 6 Apr 2016 14:08:28 +0000
SSBhbSBidWlsZGluZyBhIHZlcnNpb24gb2YgMi40LjQzIHdpdGggSVRTODI4MSByZW1vdmVkLiAg
V2lsbCBzZWUgaWYgdGhhdCByZXNvbHZlcyB0aGUgaXNzdWUuDQoNCuKAlA0KRnJhbmsgU3dhc2V5
DQpTeXN0ZW1zIEFyY2hpdGVjdHVyZSAmIEFkbWluaXN0cmF0aW9uDQoNCg0KDQoNCg0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvcGVubGRhcC1idWdzIDxvcGVubGRhcC1i
dWdzLWJvdW5jZXNAb3BlbmxkYXAub3JnPiBvbiBiZWhhbGYgb2YgIkZyYW5rLlN3YXNleUB1dm0u
ZWR1IiA8RnJhbmsuU3dhc2V5QHV2bS5lZHU+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDYsIDIw
MTYgYXQgNzo0NSBBTQ0KVG86ICJvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnIiA8b3BlbmxkYXAt
aXRzQG9wZW5sZGFwLm9yZz4NClN1YmplY3Q6IFJlOiAoSVRTIzgzOTYpIHN5bmNwcm92IGhvdXJs
eSBmYWlscyB0byBhbnN3ZXIgc3luY3JlcGwNCg0KPldXVnpkR1Z5WkdGNUxDQkpJR0oxYVd4MElH
RnVaQ0IwWlhOMFpXUWdNaTQwTGpRMExDQXlMalF1TkRNc0lHRnVaQ0F5TGpRdU5ESWcNCj5kMmww
YUc5MWRDQjBhR1VnYm05eWJXRnNJRzF2WkdsbWFXTmhkR2x2Ym5NZ2RHaGhkQ0JKSUcxaGEyVWdk
RzhnZEdobElHTnZaR1VnDQo+WW1GelpTNGdJQTBLRFFwSklHaGhkbVVnWm05MWJtUWdkR2hoZENC
aWIzUm9JREl1TkM0ME5DQmhibVFnTWk0MExqUXpJR2hoZG1VZw0KPmRHaHBjeUJtWVdsc2RYSmxJ
SGRwZEdocGJpQmhiaUJvYjNWeUlHOW1JSE4wWVhKMGFXNW5JSFJvWlNCd2NtbHRZWEo1SUhObGNu
WmwNCj5jaUJoYm1RZ2IyNWpaU0JoYmlCb2IzVnlJR0ZtZEdWeUlHbDBJR1pwY25OMElHaGhjSEJs
Ym5NdUlDQlVhR1VnTWk0MExqUXlJR052DQo+WkdVZ2FHRnpJR0psWlc0Z2NuVnVibWx1WnlCbWIz
SWdiM1psY2lCbWFXWjBaV1Z1SUdodmRYSnpJRzV2ZHlCb1lYTWdibTkwSUdaaA0KPmFXeGxaQ0Jo
ZENCaGJHd3VEUW9OQ2xSb1pTQnpZM0pwY0hRZ1NTQjFjMlZrSUhSdklHSjFhV3hrSUhSb1pYTmxJ
R2x6SUdGMllXbHMNCj5ZV0pzWlNCb1pYSmxPZzBLRFFwb2RIUndPaTh2ZDNkM0xuVjJiUzVsWkhV
dmZtWmpjeTl2Y0dWdWJHUmhjRjlwZEhNdlluVnBiR1F0DQo+YjNCbGJteGtZWEF1YzJnTkNnMEs0
b0NVRFFwR2NtRnVheUJUZDJGelpYa05DbE41YzNSbGJYTWdRWEpqYUdsMFpXTjBkWEpsSUNZZw0K
PlFXUnRhVzVwYzNSeVlYUnBiMjROQ2cwSw0KPg0KPg0KPg0K



Followup 6

Download message
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
Date: Wed, 6 Apr 2016 18:57:38 +0000
SSBoYXZlIGJhY2tlZCBvdXQgdGhlIElUUyM4MjgxIHBhdGNoIGZyb20gbXkgbG9jYWwgYnVpbGRz
IG9mIDIuNC40MyBhbmQgMi40LjQ0LiBUaGV5IGhhdmUgYm90aCBydW4gd2l0aG91dCBpc3N1ZSBm
b3IgdHdvIGhvdXJzIGVhY2guICBUaGVyZWZvcmUsIEnigJltIHByZXR0eSBzdXJlIHRoYXQgdGhl
IGNhdXNlIG9mIHRoZSBzeW5jcHJvdiBmYWlsdXJlIGlzIHRoYXQgcGF0Y2guICBJdCBtYXkgd29y
ayB3ZWxsIGluIGFuIE1NUiBlbnZpcm9ubWVudCwgYnV0IGl0IGlzIGZhaWxpbmcgaW4gYSBzaW5n
bGUgbWFzdGVyIHNldHVwLg0KDQotIEZyYW5rDQoNCg0K



Followup 7

Download message
Date: Wed, 06 Apr 2016 13:01:11 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank.Swasey@uvm.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Wednesday, April 06, 2016 7:58 PM +0000 Frank.Swasey@uvm.edu wrote:

> SSBoYXZlIGJhY2tlZCBvdXQgdGhlIElUUyM4MjgxIHBhdGNoIGZyb20gbXkgbG9jYWwgYnVpb
> GRz
> IG9mIDIuNC40MyBhbmQgMi40LjQ0LiBUaGV5IGhhdmUgYm90aCBydW4gd2l0aG91dCBpc3N1Z
> SBm
> b3IgdHdvIGhvdXJzIGVhY2guICBUaGVyZWZvcmUsIEnigJltIHByZXR0eSBzdXJlIHRoYXQgd
> Ghl
> IGNhdXNlIG9mIHRoZSBzeW5jcHJvdiBmYWlsdXJlIGlzIHRoYXQgcGF0Y2guICBJdCBtYXkgd
> 29y
> ayB3ZWxsIGluIGFuIE1NUiBlbnZpcm9ubWVudCwgYnV0IGl0IGlzIGZhaWxpbmcgaW4gYSBza
> W5n bGUgbWFzdGVyIHNldHVwLg0KDQotIEZyYW5rDQoNCg0K

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


--

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



Followup 8

Download message
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: "quanah@zimbra.com" <quanah@zimbra.com>,
        "openldap-its@OpenLDAP.org"
	<openldap-its@OpenLDAP.org>
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
Date: Wed, 6 Apr 2016 23:04:00 +0000
T24gNC82LzE2LCA0OjAxIFBNLCAib3BlbmxkYXAtYnVncyBvbiBiZWhhbGYgb2YgcXVhbmFoQHpp
bWJyYS5jb20iIDxvcGVubGRhcC1idWdzLWJvdW5jZXNAb3BlbmxkYXAub3JnIG9uIGJlaGFsZiBv
ZiBxdWFuYWhAemltYnJhLmNvbT4gd3JvdGU6DQoNCj5IaSBGcmFuaywNCj4NCj5JJ20gZ29pbmcg
dG8gc2VlIGlmIEkgY2FuIHJlcHJvZHVjZSB0aGlzIGluIG15IHNldHVwIHdpdGggeW91ciANCj5j
b25maWd1cmF0aW9ucy4gIEkgZGlkIG5vdGljZSB0aGF0IHlvdSBkb24ndCBoYXZlIHRoZSBzeW5j
cHJvdiBvdmVybGF5IA0KPmxvYWRlZCBvbiB5b3VyIHJlcGxpY2EsIHdoaWNoIGlzIGdlbmVyYWxs
eSByZWNvbW1lbmRlZC4NCg0KUXVhbmFoLA0KDQogIEnigJl2ZSBuZXZlciBoZWFyZCB0aGF0IHJl
Y29tbWVuZGF0aW9uLiAgTm9yLCBkbyBJIGZpbmQgaXQgaW4gdGhlIHNsYXBvLXN5bmNwcm92IG1h
biBwYWdlIG9yIHRoZSBBZG1pbmlzdHJhdG9y4oCZcyBndWlkZSBkaXNjdXNzaW9uIG9mIHRoZSBz
eW5jcHJvdiBvdmVybGF5IGFuZCBkZWx0YS1zeW5jcmVwbCBjb25maWd1cmF0aW9uLiAgUGxlYXNl
IHByb3ZpZGUgYSByZWZlcmVuY2UgdG8gdGhhdCByZWNvbW1lbmRhdGlvbi4NCg0KLSBGcmFuaw0K
DQo=



Followup 9

Download message
Date: Wed, 06 Apr 2016 16:20:56 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank Swasey <Frank.Swasey@uvm.edu>, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Thursday, April 07, 2016 12:04 AM +0000 Frank Swasey 
<Frank.Swasey@uvm.edu> wrote:

> On 4/6/16, 4:01 PM, "openldap-bugs on behalf of quanah@zimbra.com"
> <openldap-bugs-bounces@openldap.org on behalf of quanah@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



Followup 10

Download message
Date: Wed, 06 Apr 2016 20:05:31 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank.Swasey@uvm.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey@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_se

Message of length 5223 truncated


Followup 11

Download message
Date: Wed, 06 Apr 2016 20:22:01 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Thursday, April 07, 2016 4:05 AM +0000 quanah@zimbra.com wrote:

> --On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey@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



Followup 12

Download message
Date: Wed, 06 Apr 2016 21:04:33 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Thursday, April 07, 2016 4:22 AM +0000 quanah@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



Followup 13

Download message
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: "quanah@zimbra.com" <quanah@zimbra.com>,
        "openldap-its@openldap.org"
	<openldap-its@openldap.org>
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
Date: Thu, 7 Apr 2016 12:05:20 +0000
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



Followup 14

Download message
Date: Thu, 7 Apr 2016 08:26:20 -0400
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
From: Frank Swasey <frank.swasey@gmail.com>
To: quanah@zimbra.com, openldap-its@openldap.org
Cc: Frank Swasey <Frank.Swasey@uvm.edu>
--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@uvm.edu> wrote:

> On 4/7/16, 12:04 AM, "openldap-bugs on behalf of quanah@zimbra.com" <
> openldap-bugs-bounces@openldap.org on behalf of quanah@zimbra.com>
wrote:
>
> >--On Thursday, April 07, 2016 4:22 AM +0000 quanah@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&#39;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&#39;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&#39;m tired of gauss
marking=
 everything I send as probably spam - I&#39;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">&lt;<a
href=3D"mailto:Frank.Swasey@uvm.edu" targe=
t=3D"_blank">Frank.Swasey@uvm.edu</a>&gt;</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, &quot;openldap-bugs on behalf of
<a hre=
f=3D"mailto:quanah@zimbra.com">quanah@zimbra.com</a>&quot;
&lt;<a href=3D"m=
ailto:openldap-bugs-bounces@openldap.org">openldap-bugs-bounces@openldap.or=
g</a> on behalf of <a
href=3D"mailto:quanah@zimbra.com">quanah@zimbra.com</=
a>&gt; wrote:<br>
<br>
&gt;--On Thursday, April 07, 2016 4:22 AM +0000 <a
href=3D"mailto:quanah@zi=
mbra.com">quanah@zimbra.com</a> wrote:<br>
&gt;<br>
&gt;&gt; So the change is still correctly replicated to the replicating
MMR=
 node.<br>
&gt;<br>
&gt;I see the same behavior with the example configuration that was provide=
d as<br>
&gt;we

Message of length 6529 truncated


Followup 15

Download message
Date: Thu, 7 Apr 2016 16:21:44 -0400 (EDT)
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: openldap-its@openldap.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
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)



Followup 16

Download message
Date: Thu, 07 Apr 2016 13:53:23 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank.Swasey@uvm.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Thursday, April 07, 2016 9:22 PM +0000 Frank.Swasey@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



Followup 17

Download message
Date: Thu, 07 Apr 2016 15:56:54 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank.Swasey@uvm.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Thursday, April 07, 2016 2:53 PM -0700 Quanah Gibson-Mount 
<quanah@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



Followup 18

Download message
Date: Thu, 07 Apr 2016 16:39:45 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: openldap-its@OpenLDAP.org, Frank.Swasey@uvm.edu
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Thursday, April 07, 2016 11:57 PM +0000 quanah@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



Followup 19

Download message
Date: Fri, 8 Apr 2016 10:17:44 -0400 (EDT)
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: quanah@zimbra.com
cc: openldap-its@openldap.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
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)



Followup 20

Download message
Date: Fri, 08 Apr 2016 08:03:13 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank Swasey <Frank.Swasey@uvm.edu>
cc: openldap-its@openldap.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Friday, April 08, 2016 11:17 AM -0400 Frank Swasey 
<Frank.Swasey@uvm.edu> wrote:

> 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?

Hi Frank,

I would continue with the documentation update noting that it is 
recommended to run the syncprov overlay on replicas, so that they manage 
their CSN status based off updated received, rather than syncprov 
broadcasts.  It's really the correct way to configure a replica, regardless 
of this bug. ;)

I definitely wouldn't revert anything related to ITS8281, given that it was 
fixing some serious issues, whereas this issue, while annoying, doesn't 
actually cause harm, and has a workaround that lines up with best practices 
anyway.

--Quanah

--

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



Followup 21

Download message
Date: Fri, 8 Apr 2016 12:12:03 -0400 (EDT)
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: quanah@zimbra.com
cc: openldap-its@openldap.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1729040092-1460131935=:96761
Content-Type: text/plain; format=flowed; charset=US-ASCII

Today at 11:03am, quanah@zimbra.com wrote:

> I would continue with the documentation update noting that it is
> recommended to run the syncprov overlay on replicas, so that they manage
> their CSN status based off updated received, rather than syncprov
> broadcasts.  It's really the correct way to configure a replica, regardless
> of this bug. ;)

Yeah -- so you keep saying ;)  ...  Patch attached.

> I definitely wouldn't revert anything related to ITS8281, given that it was
> fixing some serious issues, whereas this issue, while annoying, doesn't
> actually cause harm, and has a workaround that lines up with best practices
> anyway.

No, I was not saying that 8281 should be removed - just that I have 
built without the 8281 patch and the "problem" does not happen in that 
case.

Since I think we both agree that, strictly speaking, syncprov should not 
be required on a consumer only configuration; syncrepl probably needs to 
be updated to calculate the CSN if it is not present in the 
response (that's really all that is being added by having syncprov 
between syncrepl and the database - right?).  I'm not familiar with the 
code, so I don't know how difficult that would be.

-- 
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)
--0-1729040092-1460131935=:96761
Content-Type: text/plain; charset=US-ASCII; name=ITS8396.patch
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.OSX.2.20.1604081212030.96761@vc104198.hiz.rqh>
Content-Description: 
Content-Disposition: attachment; filename=ITS8396.patch

ZGlmZiAtcnUgYS9kb2MvZ3VpZGUvYWRtaW4vcmVwbGljYXRpb24uc2RmIGIv
ZG9jL2d1aWRlL2FkbWluL3JlcGxpY2F0aW9uLnNkZg0KLS0tIGEvZG9jL2d1
aWRlL2FkbWluL3JlcGxpY2F0aW9uLnNkZgkyMDE2LTAyLTA1IDE4OjU3OjQ1
LjAwMDAwMDAwMCAtMDUwMA0KKysrIGIvZG9jL2d1aWRlL2FkbWluL3JlcGxp
Y2F0aW9uLnNkZgkyMDE2LTA0LTA4IDEwOjE4OjU1LjA1MjcyOTUxMCAtMDQw
MA0KQEAgLTcwOCw2ICs3MDgsMTIgQEANCiANCiBINDogRGVsdGEtc3luY3Jl
cGwgQ29uc3VtZXIgY29uZmlndXJhdGlvbg0KIA0KKz4gICAgICMgU2V0IHRo
ZSBtb2R1bGUgcGF0aCBsb2NhdGlvbg0KKz4gICAgIG1vZHVsZXBhdGggL29w
dC9zeW1hcy9saWIvb3BlbmxkYXANCis+ICAgICANCis+ICAgICAjTG9hZCB0
aGUgc3luY3Byb3Ygb3ZlcmxheQ0KKz4gICAgIG1vZHVsZWxvYWQgc3luY3By
b3YubGENCis+ICAgICANCiA+ICAgICAjIFJlcGxpY2EgZGF0YWJhc2UgY29u
ZmlndXJhdGlvbg0KID4gICAgIGRhdGFiYXNlIGhkYg0KID4gICAgIHN1ZmZp
eCAiZGM9c3ltYXMsZGM9Y29tIg0KQEAgLTcxOSw2ICs3MjUsMTAgQEANCiA+
ICAgICAjIHN5bmNyZXBsIHNwZWNpZmljIGluZGljZXMNCiA+ICAgICBpbmRl
eCBlbnRyeVVVSUQgZXENCiA+ICAgICANCis+ICAgICAjIHN5bmNyZXBsIFBy
b3ZpZGVyIGZvciBwcmltYXJ5IGRiDQorPiAgICAgb3ZlcmxheSBzeW5jcHJv
dg0KKz4gICAgIHN5bmNwcm92LWNoZWNrcG9pbnQgMTAwMCA2MA0KKz4gICAg
IA0KID4gICAgICMgc3luY3JlcGwgZGlyZWN0aXZlcw0KID4gICAgIHN5bmNy
ZXBsICByaWQ9MA0KID4gICAgICAgICAgICAgICBwcm92aWRlcj1sZGFwOi8v
bGRhcG1hc3Rlci5zeW1hcy5jb206Mzg5DQpAQCAtNzQxLDcgKzc1MSw4IEBA
DQogaW4geW91ciBkYXRhYmFzZSB0aGF0IGNhbiBiZSB1c2VkIHRvIGJpbmQg
dG8gdGhlIHByb3ZpZGVyLiBJbiBhZGRpdGlvbiwgDQogYWxsIG9mIHRoZSBk
YXRhYmFzZXMgKHByaW1hcnksIHJlcGxpY2EsIGFuZCB0aGUgYWNjZXNzbG9n
IA0KIHN0b3JhZ2UgZGF0YWJhc2UpIHNob3VsZCBhbHNvIGhhdmUgcHJvcGVy
bHkgdHVuZWQge3tEQl9DT05GSUd9fSBmaWxlcyB0aGF0IG1lZXQgDQoteW91
ciBuZWVkcy4NCit5b3VyIG5lZWRzLiBUaGUgdXNlIG9mIHRoZSBzeW5jcHJv
diBvdmVybGF5IGluIHRoZSBjb25zdW1lciBjb25maWd1cmF0aW9uIGtlZXBz
DQordGhlIGNvbnN1bWVyJ3Mge3tFWDpjb250ZXh0Q1NOfX0gdXBkYXRlZC4N
CiANCiANCiBIMzogTi1XYXkgTXVsdGktTWFzdGVyDQpkaWZmIC1ydSBhL2Rv
Yy9tYW4vbWFuNS9zbGFwZC5jb25mLjUgYi9kb2MvbWFuL21hbjUvc2xhcGQu
Y29uZi41DQotLS0gYS9kb2MvbWFuL21hbjUvc2xhcGQuY29uZi41CTIwMTYt
MDItMDUgMTg6NTc6NDUuMDAwMDAwMDAwIC0wNTAwDQorKysgYi9kb2MvbWFu
L21hbjUvc2xhcGQuY29uZi41CTIwMTYtMDQtMDggMTA6MjA6MDMuOTgwMzIy
ODMyIC0wNDAwDQpAQCAtMTk3Miw2ICsxOTcyLDEzIEBADQogLkIgc3luY2Rh
dGENCiBwYXJhbWV0ZXIgaXMgb21pdHRlZCBvciBzZXQgdG8gImRlZmF1bHQi
IHRoZW4gdGhlIGxvZyBwYXJhbWV0ZXJzIGFyZQ0KIGlnbm9yZWQuDQorDQor
SXQgaXMgZ2VuZXJhbGx5IHJlY29tbWVuZGVkIHRvIHVzZSB0aGUgDQorLkIg
c3luY3Byb3YNCitvdmVybGF5IHdoZW4gY29uZmlndXJpbmcgYQ0KK1xmSWRl
bHRhIHN5bmNyZXBsXGZQDQorY29uc3VtZXIgdG8gZW5zdXJlIHRoYXQgdGhl
IGNvbnN1bWVyJ3MgY29udGV4dENTTiBzdGF5cyBzeW5jaHJvbml6ZWQgDQor
d2l0aCB0aGUgcHJvdmlkZXIuDQogLlJFDQogLlRQDQogLkIgdXBkYXRlZG4g
PGRuPg0K

--0-1729040092-1460131935=:96761--



Followup 22

Download message
Date: Fri, 08 Apr 2016 09:47:23 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank Swasey <Frank.Swasey@uvm.edu>
cc: openldap-its@openldap.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Friday, April 08, 2016 1:12 PM -0400 Frank Swasey 
<Frank.Swasey@uvm.edu> wrote:

> Today at 11:03am, quanah@zimbra.com wrote:
>
>> I would continue with the documentation update noting that it is
>> recommended to run the syncprov overlay on replicas, so that they
manage
>> their CSN status based off updated received, rather than syncprov
>> broadcasts.  It's really the correct way to configure a replica,
>> regardless of this bug. ;)
>
> Yeah -- so you keep saying ;)  ...  Patch attached.

Thanks!  As per <http://www.openldap.org/devel/contributing.html>, can you

regenerate the patch as a git formatted patch, so it is properly 
attributed?  Also we will need the IPR statement as noted in 
<http://www.openldap.org/devel/contributing.html#notice>


>> I definitely wouldn't revert anything related to ITS8281, given that it
>> was fixing some serious issues, whereas this issue, while annoying,
>> doesn't actually cause harm, and has a workaround that lines up with
>> best practices anyway.
>
> No, I was not saying that 8281 should be removed - just that I have built
> without the 8281 patch and the "problem" does not happen in that case.
>
> Since I think we both agree that, strictly speaking, syncprov should not
> be required on a consumer only configuration; syncrepl probably needs to
> be updated to calculate the CSN if it is not present in the response
> (that's really all that is being added by having syncprov between
> syncrepl and the database - right?).  I'm not familiar with the code, so
> I don't know how difficult that would be.

Right, Howard's aware of the issue and will be looking into what's 
necessary to fix it. ;)

--Quanah


--

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



Followup 23

Download message
Date: Fri, 8 Apr 2016 13:01:15 -0400 (EDT)
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: Quanah Gibson-Mount <quanah@zimbra.com>
cc: openldap-its@openldap.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-599314220-1460134885=:98440
Content-Type: text/plain; format=flowed; charset=US-ASCII

git format-patch version attached.

-- 
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)
--0-599314220-1460134885=:98440
Content-Type: text/plain; charset=US-ASCII;
name=0001-Documentation-change-for-ITS-8396.patch
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.OSX.2.20.1604081301150.98440@vc104198.hiz.rqh>
Content-Description: 
Content-Disposition: attachment;
filename=0001-Documentation-change-for-ITS-8396.patch

RnJvbSBiN2YzZDc4NmFkOTA0NGRiZTRkZTU0YmQ3MWU5NGQyOGFjODNmM2Zj
IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogRnJhbmNpcyBTd2Fz
ZXkgPEZyYW5rLlN3YXNleUB1dm0uZWR1Pg0KRGF0ZTogRnJpLCA4IEFwciAy
MDE2IDEyOjU2OjMyIC0wNDAwDQpTdWJqZWN0OiBbUEFUQ0hdIERvY3VtZW50
YXRpb24gY2hhbmdlIGZvciBJVFMjODM5Ng0KDQpJLCBGcmFuY2lzIEMuIFN3
YXNleSwgaGVyZWJ5IHBsYWNlIHRoZSBmb2xsb3dpbmcgbW9kaWZpY2F0aW9u
cyB0bw0KT3BlbkxEQVAgU29mdHdhcmUgKGFuZCBvbmx5IHRoZXNlIG1vZGlm
aWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYw0KZG9tYWluLiBIZW5jZSwgdGhl
c2UgbW9kaWZpY2F0aW9ucyBtYXkgYmUgZnJlZWx5IHVzZWQgYW5kL29yDQpy
ZWRpc3RyaWJ1dGVkIGZvciBhbnkgcHVycG9zZSB3aXRoIG9yIHdpdGhvdXQg
YXR0cmlidXRpb24gYW5kL29yDQpvdGhlciBub3RpY2UuDQotLS0NCiBkb2Mv
Z3VpZGUvYWRtaW4vcmVwbGljYXRpb24uc2RmIHwgMTMgKysrKysrKysrKysr
LQ0KIGRvYy9tYW4vbWFuNS9zbGFwZC5jb25mLjUgICAgICAgfCAgNyArKysr
KysrDQogMiBmaWxlcyBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAxIGRl
bGV0aW9uKC0pDQoNCmRpZmYgLS1naXQgYS9kb2MvZ3VpZGUvYWRtaW4vcmVw
bGljYXRpb24uc2RmIGIvZG9jL2d1aWRlL2FkbWluL3JlcGxpY2F0aW9uLnNk
Zg0KaW5kZXggMTE3NTQ5YS4uNDA0ZmVkYSAxMDA2NDQNCi0tLSBhL2RvYy9n
dWlkZS9hZG1pbi9yZXBsaWNhdGlvbi5zZGYNCisrKyBiL2RvYy9ndWlkZS9h
ZG1pbi9yZXBsaWNhdGlvbi5zZGYNCkBAIC03MDgsNiArNzA4LDEyIEBAIEZv
ciBtb3JlIGluZm9ybWF0aW9uLCBhbHdheXMgY29uc3VsdCB0aGUgcmVsZXZh
bnQgbWFuIHBhZ2VzICh7e3NsYXBvLWFjY2Vzc2xvZ319DQogDQogSDQ6IERl
bHRhLXN5bmNyZXBsIENvbnN1bWVyIGNvbmZpZ3VyYXRpb24NCiANCis+ICAg
ICAjIFNldCB0aGUgbW9kdWxlIHBhdGggbG9jYXRpb24NCis+ICAgICBtb2R1
bGVwYXRoIC9vcHQvc3ltYXMvbGliL29wZW5sZGFwDQorPiAgICAgDQorPiAg
ICAgI0xvYWQgdGhlIHN5bmNwcm92IG92ZXJsYXkNCis+ICAgICBtb2R1bGVs
b2FkIHN5bmNwcm92LmxhDQorPiAgICAgDQogPiAgICAgIyBSZXBsaWNhIGRh
dGFiYXNlIGNvbmZpZ3VyYXRpb24NCiA+ICAgICBkYXRhYmFzZSBoZGINCiA+
ICAgICBzdWZmaXggImRjPXN5bWFzLGRjPWNvbSINCkBAIC03MTksNiArNzI1
LDEwIEBAIEg0OiBEZWx0YS1zeW5jcmVwbCBDb25zdW1lciBjb25maWd1cmF0
aW9uDQogPiAgICAgIyBzeW5jcmVwbCBzcGVjaWZpYyBpbmRpY2VzDQogPiAg
ICAgaW5kZXggZW50cnlVVUlEIGVxDQogPiAgICAgDQorPiAgICAgIyBzeW5j
cmVwbCBQcm92aWRlciBmb3IgcHJpbWFyeSBkYg0KKz4gICAgIG92ZXJsYXkg
c3luY3Byb3YNCis+ICAgICBzeW5jcHJvdi1jaGVja3BvaW50IDEwMDAgNjAN
Cis+ICAgICANCiA+ICAgICAjIHN5bmNyZXBsIGRpcmVjdGl2ZXMNCiA+ICAg
ICBzeW5jcmVwbCAgcmlkPTANCiA+ICAgICAgICAgICAgICAgcHJvdmlkZXI9
bGRhcDovL2xkYXBtYXN0ZXIuc3ltYXMuY29tOjM4OQ0KQEAgLTc0MSw3ICs3
NTEsOCBAQCBUaGUgYWJvdmUgY29uZmlndXJhdGlvbiBhc3N1bWVzIHRoYXQg
eW91IGhhdmUgYSByZXBsaWNhdG9yIGlkZW50aXR5IGRlZmluZWQNCiBpbiB5
b3VyIGRhdGFiYXNlIHRoYXQgY2FuIGJlIHVzZWQgdG8gYmluZCB0byB0aGUg
cHJvdmlkZXIuIEluIGFkZGl0aW9uLCANCiBhbGwgb2YgdGhlIGRhdGFiYXNl
cyAocHJpbWFyeSwgcmVwbGljYSwgYW5kIHRoZSBhY2Nlc3Nsb2cgDQogc3Rv
cmFnZSBkYXRhYmFzZSkgc2hvdWxkIGFsc28gaGF2ZSBwcm9wZXJseSB0dW5l
ZCB7e0RCX0NPTkZJR319IGZpbGVzIHRoYXQgbWVldCANCi15b3VyIG5lZWRz
Lg0KK3lvdXIgbmVlZHMuIFRoZSB1c2Ugb2YgdGhlIHN5bmNwcm92IG92ZXJs
YXkgaW4gdGhlIGNvbnN1bWVyIGNvbmZpZ3VyYXRpb24ga2VlcHMNCit0aGUg
Y29uc3VtZXIncyB7e0VYOmNvbnRleHRDU059fSB1cGRhdGVkLg0KIA0KIA0K
IEgzOiBOLVdheSBNdWx0aS1NYXN0ZXINCmRpZmYgLS1naXQgYS9kb2MvbWFu
L21hbjUvc2xhcGQuY29uZi41IGIvZG9jL21hbi9tYW41L3NsYXBkLmNvbmYu
NQ0KaW5kZXggZWZlY2E5ZS4uOWRlYjViOCAxMDA2NDQNCi0tLSBhL2RvYy9t
YW4vbWFuNS9zbGFwZC5jb25mLjUNCisrKyBiL2RvYy9tYW4vbWFuNS9zbGFw
ZC5jb25mLjUNCkBAIC0xOTk5LDYgKzE5OTksMTMgQEAgVGhlDQogcGFyYW1l
dGVyIHRlbGxzIHRoZSB1bmRlcmx5aW5nIGRhdGFiYXNlIHRoYXQgaXQgY2Fu
IHN0b3JlIGNoYW5nZXMgd2l0aG91dA0KIHBlcmZvcm1pbmcgYSBmdWxsIGZs
dXNoIGFmdGVyIGVhY2ggY2hhbmdlLiBUaGlzIG1heSBpbXByb3ZlIHBlcmZv
cm1hbmNlDQogZm9yIHRoZSBjb25zdW1lciwgd2hpbGUgc2FjcmlmaWNpbmcg
c2FmZXR5IG9yIGR1cmFiaWxpdHkuDQorDQorSXQgaXMgZ2VuZXJhbGx5IHJl
Y29tbWVuZGVkIHRvIHVzZSB0aGUgDQorLkIgc3luY3Byb3YNCitvdmVybGF5
IHdoZW4gY29uZmlndXJpbmcgYQ0KK1xmSWRlbHRhIHN5bmNyZXBsXGZQDQor
Y29uc3VtZXIgdG8gZW5zdXJlIHRoYXQgdGhlIGNvbnN1bWVyJ3MgY29udGV4
dENTTiBzdGF5cyBzeW5jaHJvbml6ZWQgDQord2l0aCB0aGUgcHJvdmlkZXIu
DQogLlJFDQogLlRQDQogLkIgdXBkYXRlZG4gPGRuPg0KLS0gDQoyLjUuNCAo
QXBwbGUgR2l0LTYxKQ0KDQo=

--0-599314220-1460134885=:98440--



Followup 24

Download message
Date: Fri, 08 Apr 2016 10:17:48 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: Frank.Swasey@uvm.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Friday, April 08, 2016 6:02 PM +0000 Frank.Swasey@uvm.edu wrote:

>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware
> tools.
>
> --0-599314220-1460134885=:98440
> Content-Type: text/plain; format=flowed; charset=US-ASCII
>
> git format-patch version attached.

Perfect, thank you!

--Quanah


--

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



Followup 25

Download message
Date: Mon, 11 Sep 2017 09:35:58 -0700
From: Quanah Gibson-Mount <quanah@symas.com>
To: Frank.Swasey@uvm.edu, openldap-its@OpenLDAP.org
Subject: Re: (ITS#8396) syncprov hourly fails to answer syncrepl
--On Monday, April 04, 2016 7:57 PM +0000 Frank.Swasey@uvm.edu wrote:

> The bad log entries that coincide with check_syncrepl finding the replica
> has fallen behind are like:
>
> Apr  4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
> Apr  4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
> Apr  4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
> Apr  4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100
>
> They appear once an hour.

Hi Frank,

This looks like ITS#8444, which now has a fix checked into OpenLDAP master. 
You probably want to apply it to your deployment.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>



Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org