openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(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

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

08 Apr '16

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

1 0

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

08 Apr '16

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

1 0

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

08 Apr '16

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

1 0

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

07 Apr '16

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

1 0

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