openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

Quanah Gibson-Mount wrote: >> I'm hitting an issue like this in some of the replication tests I'm >> currently performing. For this purpose, I think we could hack >> ldapsearch (or add a new prog, or use a script on ldapsearch output) >> that sorts entries content attribute-wise and, within each attribute, >> value-wise. Something like "sort" applied entry-wise after unwrapping >> line folding, optionally case-insensitive would probably suffice. > > I have a script somewhere from Matt Backes @ Symas that sorts LDIF > files. It was useful for seeing if it made any difference in slapadd (it > didn't). Well, if it were distributable, and written in a widely supported scripting language, it would be quite useful... 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by quanah＠zimbra.com 14 Nov '08

14 Nov '08

--On Friday, November 14, 2008 9:34 PM +0000 ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Pierangelo Masarati writes: >>>> I think ITS#5326 is related. Namely, write operations (add, rename) >>>> should always rebuild the (new)DN hierarchically from the tree. >>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >>> needs to handle databases that are not that nice: We can't require >>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >>> is an RFC (4533) so it should handle non-OpenLDAP peers. >> >> Syncrepl of course *handles* all of those cases. The only issue here is >> that our tests expect the results to be in a specific order, which is >> obviously an invalid requirement in the grand scheme of things. > > > I'm hitting an issue like this in some of the replication tests I'm > currently performing. For this purpose, I think we could hack > ldapsearch (or add a new prog, or use a script on ldapsearch output) > that sorts entries content attribute-wise and, within each attribute, > value-wise. Something like "sort" applied entry-wise after unwrapping > line folding, optionally case-insensitive would probably suffice. I have a script somewhere from Matt Backes @ Symas that sorts LDIF files. It was useful for seeing if it made any difference in slapadd (it didn't). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Pierangelo Masarati writes: >>> I think ITS#5326 is related. Namely, write operations (add, rename) >>> should always rebuild the (new)DN hierarchically from the tree. >> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >> needs to handle databases that are not that nice: We can't require >> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >> is an RFC (4533) so it should handle non-OpenLDAP peers. > > Syncrepl of course *handles* all of those cases. The only issue here is that > our tests expect the results to be in a specific order, which is obviously an > invalid requirement in the grand scheme of things. I'm hitting an issue like this in some of the replication tests I'm currently performing. For this purpose, I think we could hack ldapsearch (or add a new prog, or use a script on ldapsearch output) that sorts entries content attribute-wise and, within each attribute, value-wise. Something like "sort" applied entry-wise after unwrapping line folding, optionally case-insensitive would probably suffice. 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 14 Nov '08

14 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> I think ITS#5326 is related. Namely, write operations (add, rename) >> should always rebuild the (new)DN hierarchically from the tree. > > I'm not sure what exactly the problem is, if any:-) Syncrepl itself > needs to handle databases that are not that nice: We can't require > that of back-perl, nor back-ldap which accesses a non-OpenLDAP server > (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl > is an RFC (4533) so it should handle non-OpenLDAP peers. Syncrepl of course *handles* all of those cases. The only issue here is that our tests expect the results to be in a specific order, which is obviously an invalid requirement in the grand scheme of things. > Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. > Unless we want back-ldif to be different just to test that syncrepl > handles different backends. Might also make a test which replicates > between different backends - e.g. $BACKEND and back-ldif. The syncrepl rename-detection can be improved - we can compare the normalized parent DN, separately from the un-normalized RDN. This would eliminate a false detection of a move/rename solely due to superior RDNs being mismatched. -- -- 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#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

quanah(a)zimbra.com writes: > What about back-sql, back-ndb, etc? The test0* scripts don't seem to be really ported to other backends than bdb, hdb and ldbm, though I'm guessing about ndb. Back-sql has its own test scripts: tests/scripts/sql-*. acfilter.sh and run.in accomodate ndb a bit, but most of the $BACKEND tests are years old so I expect porting tests to ndb is in its infancy. Same with back-ldif and back-null, they will need help from acfilter.sh and some of the tests. Though there are a few tests for $BACKEND = ldif. -- Hallvard

1 0

Re: (ITS#5810) $BACKEND selections in make test
by quanah＠zimbra.com 14 Nov '08

14 Nov '08

--On Friday, November 14, 2008 3:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > A number of tests contain code like > if test "$BACKEND" != "bdb" && test "$BACKEND" != "hdb" ; then > echo "Test does not support $BACKEND" > exit 0 > fi > This looks like a holdover from ldbm, I suggest we remove it. What about back-sql, back-ndb, etc? I'm not sure it's just a holdover of ldbm. There's quite a few backends that may not support a number of things. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard A number of tests contain code like if test "$BACKEND" != "bdb" && test "$BACKEND" != "hdb" ; then echo "Test does not support $BACKEND" exit 0 fi This looks like a holdover from ldbm, I suggest we remove it. Also tests for supported LDAP features chould exclude instead of include a backend. E.g. in test040-subtree-rename, replace case $BACKEND in hdb | ldif) ;; *) echo "subtree rename not supported by back-$BACKEND" exit 0 esac with case $BACKEND in bdb) echo "subtree rename not supported by back-$BACKEND" exit 0 esac Or possibly that shold be "... in bdb | ndb)", I don't know. Whoever knows can fix it either now or later:-) Also I'm not quite sure which of the tests that fail for back-ldif are supposed to. Back-null has no "directory" directive. To support it, tests/scripts/conf.sh could recognize a format like #!backend!...!backend!#config-line where the config-line is uncommented if $BACKEND is none of the backends. Thus, "#!null!#directory @TESTDIR@/db.1.a". Takes a backend list in case tests for other directoryless backends arrive. Finally I'll append " for ${BACKEND}" to the Starting/Running/Test completed output from tests/run and tests/scripts/all: run: echo "Running ${SCRIPT} for ${BACKEND}..." all: echo ">>>>> Executing all LDAP tests for ${BACKEND}" all: echo ">>>>> Starting ${TB}`basename $CMD`${TN} for ${BACKEND}..." all: echo ">>>>> $CMD completed ${TB}OK${TN} for ${BACKEND}." all: echo ">>>>> $CMD ${TB}failed${TN} for ${BACKEND} (exit $RC)"

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 14 Nov '08

14 Nov '08

Howard Chu wrote : >I ran your test and examined the logs. I don't think your test is valid. >Search for "not indexed" in the logs - you have not indexed the necessary >attributes, as recommended in the documentation. Hi Howard, Thank you for your testing. You are right about the indexes in the slave (the master indexes are OK). After adding the line : #bdb#index entryUUID,entryCSN eq to the slave's config file the problem persisted in the version checked ou on November 4. So I checked out the HEAD last night. The good news is that the problem is fixed now and every thing seems OK (six new modifications have been made to syncprov.c since Nov 2, one of which being made by Quanah and related to this issue). So the issue can be closed :-) Thanks again Best Regards Ali

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Pierangelo Masarati writes: >>> I think ITS#5326 is related. Namely, write operations (add, rename) >>> should always rebuild the (new)DN hierarchically from the tree. >> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >> needs to handle databases that are not that nice: We can't require >> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >> is an RFC (4533) so it should handle non-OpenLDAP peers. >> >> Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. >> Unless we want back-ldif to be different just to test that syncrepl >> handles different backends. Might also make a test which replicates >> between different backends - e.g. $BACKEND and back-ldif. > > Agree to your objections. Though, ITS#5326 would improve OpenLDAP, IMHO :) Agree *with* your objections ... *implementing the feature proposed in* ITS#5326 ... 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> I think ITS#5326 is related. Namely, write operations (add, rename) >> should always rebuild the (new)DN hierarchically from the tree. > > I'm not sure what exactly the problem is, if any:-) Syncrepl itself > needs to handle databases that are not that nice: We can't require > that of back-perl, nor back-ldap which accesses a non-OpenLDAP server > (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl > is an RFC (4533) so it should handle non-OpenLDAP peers. > > Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. > Unless we want back-ldif to be different just to test that syncrepl > handles different backends. Might also make a test which replicates > between different backends - e.g. $BACKEND and back-ldif. Agree to your objections. Though, ITS#5326 would improve OpenLDAP, IMHO :) 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

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