openldap-bugs February 2016

openldap-bugs@openldap.org

15 participants
45 discussions

Re: (ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined

by h.b.furuseth＠usit.uio.no

On 03/02/16 01:39, h.b.furuseth(a)usit.uio.no wrote: > This is still not fixed: The EILSEQ, and a new memleak. > I rewrote it in my branch "mdb/its7992". Untested. Oops, shouldn't have done some late-night code and forgotten to comment it. The important changes are: * "goto leave" - fixes a memleak on failure. * New error code for mdb_strerror(), since EILSEQ is an errno. The rest is just twiddling around: * Drop the always-unused size params to utf8_to_utf16(). * goto fail -- just cleanup, fewer exit points from function. * Looping adds an error check and saves a few bytes object code:-) * Move function inside Doxygen group 'internal'

7 years, 10 months

1
0
0 / 0

Re: (ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined

by h.b.furuseth＠usit.uio.no

This is still not fixed: The EILSEQ, and a new memleak. I rewrote it in my branch "mdb/its7992". Untested.

7 years, 10 months

1
0
0 / 0

(ITS#8367) Unable to authenticate to AD when OpenLDAP 2.4 is set up in SASL mode

by ralthuru＠yahoo.com

Full_Name: Ravi Version: OpenLDAP 2.4 OS: RedHat Linux 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.55.48.135) We have OpenLDAP 2.3 running on Linux. It is set up in SASL mode authenticating against multiple ADs. Everything works fine here. We recently installed a new instance of OpenLDAP 2.4 running on RedHat Linux 6. Then, we moved the slapd.conf and slapd-meta.conf file to the new instance, and created the required users. When we run testsaslauthd, we are successfully able to authenticate against the appropriate AD that the user is under. But we are not able to bind to the OpenLDAP by using the same credentials. I get a Invalid credentials err 49, which indcates either credentials are incorrect, which in this case its not, or the bind info is incorrect. testsaslauthd -u ravi@SONEPAR -p secret - WORKS ldapsearch -x -D uid=ravi,ou=People,ou=company,dc=inside,dc=devserver,dc=com -w secret results in: ldap_bind: Invalid credentials (49) I have searched across many forums, compared the set up on the OpenLDAP 2.3 and OpenLDAP 2.4 instances and cannot find any differences. Any suggestions on how to debug this is appreciated!

7 years, 10 months

1
0
0 / 0

(ITS#8303)

by nivanova＠symas.com

A new version of the patch with all fixes is uploaded as ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160130.patch

7 years, 10 months

1
0
0 / 0

(ITS#8303)

by nivanova＠symas.com

This is a multi-part message in MIME format. --------------010703030802080506060500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit A new version of the patch with all fixes is uploaded as ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160130.patch <ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch> --------------010703030802080506060500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> A new version of the patch with all fixes is uploaded as <br> <pre><a href="ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch">ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160130.patch</a></pre> </body> </html> --------------010703030802080506060500--

7 years, 10 months

1
0
0 / 0

← Newer
1
2
3
4
5
Older →

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2016