openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

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

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

13 Nov '08

Sigh... > Thus a subtree search from the suffix ends up recursively > constructing the right DNs ...as far as back-ldif can know (parent DN of suffix can vary)... > but a search based further down does not. Good night:-) -- Hallvard

1 0

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

13 Nov '08

hyc(a)symas.com writes: > I think you need to check what back-ldif is > doing that triggers the false detection of a rename op. No time now, but I expect it's because of the following. From memory, I hope I get the details right: A back-ldif entry file only contain the entry's RDN, not the DN. The exact spelling of the suffix DN is not stored anywhere, except that of its RDN. And if you have stored the suffix entry "dc=NO" and add "dc=uio,dc=no", the lowercase in "dc=no" is lost. Furthermore the backend does not read parent and grandparent entries to construct the right DN. Instead it uses the baseDN of the request, though when it reads an entry it does replace the RDN with that from the entry file. Thus a subtree search from the suffix ends up recursively constructing the right DNs, but a search based further down does not. We could use the spelling of the suffix from slapd.conf's suffix. However that doesn't help operations with baseDN below the suffix, and unless we do read parent DNs it makes treatment of the suffix and other DNs inconsistent. Or we could cache all the DNs, but.. well, this is just back-ldif. -- Hallvard

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 13 Nov '08

13 Nov '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> With the latest back-ldif/ldif.c (rev 1.99), >> ./run -b ldif test048-syncrepl-multiproxy >> breaks with "master and P1 slave databases differ" and >> ./run -b ldif test018-syncreplication-persist >> when patched to not reject $BACKEND = ldif >> breaks with "producer and consumer databases differ". >> >> The offender is "rename to same DN" (ITS#5319), i.e. rev 1.99. >> Unless there is a big "duh!" in it, it exposed a syncrepl bug. > > Yes, thanks. The consumer assumed that an entry being renamed would have no > other modifications associated with it. This assumption is wrong. There are no > rename ops in test018, but apparently back-ldif is not returning the RDN with > the same case as the original entry, so syncrepl assumes a rename (that only > changed letter case) was done. > > Still looking at the fix. This is mostly fixed in HEAD. The diff still doesn't compare because some cn values are in the wrong order. I think you need to check what back-ldif is doing that triggers the false detection of a rename op. -- -- 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 13 Nov '08

13 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > With the latest back-ldif/ldif.c (rev 1.99), > ./run -b ldif test048-syncrepl-multiproxy > breaks with "master and P1 slave databases differ" and > ./run -b ldif test018-syncreplication-persist > when patched to not reject $BACKEND = ldif > breaks with "producer and consumer databases differ". > > The offender is "rename to same DN" (ITS#5319), i.e. rev 1.99. > Unless there is a big "duh!" in it, it exposed a syncrepl bug. Yes, thanks. The consumer assumed that an entry being renamed would have no other modifications associated with it. This assumption is wrong. There are no rename ops in test018, but apparently back-ldif is not returning the RDN with the same case as the original entry, so syncrepl assumes a rename (that only changed letter case) was done. Still looking at the fix. -- -- 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#5788) Search does not work with nested naming contexts
by h.b.furuseth＠usit.uio.no 13 Nov '08

13 Nov '08

Reopening this as a doc bug. emmanuel.duru(a)atosorigin.com writes: > I'm sorry, but I am mainly working on Windows, and the use of man > pages is not that easy on Windows (or you would say Windows people are > not used to read man pages). The man pages are online too: http://www.openldap.org/software/man.cgi > Anyway, you could mention it in the admin guide. I agree. "What to do"-issue, belongs in the Guide. Though the manpages could be updated too, so a user who does't know to look for it has a better chance of learning it. Does this look right, as an addition under the "database" keyword in slapd.conf(5)? "LDAP operations normally access only one database. However databases that provide related naming contexts ("suffixes") may be glued together with the /subordinate/ keyword. Some other features such as access controls and the /translucent/ overlay can also involve multiple databases." BTW, the Guide's chapter 16 does say "... A better approach would be to use explicitly defined local and proxy databases in /subordinate/ configurations to provide a seamless view of the Distributed Directory." but it doesn't mention that this refers to the "subordinate" keyword - if it does. The rest of the "subordinates" in the guide do not. -- Hallvard

1 0

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

13 Nov '08

Ali Pouya wrote: > Howard Chu wrote : >> 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. > > > > Hi Howard, > I just uploaded the archive file ITS_5640.tar.gz to the OpenLdap FTP incoming directory. > The script test099-syncreplication-mirrormode of this archive, derived from the test018-syncreplication- > persist, reproduces the problem in the OpenLdap test environment. > To do so copy the file in the test directory of the openldap source, then : > > cd tests > tar xvzf ./ITS_5640.tar.gz > ./run test099-syncreplication-mirrormode > > Then look for the string 'access_allowed' in the log files. > This test shows that the problem has worsen : > > 1) The slave mirror does not scan only the recent objects but the whole tree, > 2) By sending a search with a specific control to the master it makes the master scan its whole tree as > well. > > This situation is reproduced each time you do a write operation in the master while the slave is down, and > then start the slave. > The tests have been done in the HEAD extracted on Tuesday November 4. 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. -- -- 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#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 13 Nov '08

13 Nov '08

Howard Chu wrote : >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. Hi Howard, I just uploaded the archive file ITS_5640.tar.gz to the OpenLdap FTP incoming directory. The script test099-syncreplication-mirrormode of this archive, derived from the test018-syncreplication- persist, reproduces the problem in the OpenLdap test environment. To do so copy the file in the test directory of the openldap source, then : cd tests tar xvzf ./ITS_5640.tar.gz ./run test099-syncreplication-mirrormode Then look for the string 'access_allowed' in the log files. This test shows that the problem has worsen : 1) The slave mirror does not scan only the recent objects but the whole tree, 2) By sending a search with a specific control to the master it makes the master scan its whole tree as well. This situation is reproduced each time you do a write operation in the master while the slave is down, and then start the slave. The tests have been done in the HEAD extracted on Tuesday November 4. I hope this can help. Best Regards Ali

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