openldap-bugs

openldap-bugs@openldap.org

1 participants
21517 discussions

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

(ITS#5982) man page for ldapexop
by peter＠adpm.de 01 Mar '09

01 Mar '09

Full_Name: Peter Marschall Version: 2.4.15 OS: Linux URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301-ldapexop.1 Submission from: (NULL) (94.217.131.234) Hi, doing a little bug triaging for Debian, I noticed there is not man page for ldapexop. At ftp://ftp.openldap.org/incoming/Peter-Marschall-090301-ldapexop.1 you can find my first draft for it. Please adapt as you please and add it to the next release. Regards Peter

1 0

(ITS#5981) TLSVerifyClient try setting fails with GnuTLS
by peter＠adpm.de 01 Mar '09

01 Mar '09

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 Regards Peter

1 0

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

28 Feb '09

ando(a)sys-net.it wrote: > Probably a side-effect of fixing ITS#5853: This seems to be unrelated from ITS#5853, actually. 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. 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#5980) libldap referral chasing now returns referral (10) and matchedDN
by ando＠sys-net.it 28 Feb '09

28 Feb '09

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? p.

1 0

Re: (ITS#5979) ppolicy & access log crashes server
by hyc＠symas.com 27 Feb '09

27 Feb '09

Peter Giesin wrote: > Since the database was corrupted (we were getting a Segmentation Fault > when restarting the server) we simply removed the database. I guess if > we recovered the database instead we would have gotten the same results. Recovery is preformed automatically on startup. Wiping the DB and starting over isn't necessary; if the disks holding the transaction logs don't burn up/fail then corruption simply isn't an issue. > Thanks for the quick fix. You're welcome... > > Pete > > On Fri, Feb 27, 2009 at 10:44 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > pgiesin(a)gmail.com <mailto:pgiesin@gmail.com> wrote: > > Full_Name: Peter Giesin > Version: 2.4.13 > OS: Red Hat 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.187.213.234) > > > Enabled both accesslog and ppolicy overlays (configurations > included below). All > attempts to bind with an invalid password causes the server to > crash and > database to be corrupted. If you disable either of the overlays > or just the > "logold" setting of the accesslog the behavior is no longer noticed. > > > Interesting, for me only the first attempt crashed; after restarting > the same attempt just failed normally. Anyway, thanks for the > report, this is now fixed in HEAD. -- -- 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs