openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

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

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

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. -- Hallvard

1 0

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

14 Nov '08

I think ITS#5326 is related. Namely, write operations (add, rename) should always rebuild the (new)DN hierarchically from the tree. This might be expensive, and a pain for back-ldif, but would save lots of headaches and make entries always consistent. 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 h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

I wrote: > A back-ldif entry file only contain the entry's RDN, not the DN. > (...) Yup, that was it. Different case in parent DNs. This: --- syncrepl.c 13 Nov 2008 21:46:49 -0000 1.421 +++ syncrepl.c 14 Nov 2008 09:29:30 -0000 @@ -3050,4 +3050,6 @@ dni->delOldRDN = 1; } + Debug( LDAP_DEBUG_TRACE, "<<::syncrepl rename:%s:%s:%d:>>\n", + rs->sr_entry->e_dn, dni->new_entry->e_dn, dni->delOldRDN ); /* A ModDN has happened, but other changes may have * occurred before we picked it up. So fallthru to shows these renames, with dni->delOldRDN = 1: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com cn=James A Jones 1,ou=alumni association,ou=people,dc=example,dc=com cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com cn=Barbara Jensen,ou=information technology division,ou=people,dc=example,dc=com Not sure what the right fix is. ldif_back_modrdn() receives op->orr_modlist already filled in with the cn="James A Jones 1" change. Just use the awk variant to sort the attribute values in tests/scripts/acfilter.sh? What happens with syncrepl between two servers that do not spell DNs the same - e.g. syncrepl from BDB to a backend which stores just the normalized DN? -- Hallvard

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2008