openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

Re: (ITS#5984) chain/syncprov problems
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 8:37 PM +0000 quanah(a)zimbra.com wrote: > --On Monday, March 02, 2009 9:28 PM +0100 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> It's working just fine here (HEAD/re24). The main differences in >> configuration are modules (everything here is built statically) and few >> paths, URIs and so. You should walk through it with a debugger, after >> identifying (with -d -1) how far it gets before going berserk. > > But -d -1, as I pasted before, didn't actually show anything I saw useful > at all. And I don't have access to their system. :/ > > Once my servers are back online, I can play with this more. I'd guess > it's one of those weird load dependencies we've been seeing. Changing compilers/libc/kernel (i.e. using a different OS) resolved it, so it must be a libc/compiler/optimization/kernel bug of some sort. Pick any one or more. :P I'll close the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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