- openldap-bugs - openldap.org

Re: (ITS#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 02 Mar '09

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

02 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 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

Re: (ITS#5985) replication lockout with syncrepl
by ando＠sys-net.it 02 Mar '09

02 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 Is this supposed to hit 2.4 as well, as you indicated in the ITS' "Version"? 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 ando＠sys-net.it 02 Mar '09

02 Mar '09

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. 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#5985) replication lockout with syncrepl
by quanah＠OpenLDAP.org 02 Mar '09

02 Mar '09

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

1 0

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

02 Mar '09

Full_Name: Quanah Gibson-Mount Version: 2.4.15 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In a discussion with a user on the #openldap channel in IRC, they noted that if they had both the chain and syncprov overlays enabled in their configuration, slapd would refuse to start. Commenting out either one allowed slapd to start. I didn't see any obvious misconfigurations on their part. Configs as follows: include /usr/local/openldap-2.4.15/etc/openldap/schema/core.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/cosine.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/misc.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/nis.schema include /usr/local/openldap-2.4.15/etc/openldap/schema/dyngroup.schema pidfile /usr/local/openldap-2.4.15/var/run/slapd.pid argsfile /usr/local/openldap-2.4.15/var/run/slapd.args modulepath /usr/local/openldap-2.4.15/libexec/openldap moduleload accesslog.la moduleload auditlog.la moduleload back_bdb.la moduleload back_ldap.la moduleload back_monitor.la moduleload dyngroup.la moduleload ppolicy.la moduleload syncprov.la moduleload unique.la # TLS Section TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 TLSCACertificateFile /usr/local/openldap-2.4.15/etc/openldap/cacert.pem TLSCertificateFile /usr/local/openldap-2.4.15/etc/openldap/servercert.pem TLSCertificateKeyFile /usr/local/openldap-2.4.15/etc/openldap/serverkey.pem TLSVerifyClient never security tls=256 password-crypt-salt-format "$1$%.8s$" loglevel 256 loglevel stats sync overlay chain chain-uri "ldap://xxx" chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=XYX,dc=com" credentials="secret" mode="self" chain-tls start chain-return-error TRUE database bdb suffix "dc=XYZ,dc=com" rootdn "cn=Manager,dc=XYZ,dc=com" rootpw secret directory /usr/local/openldap-2.4.15/var/openldap-data/XYZ.com-slave overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=010 provider=ldap://xxx type=refreshAndPersist interval=00:00:00:05 searchbase="dc=XYZ,dc=com" bindmethod=simple binddn="cn=SyncRepl,dc=XYZ,dc=com" credentials=secret retry="5 5 300 5" starttls=yes tls_reqcert=never slapd -d -1 output wasn't too helpful, either: @(#) $OpenLDAP: slapd 2.4.15 (Mar 2 2009 11:27:50) $ bill@crash:/home/bill/openldap-2.4.15/servers/slapd ldap_pvt_gethostbyname_a: host=crash, r=0 daemon_init: listen on ldap:// daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://) daemon: listener initialized ldap:// daemon_init: 2 listeners opened ldap_create slapd init: initiated server. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 4.7.25: (May 15, 2008) bdb_db_init: Initializing BDB database >>> dnPrettyNormal: <dc=XYZ,dc=com> <<< dnPrettyNormal: <dc=XYZ,dc=com>, <dc=XYZ,dc=com> >>> dnPrettyNormal: <cn=Manager,dc=XYZ,dc=com> <<< dnPrettyNormal: <cn=Manager,dc=XYZ,dc=com>, <cn=manager,dc=XYZ,dc=com> >>> dnNormalize: <cn=Manager,dc=XYZ,dc=com> <<< dnNormalize: <cn=manager,dc=XYZ,dc=com> slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.

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

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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by michael＠stroeder.com 02 Mar '09

02 Mar '09

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). Ciao, Michael.

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 02 Mar '09

02 Mar '09

Howard, Thank you for your great knowledge in the OpenLDAP internals. I will also give a try and check but looks like you could pinpoint the issue and solve it. I would like to say this will greatly allow many users to control better memory usage and then have DBs bigger than available memory, what can be very common nowadays. I normally will not have 2 process searching DB simultaneously, this was just a test. In this way performance, in average, will be reasonable. Thanks a lot! Rodrigo. --- On Mon, 3/2/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)openldap.org > Date: Monday, March 2, 2009, 4:36 AM > Rodrigo Costa wrote: > > Howard, > > > > One more comment. If you take a longer time between > the ldapsearches the > issue doesn't appear sometimes. > > > > So you need to start the first ldapsearh and like 15 > seconds later start > > the > second one. With this scenario the problem will for sure > appear. > > I was finally able to reproduce this issue, by running two > identical searches simultaneously on a server with more than > 2 CPU cores. Given any delay between the two search > invocation, the problem did not appear. > > This is now fixed in HEAD. Thanks for your help in > providing data for reproducing the issue. > > > In this way we will see large chunks of memory being > allocated and after > > it > stabilizes the query get stuck returning as the issue > before 16 records per > minute, or very slow and getting stuck all the time. > > I should point out - the memory use is stabilized now (as > it should be) but the search performance of a configuration > such as yours will be extremely poor due to the unavoidable > thrashing that such a query pattern exerts on the cache. > Setting a larger minfree can help reduce some of the > contention but it will still be much slower than normal. > > > Regards, > > > > Rodrigo. > > > -- -- 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 Pierangelo Masarati 02 Mar '09

