openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by hyc＠symas.com 08 Nov '08

08 Nov '08

ando(a)sys-net.it wrote: > ando(a)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/

1 0

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)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(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

ando(a)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(a)sys-net.it -----------------------------------

1 0

(ITS#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

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.

1 0

Re: (ITS#5797) build failed
by ando＠sys-net.it 08 Nov '08

08 Nov '08

cycwj(a)163.com wrote: > Full_Name: bluewind > Version: 2.4.12 > OS: ubunt server 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (219.133.134.8) > > > try to build on ubutnu server 8, use install manaul from www.openldap.org > > #./configure (ok) > #make depen (ok) > #make (ok) > > but,when execution > > #make test > > the system stop on "Running slapadd to build slapd database...", no any > response > > after about 1 hour Thanks for the detailed report. Did you read <http://www.openldap.org/faq/data/cache/56.html>, significantly <http://www.openldap.org/faq/data/cache/58.html>, <http://www.openldap.org/faq/data/cache/59.html> and <http://www.openldap.org/faq/data/cache/1122.html>? 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(a)sys-net.it -----------------------------------

1 0

(ITS#5797) build failed
by cycwj＠163.com 06 Nov '08

06 Nov '08

Full_Name: bluewind Version: 2.4.12 OS: ubunt server 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (219.133.134.8) try to build on ubutnu server 8, use install manaul from www.openldap.org #./configure (ok) #make depen (ok) #make (ok) but,when execution #make test the system stop on "Running slapadd to build slapd database...", no any response after about 1 hour

1 0

Re: (ITS#5773) bi_entry_get_rw() and overlays issue
by hyc＠symas.com 06 Nov '08

06 Nov '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> I think bi_entry_get_rw() needs work. >> Or maybe phase it out in favor of some other call? >> >>> In fact, as also discussed in ITS#5628, callers either return the >>> entry or have no means to modify the arguments of the request. >> It has more troubles than that. See e.g. the notes about passing rw=1 >> (write) to it here: >> http://www.openldap.org/lists/openldap-devel/200803/msg00055.html >> And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which >> says to pass an rw=1 argument to bi_entry_release_rw(). > > Well, I see many places where an entry needs to be fetched. Typically, > it needs to be done read-only. In fact, the rw flag makes no sense. You can only fetch an entry ro; if you actually fetched it for write access and modified the entry, there's no API to commit the changed entry to stable storage. You would only be making a transient change to a cached copy (which could disappear as soon as you release the entry). So if we're going to change this API, the first thing to do is get rid of the rw flag. You must use be_modify if you want to change anything about an entry... > So the difference between > bi_entry_get_ro() and an internal search is that if we are fine with the > entry in-cache, we save lots of manipulation. However this might no > longer suffice when overlays muck with the entry (like slapo-rwm). > Moreover, when overlays are present, I see the need to: > 1) run it like it came from outside, going thru all the overlays That's what overlays currently do when they do the bd_info swap and then call be_entry_get_rw(). > 2) go straight to the underlying database That's done by calling bd_info->bi_entry_get_rw()... > 3) go thru overlays starting at some point (e.g. when called from inside > an overlay under the assumption the entry is fetched as that overlay > would see it, so with only any possible mucking from overlays layered > deeper than the caller). That's what overlay_entry_get_ov() does. Also note that passing a NULL overinst here accomplishes (2). > This probably needs to modify the way > callbacks are actually called, allowing some "after self" feature in > playing not just the overlay list, but also the response (and the cleanup). Then we need an "opcode" for this, so that response / cleanup handlers know why they're being invoked. -- -- 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#5796) back-sql intermittently failing
by robb＠wtg.cw.com 06 Nov '08

06 Nov '08

Full_Name: Robert Brooks Version: 2 OS: 2.4.12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) Set up is a pair of centos 4 hosts, one acts as primary, the other is a syncrepl consumer and mysql slave. Apart from syncrepl config/myqsl slave all config and software versions are the same. Mysql queries on both hosts are to localhost via socket. After a period of operation (24-48 hours) the slave host drops the back-sql part of directory for some queries (same query will suceed some times). Using strace it can been seen that the ldap searches are not resulting in queries to mysql. Back-sql is a subordinate db and results from hdb backed part of directory are returned. Restarting slapd fixes the problem, but start-up reports the shutdown was unclean on hdb db. Operation of primary is reliable.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 06 Nov '08

06 Nov '08

ali.pouya(a)free.fr wrote: > Howard Chu wrote : > >> I see. >> >> This has been fixed for back-bdb/hdb in HEAD. If the database was shut down >> cleanly before, there will be no scan on the next startup. > > Hi Howard, > Thanks for the corrections. > We tested the HEAD extracted on monday november 3. Unfortunately the problem > explained in point 2 persists (even after a clean shutdown). > Our directory contains 10 million entries. It can evolve to 40 million entries > next year. > The local sacanning speed is around 250 000 entries per minute. > So the scan of the recent objects on the standby mirror after startup can take > several minutes (unless if we distribute the write operations on both mirrors). I don't see this happening on my builds. Maybe you should post your configs and a sample of the data and modifications used to illustrate the problem. -- -- 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

Re: (ITS#5783) Possible DB corruption
by hyc＠symas.com 06 Nov '08

06 Nov '08

Maykel Moya wrote: > El jue, 06-11-2008 a las 07:30 -0800, Howard Chu escribió: > >> moya(a)latertulia.org wrote: >>> Full_Name: Maykel Moya >>> Version: 2.4.11 >>> OS: Debian Lenny >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (200.55.135.211) >>> >>> >>> It's second time that I have bitten by this: >>> >>> Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. >>> >>> After that I'm unable to bind against the DSA. The problem has arise in two >>> independent systems. >> This is now fixed in HEAD. > > Oh, thanks. Is there a way I can get the patch for applying it to my > system? See the diff here http://www.openldap.org/lists/openldap-commit/200811/msg00034.html -- -- 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

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