Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When syncrepl is configured, schema checking is switched off. As a consequence, schema checking does not occur for all writes, including direct writes from clients when MMR/MM is in use. Internal writes performed by syncrepl should be marked as such, in order to disable schema checking only when appropriate. p.
ando@sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > When syncrepl is configured, schema checking is switched off. As a consequence, > schema checking does not occur for all writes, including direct writes from > clients when MMR/MM is in use. > > Internal writes performed by syncrepl should be marked as such, in order to > disable schema checking only when appropriate. It all seems to boil down to the fact that syncrepl schemachecking is off by default. So, not specifying any results in having multimasters with schemachecking disabled, which is not desirable. I recommend schema checking be on by default. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
changed notes
ando@sys-net.it wrote: > ando@sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> When syncrepl is configured, schema checking is switched off. As a consequence, >> schema checking does not occur for all writes, including direct writes from >> clients when MMR/MM is in use. >> >> Internal writes performed by syncrepl should be marked as such, in order to >> disable schema checking only when appropriate. > > It all seems to boil down to the fact that syncrepl schemachecking is > off by default. So, not specifying any results in having multimasters > with schemachecking disabled, which is not desirable. I recommend > schema checking be on by default. All we have to do is change the code from setting the DB flag to using the per-op o_no_schema_check flag. IMO defaulting schemacheck off for replication is fine because replicated entries will have been checked on the master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > ando@sys-net.it wrote: >> ando@sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (82.63.140.131) >>> Submitted by: ando >>> >>> >>> When syncrepl is configured, schema checking is switched off. As a >>> consequence, >>> schema checking does not occur for all writes, including direct >>> writes from >>> clients when MMR/MM is in use. >>> >>> Internal writes performed by syncrepl should be marked as such, in >>> order to >>> disable schema checking only when appropriate. >> >> It all seems to boil down to the fact that syncrepl schemachecking is >> off by default. So, not specifying any results in having multimasters >> with schemachecking disabled, which is not desirable. I recommend >> schema checking be on by default. > > All we have to do is change the code from setting the DB flag to using > the per-op o_no_schema_check flag. IMO defaulting schemacheck off for > replication is fine because replicated entries will have been checked on > the master. Well, it used to be so, but now with MMR (and mirror mode) it's no longer so. Using the per-op is fine, as long as the caller consistently sets it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Howard Chu wrote: > All we have to do is change the code from setting the DB flag to using the > per-op o_no_schema_check flag. IMO defaulting schemacheck off for replication > is fine because replicated entries will have been checked on the master. Of course, it was already using the per-op flag too. Probably meant to remove the per-DB flag and forgot to some time ago. Fixed now in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
hyc@symas.com writes: > IMO defaulting schemacheck off for replication is fine because > replicated entries will have been checked on the master. What if two simulaneous, valid changes to the same entry on two masters produce a schema error when combined? I haven't been tracking MMR - does the entry end up with a schema error, or does MMR consider two changes to the same entry a conflict and fail to replicate, or...? -- Hallvard
h.b.furuseth@usit.uio.no wrote: > hyc@symas.com writes: >> IMO defaulting schemacheck off for replication is fine because >> replicated entries will have been checked on the master. > > What if two simulaneous, valid changes to the same entry on two masters > produce a schema error when combined? I haven't been tracking MMR - > does the entry end up with a schema error, or does MMR consider two > changes to the same entry a conflict and fail to replicate, or...? AFAIK, the last entryCSN should win. Something like: MM1 MM2 time 0 csn0 csn0 (same) time 1 csn0+1 -> - time 2 - <- csn0+2 time 3 csn0+1,csn0+2 csn0+2,csn0+1 (one wins, I assume the latest) At all times, each entry is sane. The one that wins is sane, the one that loses will be replaced by the one that wins. The reason for this ITS and other stuff that will come shortly is that I've been asked to audit MMR, by designing a suite of tests that check functionality and reliability of MMR under possibly reproducible conflict, concurrency and other critical conditions. I'm highlighting a series of issues. I won't post ITSes or other notices until I find out whether it's slapd's or my tests' fault. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD (confirmed) fixed in RE24