openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Friday, March 03, 2017 9:36 PM +0000 mberg(a)synacor.com wrote: > I'm not precisely sure how this relates to 8281, since that seemed to > be fixed by not generating an initial contextCSN for newly initialized > databases and telling consumers to smeg off if they tried to connect > before a contextCSN was written (presumably by a successful REFRESH in > a newly initialized MMR provider, or an initial write in a single- > master provider). See <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=cd8f…>, where the code was clearly modified to push the contextCSN's through where before they were not. The entire issue around ITS#8281 was REFRESH mode in MMR failing if the server was stopped and restarted midstream while doing the refresh, with the wrong CSN value being stored. The changes in ITS#8281 ensure it maintains the correct CSN value internally. Your context for points 1-3 are invalid as the entire issue was around N-way MMR (and their individual serverID contextCSNs) so non-master replicas are beside the point. In addition, a correct setup via the most recent tools would include replicas pulling from all masters, vs a single master. So there is no replica only pulling from an "active" or "passive" master in a correct setup. Replicas pull from *all* masters when deployed correctly. See also <https://bugzilla.zimbra.com/show_bug.cgi?id=95200> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 03 Mar '17

03 Mar '17

On Thu, 2017-03-02 at 16:49 -0800, Quanah Gibson-Mount wrote: > --On Thursday, March 02, 2017 10:36 PM +0000 mberg(a)synacor.com wrote: > > > I'm not sure if there is any guard against writing an older > > contextCSN > > than is currently stored, but this could theoretically rewind the > > stored contextCSN on A if there is any latency in replication from > > B. > > Older contextCSNs will be ignored. And it is accurate to then have > a contextCSN for each server in the system. That was part of the > initial problem in 8281. I still see no evidence of incorrect > behavior. ;) I'm well aware that there will be a contextCSN for each SID in the system. The questionable part was the apparent overwriting of the contextCSN on another server. I seem to be unable to reproduce that today, so I'm not sure if I fat-fingered something. However there would seem to be a couple possibilities here: 1) The contextCSN written as an accesslog entry is read by the other server and applied, which would be wrong since it should represent the most recent entryCSN seen for that SID, or 2) The contextCSN written as an accesslog entry is read by the other server and ignored, which would waste IOPS and increase latency, or 3) The contextCSN written as an accesslog entry has some non-obvious function, and replicas reading from the active master would be at a disadvantage since these entries are only being written on the passive master. I'm not precisely sure how this relates to 8281, since that seemed to be fixed by not generating an initial contextCSN for newly initialized databases and telling consumers to smeg off if they tried to connect before a contextCSN was written (presumably by a successful REFRESH in a newly initialized MMR provider, or an initial write in a single- master provider). This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

(ITS#8608) Inversion in filter pcacheTemplate cannot be parsed
by danmer＠danmer.net 03 Mar '17

03 Mar '17

Full_Name: Tabolin Yuriy Version: 2.4.43 OS: FreeBSD 10.1-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.126.18.58) I use openldap 2.4.43 with pcache overlay. Inversion assertions in pcacheTemplate filter cannot be parsed and slapd cannot start. For example this works fine: overlay pcache pcache mdb 100000 1 1000 60 pcacheAttrset 0 * pcacheTemplate (objectClass=) 0 3600 3600 But this not: overlay pcache pcache mdb 100000 1 1000 60 pcacheAttrset 0 * pcacheTemplate (!(objectClass=)) 0 3600 3600 There is written in man slapo-pcache "A template is defined by a filter string and an index identifying a set of attributes. The template string for a query can be obtained by removing assertion values from the RFC 4515 representation of its search filter." RFC4515 have defined exclamation mark ("!") as inversion in filter.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 02 Mar '17

02 Mar '17

--On Thursday, March 02, 2017 10:36 PM +0000 mberg(a)synacor.com wrote: > I'm not sure if there is any guard against writing an older contextCSN > than is currently stored, but this could theoretically rewind the > stored contextCSN on A if there is any latency in replication from B. Older contextCSNs will be ignored. And it is accurate to then have a contextCSN for each server in the system. That was part of the initial problem in 8281. I still see no evidence of incorrect behavior. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 02 Mar '17

02 Mar '17

