October 2018 - openldap-bugs

Re: (ITS#8930) Setting source interface of LDAP session the ldap client uses to connect to server

by ryan＠nardis.ca

Hello Adrian, I think someone is already working on this feature, please see: ITS#8847 https://openldap.org/its?findid=8847 ITS#8654 https://openldap.org/its?findid=8654 http://www.openldap.org/lists/openldap-devel/201810/msg00008.html

4 years, 5 months

1
0
0 / 0

(ITS#8930) Setting source interface of LDAP session the ldap client uses to connect to server

by ac1471＠att.com

Full_Name: adrian cepleanu Version: 0.5.3 OS: Ubuntu 16.04LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.160.130.91) In a system with multiple interfaces software initiating network connections may choose the source interface (or IP address) that the request is initiated from. I am looking for such a setting in the ldap-auth-client for Linux but cannot find it. Perhaps it doesn't exist. If the latter please advise if there is a way to submit a feature request. thanks

4 years, 5 months

1
0
0 / 0

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message

by michael＠stroeder.com

On 10/26/18 4:21 PM, Ondřej Kuzník wrote: > Yes, but `key` had already been freed a few lines earlier and using > o_tmpalloc reliably exposes the issue where ch_malloc just masks it. Ouch! > This is now fixed in master. Thanks. Everything now works like a charm also with RE24. Ciao, Michael.

4 years, 5 months

1
0
0 / 0

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message

by ondra＠mistotebe.net

On Fri, Oct 26, 2018 at 08:12:13AM +0000, michael(a)stroeder.com wrote: > On 10/26/18 4:01 AM, Quanah Gibson-Mount wrote: >> This patch has been applied to OpenLDAP HEAD with a correction to the >> memory allocation functions. I'll discuss with Howard about whether or >> not to add it to 2.4.47. > > With your memory allocation correction, op->o_tmpalloc() and > op->o_tmpfree(), this does not work as expected with 2.4.x. It does > *not* return the filter used for uniqueness check. > (I did not test master yet.) > > [...] > Result with patch backported from git master using op->o_tmpalloc() and > op->o_tmpfree(): > > non-unique attributes found with non-unique attribute > ^^^^^^^^^^^^^^^^^^^^ > Seems to repeat parts of the buffer? > > In my original patch the use of ch_malloc() and ch_free() was simply > copied from other overlay code. There are many occurences of ch_malloc() > and ch_free() throughout the whole code. Yes, but `key` had already been freed a few lines earlier and using o_tmpalloc reliably exposes the issue where ch_malloc just masks it. This is now fixed in master. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

4 years, 5 months

1
0
0 / 0

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message

by michael＠stroeder.com

On 10/26/18 4:01 AM, Quanah Gibson-Mount wrote: > --On Monday, July 30, 2018 6:58 PM +0000 michael(a)stroeder.com wrote: > >> Can someone correct the subject line of the ticket? >> >> Should of course mention slapo-unique instead of slapo-constraint. > > This patch has been applied to OpenLDAP HEAD with a correction to the > memory allocation functions. I'll discuss with Howard about whether or > not to add it to 2.4.47. With your memory allocation correction, op->o_tmpalloc() and op->o_tmpfree(), this does not work as expected with 2.4.x. It does *not* return the filter used for uniqueness check. (I did not test master yet.) Example for expected diagnostic message (with my original patch applied to 2.4.46): non-unique attributes found with (|(gidNumber=30041)) Result with patch backported from git master using op->o_tmpalloc() and op->o_tmpfree(): non-unique attributes found with non-unique attribute ^^^^^^^^^^^^^^^^^^^^ Seems to repeat parts of the buffer? In my original patch the use of ch_malloc() and ch_free() was simply copied from other overlay code. There are many occurences of ch_malloc() and ch_free() throughout the whole code. Does op->o_tmpalloc() and op->o_tmpfree() work correctly in RE24 branch? Ciao, Michael.

4 years, 5 months

1
0
0 / 0

Re: (ITS#8925) Please remove the entry for mirror.switch.ch from the Download page

by quanah＠symas.com

--On Thursday, October 18, 2018 10:23 PM -0400 Thomas Lenggenhager <thomas.lenggenhager(a)switch.ch> wrote: > Hello Quanah > > Many thanks for your action and answer. In the mean time I noticed that > in this file > ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS > the mirrors are still listed. Could you please update that as well? Thanks, This is now fixed as well. :) Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 5 months

1
0
0 / 0

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message

by quanah＠symas.com

--On Monday, July 30, 2018 6:58 PM +0000 michael(a)stroeder.com wrote: > Can someone correct the subject line of the ticket? > > Should of course mention slapo-unique instead of slapo-constraint. This patch has been applied to OpenLDAP HEAD with a correction to the memory allocation functions. I'll discuss with Howard about whether or not to add it to 2.4.47. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 5 months

1
0
0 / 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string

by douglas.royds＠taitradio.com

URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch This updated patch also sets the date and time strings to the SOURCE_DATE_EPOCH. The WHOWHERE string will now be set to simply "openldap" in the case that a SOURCE_DATE_EPOCH is set. Tait Communications Ltd hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

4 years, 5 months

1
0
0 / 0

Re: (ITS#8929) syncrepl retry parameter ignored

by openldap-its＠plumbe.de

Am 2018-10-24 15:57, schrieb Quanah Gibson-Mount: > --On Wednesday, October 24, 2018 10:21 AM +0000 openldap-its(a)plumbe.de > wrote: > >> Full_Name: Markus Joosten >> Version: 2.4.44-15.el7 >> OS: CentOS 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (62.8.242.42) >> >> >> Hello, >> >> I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config >> backend. >> My main database dc=example,dc=com is replicated using syncrepl, >> however >> the retry parameter is completely ignored. > > Provide your full configuration minus passwords, as syncrepl is used > extensively in the test suite and does not exhibit this behavior. > > --Quanah > I found my error. Turns out I had a runaway double-quote on the type= parameter like this: type=refreshAndPersist" Funny enough, the only message in my log was regarding the missing retry parameter. The replication itself was created successfully and was also working as expected, only the retry parameter was missing. Regards, Markus

4 years, 5 months

1
0
0 / 0

Re: (ITS#8929) syncrepl retry parameter ignored

by quanah＠symas.com

--On Wednesday, October 24, 2018 10:21 AM +0000 openldap-its(a)plumbe.de wrote: > Full_Name: Markus Joosten > Version: 2.4.44-15.el7 > OS: CentOS 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.8.242.42) > > > Hello, > > I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config backend. > My main database dc=example,dc=com is replicated using syncrepl, however > the retry parameter is completely ignored. Provide your full configuration minus passwords, as syncrepl is used extensively in the test suite and does not exhibit this behavior. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 5 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2018