Full_Name: Francis Swasey Version: 2.4.22 OS: Red Hat Enterprise Linux 5 update 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.107.64) Platform: Red Hat Enterprise Linux 5, update 5, 64-bit OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. The following modify ldif successfully applies to the master: dn: uid=fcswasey,ou=People,dc=uvm,dc=edu changetype: modify replace: sn sn: Swasey - replace: sn sn: Swasey - In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" attribute is presented twice. In OpenLDAP 2.4 -- it works, but the delta-syncrepl replica pukes on it with this error: syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more than once)
changed notes
--On Wednesday, May 05, 2010 5:37 PM +0000 Frank.Swasey@uvm.edu wrote: > Full_Name: Francis Swasey > Version: 2.4.22 > OS: Red Hat Enterprise Linux 5 update 5 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.107.64) > > > Platform: Red Hat Enterprise Linux 5, update 5, 64-bit > OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. > > The following modify ldif successfully applies to the master: > > dn: uid=fcswasey,ou=People,dc=uvm,dc=edu > changetype: modify > replace: sn > sn: Swasey > - > replace: sn > sn: Swasey > - > > syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more > than once) Can you please show the contents of the accesslog databsae for this change? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On 5/6/10 3:18 PM, Quanah Gibson-Mount wrote: > Can you please show the contents of the accesslog databsae for this > change? dn: reqStart=20100506114012.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20100506114012.000002Z reqEnd: 20100506114012.000003Z reqType: modify reqSession: 1006 reqAuthzID: cn=manager,dc=uvm,dc=edu reqDN: uid=fcswasey,ou=People,dc=uvm,dc=edu reqResult: 0 reqMod: sn:= Swasey reqMod: sn:= Swasey reqMod: entryCSN:= 20100506114012.200297Z#000000#000#000000 reqMod: modifiersName:= cn=manager,dc=uvm,dc=edu reqMod: modifyTimestamp:= 20100506114012Z entryUUID: 7ba18504-6f3b-450a-8420-a101ba6b76c5 creatorsName: cn=accesslog createTimestamp: 20100506114012Z entryCSN: 20100506114012.200297Z#000000#000#000000 modifiersName: cn=accesslog modifyTimestamp: 20100506114012Z entryDN: reqStart=20100506114012.000002Z,cn=accesslog subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- 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)
I see someone has tagged this as unreproducable in head/re24. Ok.... Are you saying that 2.4.23 will not have this bug or that I did something wrong in compiling 2.4.22???? -- 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)
--On May 12, 2010 1:06:53 PM +0000 Frank.Swasey@uvm.edu wrote: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig666A26622E67D44DE6AFFA9C > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > I see someone has tagged this as unreproducable in head/re24.=20 > > Ok.... Are you saying that 2.4.23 will not have this bug or that I did > something wrong in compiling 2.4.22???? Pierangelo made that note, but failed to follow up with the ITS in any way. Maybe he will be willing to provide more information, since RE24 and 2.4.22 are identical. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
I checked with HEAD and re24 (basically, 2.4.22 from CVS) and I couldn't reproduce the issue. Can you provide the configuration and an example LDIF that triggers the issue? I simply ran test043, restart both servers, and perform a modification similar to yours, and it went through with no problems. p. > Full_Name: Francis Swasey > Version: 2.4.22 > OS: Red Hat Enterprise Linux 5 update 5 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.107.64) > > > Platform: Red Hat Enterprise Linux 5, update 5, 64-bit > OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. > > The following modify ldif successfully applies to the master: > > dn: uid=fcswasey,ou=People,dc=uvm,dc=edu > changetype: modify > replace: sn > sn: Swasey > - > replace: sn > sn: Swasey > - > > In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" > attribute is presented twice. In OpenLDAP 2.4 -- it works, but the > delta-syncrepl replica pukes on it with this error: > > syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more > than once) > > >
Yes, I'll have to do some work to set that up -- I'll get back to you. Frank On 5/13/10 8:44 PM, masarati@aero.polimi.it wrote: > I checked with HEAD and re24 (basically, 2.4.22 from CVS) and I couldn't > reproduce the issue. Can you provide the configuration and an example > LDIF that triggers the issue? I simply ran test043, restart both servers, > and perform a modification similar to yours, and it went through with no > problems. > > p. > > >> Full_Name: Francis Swasey >> Version: 2.4.22 >> OS: Red Hat Enterprise Linux 5 update 5 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (132.198.107.64) >> >> >> Platform: Red Hat Enterprise Linux 5, update 5, 64-bit >> OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. >> >> The following modify ldif successfully applies to the master: >> >> dn: uid=fcswasey,ou=People,dc=uvm,dc=edu >> changetype: modify >> replace: sn >> sn: Swasey >> - >> replace: sn >> sn: Swasey >> - >> >> In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" >> attribute is presented twice. In OpenLDAP 2.4 -- it works, but the >> delta-syncrepl replica pukes on it with this error: >> >> syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more >> than once) >> >> >> >> > -- 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)
changed notes changed state Open to Feedback
Hi Frank, Do you still encounter this issue with current OpenLDAP builds? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
changed notes moved from Incoming to Software Bugs
Yes. It still happens. On 3/27/17, 20:19, "Quanah Gibson-Mount" <quanah@symas.com> wrote: Hi Frank, Do you still encounter this issue with current OpenLDAP builds? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
The attached patch updates the testsuite to reproduce the issue: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170404-ITS-6545-testcase.patch The issue is that there is information lost when creating the log entry: - the ordering of values is not guaranteed by LDAP, even though this is rarely an issue with OpenLDAP with main backends (unless some overlay interferes) - there is no way to record where one modification ends and another begins The obvious way to fix this is to record that a modification has ended. This is technically a change to the accesslog format but delta syncrepl will recover by falling back to plain syncrepl (which it already does in the reported case). We could also record the order modifications as well (implementing the X-ORDERED trait on the attribute), but that would break most consumers of this format. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Thanks for the patch to provide a test script that just shows the same thing. I see two possible solutions: 1) replacing the same attribute twice in the same modify LDIF is illegal (as it was in older releases) 2) the accesslog/syncrepl needs to record the final result, not every bit of the change. I believe the easiest solution is #1. However, #2 would be proper if this kind of abuse is legal. Consider the following deck: dn: cn=Oh Noes,ou=People,dc=example,dc=com changetype: modify delete: sn sn: George - add: sn sn: Thomas - delete: sn sn: Thomas - add: sn sn: George - Is that legal? Well, it works and results in an entry in the accesslog that contains: reqMod: sn:- George reqMod: sn:+ Thomas reqMod: sn:- Thomas reqMod: sn:+ George and has no issues in the replication. Therefore, why does this deck: dn: cn=Oh Noes,ou=People,dc=example,dc=com changetype: modify replace: sn sn: Thomas - replace: sn sn: George - which creates an accesslog entry that contains: reqMod: sn:= Thomas reqMod: sn:= George Interestingly, this morning when I was performing this, the replica ate that accesslog entry and put both of those sn's into the LDAP entry on the replica (instead of the normal barking in the logs that it failed). Perhaps because I had done the former test with the delete/add/delete/add sequence? At this point, I'm thinking the accesslog should probably generate the minimal changes necessary to get to the right state. That would mean the former test should produce: reqMod: sn:- George reqMod: sn:+ George and the latter: reqMod:sn:= George Either that, or the syncrepl processing of what accesslog is sending needs some serious investigation. I'll see what I can find for time to look into that serious investigation. - Frank On Tue, 4 Apr 2017 at 1:54pm, Ondřej Kuzník wrote: > The attached patch updates the testsuite to reproduce the issue: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170404-ITS-6545-testcase.patch > > The issue is that there is information lost when creating the log entry: > - the ordering of values is not guaranteed by LDAP, even though this is > rarely an issue with OpenLDAP with main backends (unless some overlay > interferes) > - there is no way to record where one modification ends and another > begins > > The obvious way to fix this is to record that a modification has ended. > This is technically a change to the accesslog format but delta syncrepl > will recover by falling back to plain syncrepl (which it already does in > the reported case). > > We could also record the order modifications as well (implementing the > X-ORDERED trait on the attribute), but that would break most consumers > of this format. > > -- 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)
On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: > Thanks for the patch to provide a test script that just shows the same > thing. > > I see two possible solutions: > > 1) replacing the same attribute twice in the same modify LDIF is illegal > (as it was in older releases) AFAIK, LDAP doesn't forbid it so I don't see that going away. > 2) the accesslog/syncrepl needs to record the final result, not every bit > of the change. Two problems: - the log is meant to record the request for review/statistics purposes as well and should record the intent, not just the result - the modification might fail, in that case you still need an accurate record of the request > I believe the easiest solution is #1. However, #2 would be proper if this > kind of abuse is legal. > > Consider the following deck: > > [...] > > Is that legal? Well, it works and results in an entry in the accesslog that > contains: > > [...] > > and has no issues in the replication. > > Therefore, why does this deck: > > dn: cn=Oh Noes,ou=People,dc=example,dc=com > changetype: modify > replace: sn > sn: Thomas > - > replace: sn > sn: George > - > > which creates an accesslog entry that contains: > > reqMod: sn:= Thomas > reqMod: sn:= George > > Interestingly, this morning when I was performing this, the replica ate that > accesslog entry and put both of those sn's into the LDAP entry on the > replica (instead of the normal barking in the logs that it failed). Perhaps > because I had done the former test with the delete/add/delete/add sequence? Your original example did two replacements with the same value, the test case runs two replacements with different values as that will cause the two servers to de-sync silently. > At this point, I'm thinking the accesslog should probably generate the > minimal changes necessary to get to the right state. That would mean the > former test should produce: > > reqMod: sn:- George > reqMod: sn:+ George > > and the latter: > > reqMod:sn:= George > > Either that, or the syncrepl processing of what accesslog is sending needs > some serious investigation. I'll see what I can find for time to look into > that serious investigation. It does need a fair bit of attention, the problem is it's something that would require a format change and there are already existing consumers that would be affected. I'm going to try with a patch to record something like this: regMod: sn:= George regMod: : regMod: sn:= George Together with the relevant syncrepl updates. While consumers would still be affected, this should be quite rare and the current handling of that case would have been incorrect anyway. The change would then only make the silent failure a noisy one. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
ondra@mistotebe.net wrote: > On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >> Thanks for the patch to provide a test script that just shows the same >> thing. >> >> I see two possible solutions: >> >> 1) replacing the same attribute twice in the same modify LDIF is illegal >> (as it was in older releases) > > AFAIK, LDAP doesn't forbid it so I don't see that going away. Yes, there's no text in RFC 4511 which forbids this: https://tools.ietf.org/html/rfc4511#section-4.6 However personally I consider LDAP clients sending modify requests like this to be broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) => There could be a slapd per-backend configuation directive to disallow it with a strong hint in the docs recommending to disallow it when using delta-syncrepl. Suggestion: disallow mod_attr_repeated >> 2) the accesslog/syncrepl needs to record the final result, not every bit >> of the change. > > Two problems: > - the log is meant to record the request for review/statistics purposes > as well and should record the intent, not just the result > - the modification might fail, in that case you still need an accurate > record of the request IIRC slapo-accesslog was primarily implemented for delta-syncrepl. Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-) But still I'd consider an optimized changes list written to accesslog to be perfectly fine for security auditing because it would represent what caused the modification of the database content. Also note that not every failed modification is written to accesslog-DB anyway because most malformed write operations already fail in slapd's front-end (schema check etc.) and never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is something for which you have to use Wireshark etc. in most cases anyway. I'm not familiar with the inner workings of slapd but these things should be carefully considered when optimizing the changes list of a modify request: 1. constraint checking (slapo-unique and slapo-constraint) 2. impact on indexing 3. access control, especially with val=foo part in the ACL 1. and 2. are hopefully already done on the "resulting entry after the entire list of modifications is performed" (RFC 4511). Ciao, Michael.
On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Ströder wrote: > ondra@mistotebe.net wrote: >> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >>> Thanks for the patch to provide a test script that just shows the same >>> thing. >>> >>> I see two possible solutions: >>> >>> 1) replacing the same attribute twice in the same modify LDIF is illegal >>> (as it was in older releases) >> >> AFAIK, LDAP doesn't forbid it so I don't see that going away. > > Yes, there's no text in RFC 4511 which forbids this: > https://tools.ietf.org/html/rfc4511#section-4.6 > > However personally I consider LDAP clients sending modify requests like this to be > broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) I'm not saying it's common or good practice ;) > => There could be a slapd per-backend configuation directive to disallow it with a strong > hint in the docs recommending to disallow it when using delta-syncrepl. > > Suggestion: > disallow mod_attr_repeated In my view, that's more pain than it's worth. >>> 2) the accesslog/syncrepl needs to record the final result, not every bit >>> of the change. >> >> Two problems: >> - the log is meant to record the request for review/statistics purposes >> as well and should record the intent, not just the result >> - the modification might fail, in that case you still need an accurate >> record of the request > > IIRC slapo-accesslog was primarily implemented for delta-syncrepl. > > Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-) > But still I'd consider an optimized changes list written to accesslog to be perfectly > fine for security auditing because it would represent what caused the modification of the > database content. I don't think it matters what it was written for, the fact that it's officially useful for that as you and others have realised means they might object to us making drastic changes in 2.4, a series the project have tried to freeze even maintenance for. > Also note that not every failed modification is written to accesslog-DB anyway because > most malformed write operations already fail in slapd's front-end (schema check etc.) and > never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is > something for which you have to use Wireshark etc. in most cases anyway. I think most of the ones that don't reach accesslog get a protocol error or come from anonymous connections, schema checking and ACL should happen later. > I'm not familiar with the inner workings of slapd but these things should be carefully > considered when optimizing the changes list of a modify request: > 1. constraint checking (slapo-unique and slapo-constraint) > 2. impact on indexing > 3. access control, especially with val=foo part in the ACL > > 1. and 2. are hopefully already done on the "resulting entry after the entire list of > modifications is performed" (RFC 4511). Not sure I follow. On the consumer, syncrepl bypasses all ACLs and the overlays you mention should already be capable of passing the operation intact. On the provider side it depends on the overlay order and the administrator has the option to decide that if they wish. Consistency and data model are generally maintained quite alright. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Wed, 5 Apr 2017 at 10:14am, michael@stroeder.com wrote: > However personally I consider LDAP clients sending modify requests like this to be > broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) My original report was from 2010 - I presume it was something that the perl code (using Net::LDAP module) that I had written at the time tripped onto [or it was some awful edgecase test that I had devised]. To the best of my knowledge, this was not something that I had a client doing to the LDAP servers from the wild. -- 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)
On Wed, 5 Apr 2017 at 8:18am, ondra@mistotebe.net wrote: > AFAIK, LDAP doesn't forbid it so I don't see that going away. Well, then that means that the current behavior is a bug in either the syncrepl implementation or the accesslog recording. Since the MASTER gets updated correctly and the REPLICAs (and other MMR members) all fall down when attempting to process the accesslog entry. > It does need a fair bit of attention, the problem is it's something that > would require a format change and there are already existing consumers > that would be affected. > > I'm going to try with a patch to record something like this: > regMod: sn:= George > regMod: : > regMod: sn:= George > > Together with the relevant syncrepl updates. > > While consumers would still be affected, this should be quite rare and > the current handling of that case would have been incorrect anyway. The > change would then only make the silent failure a noisy one. Noisy in that the replica/mmr falls over dead or just logs more stuff? To be honest, my goal is consistency. I want the replicas (and MMR mates) to all wind up with the same values the master has. -- 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)
ondra@mistotebe.net wrote: > On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael StrĂśder wrote: >> ondra@mistotebe.net wrote: >>> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >>>> Thanks for the patch to provide a test script that just shows the same >>>> thing. >>>> >>>> I see two possible solutions: >>>> >>>> 1) replacing the same attribute twice in the same modify LDIF is illegal >>>> (as it was in older releases) >>> >>> AFAIK, LDAP doesn't forbid it so I don't see that going away. >> >> Yes, there's no text in RFC 4511 which forbids this: >> https://tools.ietf.org/html/rfc4511#section-4.6 >> >> However personally I consider LDAP clients sending modify requests like this to be >> broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) > > I'm not saying it's common or good practice ;) > >> => There could be a slapd per-backend configuation directive to disallow it with a >> strong hint in the docs recommending to disallow it when using delta-syncrepl. >> >> Suggestion: >> disallow mod_attr_repeated > > In my view, that's more pain than it's worth. Hmm, I think slapd should be able to disallow a crazy modify request like this: dn: cn=foobar,dc=example,dc=com changetype: modify replace: description description: foobar1 - replace: description description: foobar2 - .. replace: description description: foobar1000 - Ciao, Michael.
On Thu, Apr 06, 2017 at 05:14:15PM +0200, Michael Ströder wrote: > ondra@mistotebe.net wrote: >> On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael StrĂśder wrote: >>> => There could be a slapd per-backend configuation directive to disallow it with a >>> strong hint in the docs recommending to disallow it when using delta-syncrepl. >>> >>> Suggestion: >>> disallow mod_attr_repeated >> >> In my view, that's more pain than it's worth. > > Hmm, I think slapd should be able to disallow a crazy modify request like this: > > dn: cn=foobar,dc=example,dc=com > changetype: modify > replace: description > description: foobar1 > - > replace: description > description: foobar2 > - > .. > replace: description > description: foobar1000 > - Well, the clients are allowed to request a lot of strange things, some of which border on a DoS: e.g. right now slapd can't disallow a modify request like: dn: cn=foobar,dc=example,dc=com changetype: modify replace: description description: foobar1 description: foobar2 ... description: foobar1000 So there. If we can agree on a way to handle that, we might see whether it could be repurposed. I should have a patch for the accesslog issue soon. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
ondra@mistotebe.net wrote: > On Thu, Apr 06, 2017 at 05:14:15PM +0200, Michael Ströder wrote: >> ondra@mistotebe.net wrote: >>> On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael StrĂśder wrote: >>>> => There could be a slapd per-backend configuation directive to disallow it with a >>>> strong hint in the docs recommending to disallow it when using delta-syncrepl. >>>> >>>> Suggestion: >>>> disallow mod_attr_repeated >>> >>> In my view, that's more pain than it's worth. >> >> Hmm, I think slapd should be able to disallow a crazy modify request like this: >> >> dn: cn=foobar,dc=example,dc=com >> changetype: modify >> replace: description >> description: foobar1 >> - >> replace: description >> description: foobar2 >> - >> .. >> replace: description >> description: foobar1000 >> - > > Well, the clients are allowed to request a lot of strange things, some > of which border on a DoS: e.g. right now slapd can't disallow a modify > request like: Nor should we disallow any such thing. "Be liberal in what you accept." > > dn: cn=foobar,dc=example,dc=com > changetype: modify > replace: description > description: foobar1 > description: foobar2 > ... > description: foobar1000 > > So there. If we can agree on a way to handle that, we might see whether > it could be repurposed. > > I should have a patch for the accesslog issue soon. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Thu, Apr 06, 2017 at 04:41:19PM +0100, Howard Chu wrote: > ondra@mistotebe.net wrote: >> Well, the clients are allowed to request a lot of strange things, some >> of which border on a DoS: e.g. right now slapd can't disallow a modify >> request like: (pumping up an attribute to extreme size) > > Nor should we disallow any such thing. "Be liberal in what you accept." Yes, not disallow in principle, it was meant as focusing on an option to define some resource/processing limits before we even thought about the other example that is relatively benign. BTW, the patch is now available here. The empty attribute should have replicas fall back to regular syncrepl, where the ones that understand it will interpret it correctly. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170406-ITS-6545-accesslog-format-update-and-tests.patch -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Thu, Apr 06, 2017 at 02:48:45PM +0000, Frank.Swasey@uvm.edu wrote: > On Wed, 5 Apr 2017 at 8:18am, ondra@mistotebe.net wrote: > >> AFAIK, LDAP doesn't forbid it so I don't see that going away. > > Well, then that means that the current behavior is a bug in either the > syncrepl implementation or the accesslog recording. Since the MASTER > gets updated correctly and the REPLICAs (and other MMR members) all fall > down when attempting to process the accesslog entry. Yes, they might reject the log entry and fall back to regular syncrepl in the way they would in case of a conflict (which is mostly fine), or the interpretation might seem to fit and a chance is that it's different that the actual modification, causing the servers to silently get out of sync. >> It does need a fair bit of attention, the problem is it's something that >> would require a format change and there are already existing consumers >> that would be affected. >> >> I'm going to try with a patch to record something like this: >> regMod: sn:= George >> regMod: : >> regMod: sn:= George >> >> Together with the relevant syncrepl updates. >> >> While consumers would still be affected, this should be quite rare and >> the current handling of that case would have been incorrect anyway. The >> change would then only make the silent failure a noisy one. > > Noisy in that the replica/mmr falls over dead or just logs more stuff? In case of delta-syncrepl, it should reject it and fall back to regular syncrepl. I can't vouch for anything else that consumes accesslog data obviously. > To be honest, my goal is consistency. I want the replicas (and > MMR mates) to all wind up with the same values the master has. Would you be able to confirm the patch in my previous email does the right thing for you? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Today at 7:59am, ondra@mistotebe.net wrote: > Would you be able to confirm the patch in my previous email does the > right thing for you? I am building it now, I'll test and report back. -- 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)
Today at 1:36pm, Frank.Swasey@uvm.edu wrote: > Today at 7:59am, ondra@mistotebe.net wrote: > >> Would you be able to confirm the patch in my previous email does the >> right thing for you? > > I am building it now, I'll test and report back. Yes, it has worked with every nasty test I have been able to dream up to throw at it. -- 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)
changed notes changed state Feedback to Release
--On Friday, April 07, 2017 7:59 PM +0000 Frank.Swasey@uvm.edu wrote: > Today at 1:36pm, Frank.Swasey@uvm.edu wrote: > >> Today at 7:59am, ondra@mistotebe.net wrote: >> >>> Would you be able to confirm the patch in my previous email does the >>> right thing for you? >> >> I am building it now, I'll test and report back. > > Yes, it has worked with every nasty test I have been able to dream up to > throw at it. Thanks for the confirmation. This fix will be included in OpenLDAP 2.4.45. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Fixed in master Fixed in RE25 Fixed in RE24 (2.4.45)
changed notes changed state Release to Closed