openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

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

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

13 Nov '08

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. It's unrelated to the other recent back-ldif patches: 1.98 passes these tests, as does 1.87, while 1.87 + a "rename to same DN" patch breaks. Rev 1.99 passes test005-modrdn & test040-subtree-rename. Another strange thing I've seen recently is that bash once in a while complains something like ./scripts/test018-syncreplication-persist: line 361: echo: write error: Interrupted system call This is indeed just an "echo" statement in the test script: echo "Comparing retrieved entries from producer and consumer..." Don't know what's going on or if it's relatead, but I've not seen (or noticed) it before.

1 0

(ITS#5808) jldap library connect timeout doesn't work
by mavricknzwork＠yahoo.com 13 Nov '08

13 Nov '08

Full_Name: Matt Stevenson Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.129.121.62) I believe trying to timeout using "LDAPConnection(int timeout)" will not work. The below patch fixes that, with limited testing. Regards Matt I, Matt Stevenson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. ### Eclipse Workspace Patch 1.0 #P jldap Index: com/novell/ldap/Connection.java =================================================================== RCS file: /repo/OpenLDAP/pkg/jldap/com/novell/ldap/Connection.java,v retrieving revision 1.91 diff -u -r1.91 Connection.java --- com/novell/ldap/Connection.java 22 Feb 2008 11:29:50 -0000 1.91 +++ com/novell/ldap/Connection.java 13 Nov 2008 11:22:30 -0000 @@ -21,7 +21,7 @@ import java.net.Socket; import java.net.SocketException; import java.net.SocketTimeoutException; - +import java.net.InetSocketAddress; import com.novell.ldap.asn1.*; import com.novell.ldap.client.*; @@ -454,7 +454,10 @@ } socket = mySocketFactory.createSocket(host, port); } else { - socket = new Socket(host, port); + socket = new Socket(); + InetSocketAddress socketAddress = new InetSocketAddress(host, port); + socket.connect(socketAddress, myTimeOut); + //socket = new Socket(host, port); if(myTimeOut > 0) { socket.setSoTimeout(myTimeOut);

1 0

RE: (ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 13 Nov '08

13 Nov '08

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). Anyway, you could mention it in the admin guide. > -----Message d'origine----- > De : Gavin Henry [mailto:ghenry@OpenLDAP.org] > Envoyé : mercredi 12 novembre 2008 17:38 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5788) Search does not work with nested naming contexts > > emmanuel.duru(a)atosorigin.com wrote: > > OK, thank you. > > I didn't see this configuration directive in the admin guide... > > All the details are always in the man pages. > > Cheers. > > -- > Kind Regards, > > Gavin Henry. > OpenLDAP Engineering Team. > > E ghenry(a)OpenLDAP.org > > Community developed LDAP software. > > http://www.openldap.org/project/

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
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