openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

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

02 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 02 Mar '09

02 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 02 Mar '09

02 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

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 02 Mar '09

02 Mar '09

I would like to end the patch of dnssrv.c by implementing the weighty notion in SRV searchs (according to the rfc2782); but the use of a file disk to store the previous answers does seem to me a very successful solution. Would anybody have better one idea?...

1 0

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

02 Mar '09

--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. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5984) chain/syncprov problems
by ando＠sys-net.it 02 Mar '09

02 Mar '09

quanah(a)zimbra.com wrote: > Same problem once it is changed to: > > overlay chain > chain-uri "ldap://xxx" > chain-idassert-bind bindmethod="simple" > binddn="cn=Manager,dc=XYZ,dc=com" > credentials="secrets" > mode="self" > chain-tls start > chain-return-error TRUE > > > slapd still fails to start as long as both chain and syncprov are enabled. > It also fails to log any reason as to why it's failing to start up. 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. 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 7:58 PM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> chain-idassert-bind >> bindmethod="simple" >> binddn="cn=Manager,dc=XYX,dc=com" >> credentials="secret" >> mode="self" >> chain-tls start >> chain-return-error TRUE > > chain-tls start > chain-return-error TRUE > > are not allowed within a "chain-idassert-bind"; probably the leading > whitespace is not intended. Same problem once it is changed to: overlay chain chain-uri "ldap://xxx" chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XYZ,dc=com" credentials="secrets" mode="self" chain-tls start chain-return-error TRUE slapd still fails to start as long as both chain and syncprov are enabled. It also fails to log any reason as to why it's failing to start up. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5985) replication lockout with syncrepl
by quanah＠zimbra.com 02 Mar '09

02 Mar '09

--On Monday, March 02, 2009 7:59 PM +0000 ando(a)sys-net.it wrote: > 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 > > Is this supposed to hit 2.4 as well, as you indicated in the ITS' > "Version"? Yes. It affects OL2.3, OL2.4, and remains this way in current HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2009