Storing the update to the contextCSN to the root object makes sense, but propagating that update through the accesslog? Even if it were intended behavior, shouldn't the server receiving the update directly generate a similar access log entry, rather than just the server applying it from the accesslog. But practically speaking, the contextCSN on a given server should presumably reflect the most recent entryCSN that particular server has applied, and this would seem to break that. To illustrate I added a third contextCSN to my lab servers, with a stale CSN on ldap01-a: [zimbra@ldap01-a ~ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302203943.550330Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20160302175436.282737Z#000000#003#000000 [zimbra@ldap01-b ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302203943.550330Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20170302175436.282737Z#000000#003#000000 Wrote a new entry on ldap01-a (which is SID 001). The change propagated to ldap01-b, wrote an auditModify to the accesslog with its new contextCSNs: dn: reqStart=20170302214742.843377Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170302214742.843377Z reqEnd: 20170302214742.844297Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20170302214737.049475Z#000000#001#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#003#000000 reqEntryUUID: e1475404-93d7-1036-989f-315f78f5905f entryUUID: 9bceae9e-93dd-1036-8a51-85a9c542cb5f creatorsName: cn=config createTimestamp: 20170302214737Z entryCSN: 20170302214737.049475Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170302214737Z Which was subsequently read by ldap01-a: Mar 2 16:47:42 ldap01-a slapd[9577]: syncprov_search_response: cookie=rid=100,sid=001,csn=20170302214737.049475Z#000000#001#000000 And now it has an updated contextCSN for 003 despite receiving no update for that SID: [zimbra@ldap01-a ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302214737.049475Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20170302175436.282737Z#000000#003#000000 I'm not sure if there is any guard against writing an older contextCSN than is currently stored, but this could theoretically rewind the stored contextCSN on A if there is any latency in replication from B. This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 02 Mar '17

02 Mar '17

--On Thursday, March 02, 2017 6:46 PM +0000 mberg(a)synacor.com wrote: > In order to rule out the possibility that this was introduced by any > patched Zimbra applied I built out a new package from stock OpenLDAP > sources and was able to reproduce with both 2.4.44 and 2.4.43, but not > with 2.4.42 and earlier. Hi Matt, I don't see any indication of a bug here. Zimbra uses "" (empty DN) as its root, which shares other responsibilities with the overal DIT. So it's simply logging an update of the contextCSN to its root entry. This change in behavior was made to resolve the issue I reported in ITS#8281. Closing this report. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 02 Mar '17

02 Mar '17

Full_Name: Matthew Berg Version: 2.4.43+ OS: CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.97.88.240) While debugging replication issues in a Zimbra installation, I discovered a significant number of accesslog entries with an empty reqDN and specifying values for contextCSN; e.g. dn: reqStart=20170302180943.186147Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170302180943.186147Z reqEnd: 20170302180943.190880Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20170227211132.933390Z#000000#000#000000 reqMod: contextCSN:= 20170302180943.182601Z#000000#001#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000 entryUUID: 27b9f34c-93bf-1036-9636-3fa0e78444ec creatorsName: cn=config createTimestamp: 20170302180943Z entryCSN: 20170302180943.182601Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170302180943Z I was able to reproduce this behavior in a test lab with two freshly installed servers and no existing data. Given two servers, A and B, a write to A will result in the expected audit object being written to the access log on A, but when B applies the change it logs an additional auditModify (likewise B will cause the same additional entry on A). This particular environment was running a patched build of 2.4.44. I audited our other production environments and did not see the same behavior with prior builds (primarily 2.4.39). In order to rule out the possibility that this was introduced by any patched Zimbra applied I built out a new package from stock OpenLDAP sources and was able to reproduce with both 2.4.44 and 2.4.43, but not with 2.4.42 and earlier.

1 0

(ITS#8606) Document the keepalive parameter in the admin guide
by quanah＠openldap.org 02 Mar '17

02 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The keepalive parameter to syncrepl was added after the current replication documents were written, and needs to be added to the admin guide.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by quanah＠symas.com 28 Feb '17

28 Feb '17

--On Tuesday, February 14, 2017 3:16 AM +0000 ryan(a)nardis.ca wrote: > I found that useful in a setup very similar to what Andreas and Michael > describe: slapd with a server certificate issued by an external/public > CA, but trusting only a specific internal CA to authenticate clients. I found this to be a very common scenario while working for Zimbra. Many of the clients had a commercial sever cert but used their own CA for internal client cert auth. It would be extremely helpful for OpenLDAP to better support these types of configurations. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8605) spelling
by quanah＠symas.com 28 Feb '17

28 Feb '17

--On Sunday, February 26, 2017 8:20 AM +0000 jsoref(a)gmail.com wrote: > Full_Name: Josh Soref > Version: master > OS: > URL: > https://github.com/openldap/openldap/compare/master...jsoref:spelling?exp > and=1 Submission from: (NULL) (135.23.187.91) > > > This is a proposal of 144 changes. They should each be individually > applicable (although some may require earlier changes if they happen to > touch similar lines). > > Please don't expect me to submit 144 individual change requests, that > isn't reasonable. I am generally willing to provide 3-10 submissions, > preferably on the lower side. All you have to do is specify what you want > in them. Hi Josh, These look good, and I think it can be done as a single git-format-patch submission uploaded to the FTP server. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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