02 Mar '09

> Full_Name: Marius Paulauskas > Version: 2.4.11 > OS: Solaris 10 (SPARC) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.201.141.149) Please retry with latest. p.

1 0

Re: (ITS#5982) man page for ldapexop
by Gavin Henry 02 Mar '09

02 Mar '09

Thanks for your contribution! Could you take a read of: http://www.openldap.org/devel/contributing.html#notice with an example of the format at the top of: ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 Thanks and always appreciated! Gavin.

1 0

ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC openldap 2.4.11
by Marius Paulauskas 02 Mar '09

02 Mar '09

Hello, I am trying to change a password for ldap entry using ldappasswd -vx -D "cn=root,dc=test,dc=com" -w foobarr "uid=mariusp,ou=people,dc=test,dc=com" and reply I get is: Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It works fine if it is CLEARTEXT, SHA and MD5. I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in testing meaning there is nothing special about its configuration all defaults. Database has two entries just to play with. Same error occurs if I use downloaded pre-compiled version from sunfreeware.com or compile it myself using gcc. Wondering if anyone experienced similar issue. Regards, /Marius

3 2

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 01 Mar '09

01 Mar '09

Rodrigo Costa wrote: > Howard, > > One more comment. If you take a longer time between the ldapsearches the issue doesn't appear sometimes. > > So you need to start the first ldapsearh and like 15 seconds later start > the second one. With this scenario the problem will for sure appear. I was finally able to reproduce this issue, by running two identical searches simultaneously on a server with more than 2 CPU cores. Given any delay between the two search invocation, the problem did not appear. This is now fixed in HEAD. Thanks for your help in providing data for reproducing the issue. > In this way we will see large chunks of memory being allocated and after > it stabilizes the query get stuck returning as the issue before 16 records per minute, or very slow and getting stuck all the time. I should point out - the memory use is stabilized now (as it should be) but the search performance of a configuration such as yours will be extremely poor due to the unavoidable thrashing that such a query pattern exerts on the cache. Setting a larger minfree can help reduce some of the contention but it will still be much slower than normal. > Regards, > > Rodrigo. -- -- 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#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 01 Mar '09

01 Mar '09

Full_Name: Marius Paulauskas Version: 2.4.11 OS: Solaris 10 (SPARC) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.201.141.149) I am trying to change a password for ldap entry using ldappasswd -vx -D "cn=root,dc=test,dc=com" -w foobarr "uid=mariusp,ou=people,dc=test,dc=com" and reply I get is: Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It works fine if it is CLEARTEXT, SHA and MD5. I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in testing meaning there is nothing special about its configuration all defaults. Database has two entries just to play with. Same error occurs if I use downloaded pre-compiled version from sunfreeware.com or compile it myself using gcc.

1 0

Re: (ITS#5981) TLSVerifyClient try setting fails with GnuTLS
by hyc＠symas.com 01 Mar '09

01 Mar '09

peter(a)adpm.de wrote: > Full_Name: Peter Marschall > Version: 2.4.15 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch > Submission from: (NULL) (92.75.56.86) > > > Hi, > > when OpenLDAP 2.4.15 is compiled with GnuTLS, then setting > TLSVerifyClient Try > in slapd.conf makes TLS connections without certificates impossible. > > This is caused by incomplete decoding in tls_g.c > > The patch in ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch > fixes this issue together with a few other little cleanups: > - remove unused variables (less compiler warnings) > - use correct types (less compiler warnings) > - detect failed calls for activation/exiration functions to > avoid giving wrong information > > Please consider adding this patch to OpenLDAP Thanks for the patch, committed to HEAD. > > Regards > Peter > -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs