openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8401) mdb_env_stat crashes if env is not open
by hyc＠symas.com 13 Apr '16

13 Apr '16

gahr(a)gahr.ch wrote: > Full_Name: Pietro Cerutti > Version: lmdb 0.9.18 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.191.176.32) > > > mdb_env_stat crashes is the env was created but not opened. This happens because > mdb_env_stat calls mdb_env_pick_meta, which doesn't check whether the two pages > are NULL before dereferencing them. > > Please note that there is no mention of the fact that the env must have been > opened before calling mdb_env_stat in the documentation [1]. You're not reading carefully. http://symas.com/mdb/doc/group__mdb.html#gaad6be3d8dcd4ea01f8df436f41d158d4 "Before the handle may be used, it must be opened using mdb_env_open()." Closing this ITS. -- -- 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

(ITS#8401) mdb_env_stat crashes if env is not open
by gahr＠gahr.ch 13 Apr '16

13 Apr '16

Full_Name: Pietro Cerutti Version: lmdb 0.9.18 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.191.176.32) mdb_env_stat crashes is the env was created but not opened. This happens because mdb_env_stat calls mdb_env_pick_meta, which doesn't check whether the two pages are NULL before dereferencing them. Please note that there is no mention of the fact that the env must have been opened before calling mdb_env_stat in the documentation [1]. The proposed patch is to check whether the environment is active before getting the most recent page: --- mdb.c.orig 2016-04-13 10:00:30.084676000 +0000 +"B2B mdb.c 2016-04-13 10:07:32.064085000 +0000 @@ -9432,7 +9432,7 @@ { MDB_meta *meta; - if (env == NULL || arg == NULL) + if (env == NULL || !(env->me_flags & MDB_ENV_ACTIVE) || arg == NULL) return EINVAL; meta = mdb_env_pick_meta(env); [1] http://symas.com/mdb/doc/group__mdb.html#gaf881dca452050efbd434cd16e4bae255

1 0

Re: (ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by dsullivan2＠bsd.uchicago.edu 12 Apr '16

12 Apr '16

VGhhbmsgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmVwbHkgdG8gbWUgKEkgYXNzdW1lIHlv dSBhcmUgdmVyeSBidXN5KS4gIEkgYXBvbG9naXplIGZvciB0aGlzLCBJIHdvdWxkbuKAmXQgcmVw b3J0IHRoaXMgYXMgYSBidWcgdW5sZXNzIEkgdGhvdWdodCBpdCByZWFsbHkgd2FzLg0KDQpEYW4g U3VsbGl2YW4NCg0KPiBPbiBBcHIgMTEsIDIwMTYsIGF0IDc6MTIgUE0sIEhvd2FyZCBDaHUgPGh5 Y0BzeW1hcy5jb20+IHdyb3RlOg0KPiANCj4gZHN1bGxpdmFuMkBic2QudWNoaWNhZ28uZWR1IHdy b3RlOg0KPj4gRnVsbF9OYW1lOiBEYW4gU3VsbGl2YW4NCj4+IFZlcnNpb246ICAyLjQuNDAtNy5l bDZfNw0KPj4gT1M6IFJIRUwNCj4+IFVSTDogZnRwOi8vZnRwLm9wZW5sZGFwLm9yZy9pbmNvbWlu Zy8NCj4+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICgyMDUuMjA4LjEyMi4yMzApDQo+PiANCj4+ IA0KPj4gSGksDQo+PiANCj4+IEkgYW0gcmVwb3J0aW5nIHdoYXQgSSBiZWxpZXZlIHRvIGJlIGEg YnVnIGluIHRoZSB0cmFuc2x1Y2VudCBvdmVybGF5IHByb3h5LiAgSXQNCj4+IGFwcGVhcnMgdGhh dCB0d28gY29udGlndW91cyBub24tZXNjYXBlZCBzcGFjZXMgaW4gdGhlIG1pZGRsZSBvZiBhIERO IHdpbGwgZ2V0DQo+PiBzZW50IHRvIHRoZSByZW1vdGUgc2VydmVyIGFzIGEgc2luZ2xlIHNwYWNl LiAgRm9yIGV4YW1wbGUsIGlmIEkgaGF2ZSB0aGUNCj4+IGZvbGxvd2luZyByZWNvcmQgYmVpbmcg ZHVtcGVkIGZyb20gdGhlIGxvY2FsIGRhdGFiYXNlIHVzaW5nIHNsYXBjYXQ6DQo+IA0KPiBUaGlz IGlzIG5vdCBhIGJ1Zy4gQXMgc3BlY2lmaWVkIGluIFguNTIwLCBtdWx0aXBsZSBjb25zZWN1dGl2 ZSBzcGFjZXMgYXJlIGluc2lnbmlmaWNhbnQuDQo+IA0KPiBDbG9zaW5nIHRoaXMgSVRTLg0KPiAN Cj4+IA0KPj4gZG46IGNuPWZvb1wyQyBiYXIgIFtCU0RdIC0gSEdELG91PWdlbmVyYWwNCj4+IGFj Y291bnRzLG91PWFjY291bnRzLG91PWhnZCxkYz1zb21lZG9tYWluLGRjPXVjaGljYWdvLGRjPWVk dQ0KPj4gZ2lkTnVtYmVyOiAzMzk3OTI5MjINCj4+IHVpZE51bWJlcjozOTM5Nzk4NTE2DQo+PiBo b21lRGlyZWN0b3J5OiAvaG9tZS9mYmFyDQo+PiBzQU1BY2NvdW50TmFtZTogZmJhcg0KPj4gb2Jq ZWN0Q2xhc3M6IHBlcnNvbg0KPj4gDQo+PiBUaGVyZSBhcmUgdHdvIHNwYWNlcyBiZXR3ZWVuIGJh ciBhbmQgW0JTRF0uICBJZiBJIHF1ZXJ5IExEQVAgZm9yIHVpZE51bWJlciAodmlhDQo+PiB0cmFu c2x1Y2VudCBsb2NhbCksIHRoZSBzZWFyY2ggRE4gdGhhdCBpcyBwYXNzZWQgdG8gdGhlIHJlbW90 ZSBzZXJ2ZXIgb25seSBoYXMNCj4+IG9uZSBzcGFjZSBpbiBpdC4gIEJhc2VkIG9uIG15IHVuZGVy c3RhbmRpbmcgaXQgaXMgYWNjZXB0YWJsZSB0byBoYXZlIGFueSBudW1iZXINCj4+IG9mIHNwYWNl cyBpbiBhIEROIHdpdGhvdXQgZXNjYXBpbmcgdGhlbSAoYXMgbG9uZyBhcyB0aGV5IGFyZSBub3Qg dGhlIGZpcnN0IG9yDQo+PiB0aGUgbGFzdCBjaGFyYWN0ZXJzIGluIHRoZSBmaWVsZCkuICBJIHZl cmlmaWVkIHRoYXQgb25seSBhIHNpbmdsZSBzcGFjZSBpcyBiZWluZw0KPj4gc2VudCB0byB0aGUg cmVtb3RlIHNlcnZlciBieSBkb2luZyBhIHBhY2tldCBjYXB0dXJlIGFuZCBsb29raW5nIGF0IHRo ZSBhY3R1YWwNCj4+IExEQVAgcXVlcnkgYmVpbmcgc2VudC4NCj4+IA0KPj4gSWYgaXQgd291bGQg aGVscCB0byBwcm92aWRlIGNvbmZpZ3VyYXRpb24sIGFkZGl0aW9uYWwgbG9ncywgb3IgYSBwYWNr ZXQgY2FwdHVyZQ0KPj4gcGxlYXNlIGFkdmlzZSBhbmQgSSBjYW4gcHJvdmlkZSB0aGlzLg0KPj4g DQo+PiBJIGJlbGlldmUgbXkgb3ZlcmxheSBwcm94eSB3b3JrcyBmaW5lIG90aGVyd2lzZS4NCj4+ IA0KPj4gRGFuDQo+PiANCj4+IA0KPiANCj4gDQo+IC0tIA0KPiAgLS0gSG93YXJkIENodQ0KPiAg Q1RPLCBTeW1hcyBDb3JwLiAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NCj4gIERpcmVj dG9yLCBIaWdobGFuZCBTdW4gICAgIGh0dHA6Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KPiAgQ2hp ZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8N Cg0KCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMgZS1tYWlsIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoCml0IGlzIGFk ZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwuCklmIHRoZSByZWFkZXIgb2YgdGhpcyBlLW1haWwgbWVzc2FnZSBpcyBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSAKaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMKY29tbXVu aWNhdGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBp biBlcnJvciwgcGxlYXNlIApub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSB0cmFuc21pdHRhbC4gCgpUaGFuayB5b3UKVW5pdmVyc2l0eSBvZiBDaGljYWdvIE1l ZGljaW5lIGFuZCBCaW9sb2dpY2FsIFNjaWVuY2VzIAoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=

1 0

Re: (ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by hyc＠symas.com 11 Apr '16

11 Apr '16

dsullivan2(a)bsd.uchicago.edu wrote: > Full_Name: Dan Sullivan > Version: 2.4.40-7.el6_7 > OS: RHEL > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.208.122.230) > > > Hi, > > I am reporting what I believe to be a bug in the translucent overlay proxy. It > appears that two contiguous non-escaped spaces in the middle of a DN will get > sent to the remote server as a single space. For example, if I have the > following record being dumped from the local database using slapcat: This is not a bug. As specified in X.520, multiple consecutive spaces are insignificant. Closing this ITS. > > dn: cn=foo\2C bar [BSD] - HGD,ou=general > accounts,ou=accounts,ou=hgd,dc=somedomain,dc=uchicago,dc=edu > gidNumber: 339792922 > uidNumber:3939798516 > homeDirectory: /home/fbar > sAMAccountName: fbar > objectClass: person > > There are two spaces between bar and [BSD]. If I query LDAP for uidNumber (via > translucent local), the search DN that is passed to the remote server only has > one space in it. Based on my understanding it is acceptable to have any number > of spaces in a DN without escaping them (as long as they are not the first or > the last characters in the field). I verified that only a single space is being > sent to the remote server by doing a packet capture and looking at the actual > LDAP query being sent. > > If it would help to provide configuration, additional logs, or a packet capture > please advise and I can provide this. > > I believe my overlay proxy works fine otherwise. > > Dan > > -- -- 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

(ITS#8400) contiguous spaces in middle of DN - translucent overlay proxy
by dsullivan2＠bsd.uchicago.edu 11 Apr '16

11 Apr '16

Full_Name: Dan Sullivan Version: 2.4.40-7.el6_7 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.208.122.230) Hi, I am reporting what I believe to be a bug in the translucent overlay proxy. It appears that two contiguous non-escaped spaces in the middle of a DN will get sent to the remote server as a single space. For example, if I have the following record being dumped from the local database using slapcat: dn: cn=foo\2C bar [BSD] - HGD,ou=general accounts,ou=accounts,ou=hgd,dc=somedomain,dc=uchicago,dc=edu gidNumber: 339792922 uidNumber:3939798516 homeDirectory: /home/fbar sAMAccountName: fbar objectClass: person There are two spaces between bar and [BSD]. If I query LDAP for uidNumber (via translucent local), the search DN that is passed to the remote server only has one space in it. Based on my understanding it is acceptable to have any number of spaces in a DN without escaping them (as long as they are not the first or the last characters in the field). I verified that only a single space is being sent to the remote server by doing a packet capture and looking at the actual LDAP query being sent. If it would help to provide configuration, additional logs, or a packet capture please advise and I can provide this. I believe my overlay proxy works fine otherwise. Dan

1 0

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

08 Apr '16

--On Friday, April 08, 2016 6:02 PM +0000 Frank.Swasey(a)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

1 0

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

08 Apr '16

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(a)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--

1 0

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

08 Apr '16

--On Friday, April 08, 2016 1:12 PM -0400 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > Today at 11:03am, quanah(a)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

1 0

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

08 Apr '16

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(a)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(a)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--

1 0

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

08 Apr '16

--On Friday, April 08, 2016 11:17 AM -0400 Frank Swasey <Frank.Swasey(a)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

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