openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

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 > > > Probably a side-effect of fixing ITS#5853: when setting LDAP_OPT_REFERRALS, > libldap automatically chases any referrals, but at the end returns a response > with ld_errno set to 10 and ld_matched set to the portion of DN that was matched > in the initial request. This is because the corresponding fields in the parent > request are not cleared when the referral is successfully chased. I'm trying to > fix this, but it's not clear to me when success should be detected: at > successful referral chasing request submission, I guess? When does this behavior? It doesn't show up in e.g. test009... -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

Pierangelo Masarati wrote: > Howard Chu wrote: >> ando(a)sys-net.it wrote: >>> ando(a)sys-net.it wrote: >>> >>>> Probably a side-effect of fixing ITS#5853: >>> This seems to be unrelated from ITS#5853, actually. >> Have you found the same behavior in earlier releases? > > 2.3 is OK. > 2.4.11,15 are affected. No relevant diff in libldap from 2.4.7 to .11. But quite a lot of changes in result.c from 2.4.1ALPHA to 2.4.7... -- -- 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#5987) replication documentation
by francis＠badape.net 03 Mar '09

03 Mar '09

Full_Name: Version: 2.4.15 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.6.103.253) I've had a number of issues getting replications working, I noticed that my multi-homed server was trying to replicate to itself. however I was pointed to http://www.openldap.org/its/index.cgi/?findid=5942 If the documentation could state when setting up replication that slap -H $URI needs to match all other references, even to the point where it has to match port, ie ldap://ldap01 != ldap://ldap01:389 making everything match has fixed a lot of my problems.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by hyc＠symas.com 03 Mar '09

03 Mar '09

ando(a)sys-net.it wrote: > mariusp44(a)gmail.com wrote: >> I have just compiled and tested 2.4.15 and result is same: cleartext, >> md5 and sha works, smd5, ssha and crypt doesn't. >> >> Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. > > I have no chance to test on that arch. You should figure our why those > hashes are not supported. Did you enable crypt (--enable-crypt)? gcc 3.4.3 was released November 4 2004 http://gcc.gnu.org/gcc-3.4/ and is known to have many bugs. It's also already known that old gcc releases have other problems on Sparc. (E.g. ITS#5875.) Please use a working compiler. As a workaround, recompile the offending functions with optimization disabled. That usually helps in cases like this. There is no bug in OpenLDAP Software here, this ITS will be closed. -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 03 Mar '09

03 Mar '09

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> Probably a side-effect of fixing ITS#5853: >> >> This seems to be unrelated from ITS#5853, actually. > > Have you found the same behavior in earlier releases? 2.3 is OK. 2.4.11,15 are affected. >> Another note: if a search reference is received, it is returned by >> libldap and additionally it is chased, so one gets both the search >> reference and the chased search reference results. > > That certainly wouldn't have changed due to any of the recent patches. > Probably the response gets added to the message chain unconditionally, > but obviously doesn't belong there if chasing occurred. 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#5985) replication lockout with syncrepl
by hyc＠symas.com 03 Mar '09

03 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3/2.4/HEAD > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I noticed back in testing with OpenLDAP 2.3 that if a master gets a high rate of > changes, and you have 3+ replicas, usually 2 replicas will end up getting all of > the changes while the 3rd+ replicas have to wait until those 2 finish before > getting changes. If the high rate of changes goes on for a long enough period > of time, this can cause the other replicas to get so far out of sync that it is > more efficient to reload them than to wait on them to re-sync. I discussed this > with Howard, and in reviewing the code, he sees there's an underlying design > issue with updates that is causing this. His comments: > > Once a thread for a psearch wakes up, it sends all the changes that were queued > so it may hog an entire thread for a long time before the next psearch comes off > the queue > Fixing this issue would require a complete redesign of the psearch queue handling. Instead of queuing up a separate response per psearch, there should be a single queue of responses, and the qplayer should iterate thru to match a response to each of the active psearches. That would guarantee that all replicas receive a given change before any of them receives the next change. This would also help with the ordering issues discussed recently on -technical and -devel. I suspect this is too big a change to target the next (.16) release, since we're focusing on re-stabilizing the code right now. -- -- 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by hyc＠symas.com 03 Mar '09

03 Mar '09

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Probably a side-effect of fixing ITS#5853: > > This seems to be unrelated from ITS#5853, actually. Have you found the same behavior in earlier releases? > > Another note: if a search reference is received, it is returned by > libldap and additionally it is chased, so one gets both the search > reference and the chased search reference results. That certainly wouldn't have changed due to any of the recent patches. Probably the response gets added to the message chain unconditionally, but obviously doesn't belong there if chasing occurred. -- -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by ando＠sys-net.it 03 Mar '09

03 Mar '09

mariusp44(a)gmail.com wrote: > I have just compiled and tested 2.4.15 and result is same: cleartext, > md5 and sha works, smd5, ssha and crypt doesn't. > > Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. I have no chance to test on that arch. You should figure our why those hashes are not supported. Did you enable crypt (--enable-crypt)? 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#5986) backglue tool entry_{first, next} may fail when DBs are empty
by ando＠sys-net.it 03 Mar '09

03 Mar '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Under some special circumstances, like sequences of empty/full/empty databases, the glue_tool_entry_first/glue_tool_entry_next sequence may fail. I think I've fixed the problem; please review. p.

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 02 Mar '09

02 Mar '09

I have just compiled and tested 2.4.15 and result is same: cleartext, md5 and sha works, smd5, ssha and crypt doesn't. Solaris 10 SPARC latest, gcc 3.4.3, Berkeley DB 4.7.25, opessl 0.9.8j. /Marius On Mon, Mar 2, 2009 at 8:55 AM, <ando(a)sys-net.it> wrote: > michael(a)stroeder.com wrote: >> mariusp44(a)gmail.com wrote: >>> I am running openldap 2.4.11 >> >> Note that this release is already a bit old. If you're testing it is >> more helpful to use a recent release (like 2.4.15 at the moment). > > The fact is that there is no point in chasing a bug in an old release. > If the bug exists in the latest, fine. Otherwise one needs to upgrade > anyway, either to the latest release or to the forthcoming when the bug > is fixed. > > 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