openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#5085) slapo-translucent has wrong Debug message
by ghenry＠OpenLDAP.org 10 Aug '07

10 Aug '07

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Inside: translucent_db_destroy Debug: Debug(LDAP_DEBUG_TRACE, "==> translucent_db_close\n", 0, 0, 0); Should be: Debug(LDAP_DEBUG_TRACE, "==> translucent_db_destroy\n", 0, 0, 0); Probably copy and paste error. Correcting. Gavin.

1 0

Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize '1.1' to describe an empty attribute set
by ando＠sys-net.it 10 Aug '07

10 Aug '07

> On Aug 6, 2007, at 6:43 AM, Pierangelo Masarati wrote: >> I believe there's something odd in pcache's current behavior. In >> fact, right now "proxyattrset 0" is already a valid directive, but >> it implies "proxyattrset 0 *", which means all attributes. >> Unfortunately, this seems to only work if no attribute is >> requested, while it fails if a "*" is explicitly requested. > > Ah, I was not aware of this behaviour! I've noticed it from the sources, I don't think it was noted anywhere. >> I've modified the propxycache code in HEAD so that a "1.1" can only >> explicitly appear in a list if it's the only string. An empty >> attribute set is no longer valid, to avoid confusion about the >> meaning of non-explicit attribute sets. A "*" or a "+" can >> explicitly appear in a proxyattrset statement, resulting in the >> expected behavior. Use both to indicate that all attributes are in >> the set. > > Let me confirm, that I should specify "proxyattrset 0 1.1" to match > an empty attribute list, and only an empty attribute list. Will a > '*' than match emptiness as well, or does it only match where there > is some attribute specified by the client? No: you need to specify proxyattrset <#idx> "*" in order to have either nothing or "*" return all attributes. In short, an empty attribute set and "*" are now recognized as equivalent. You need to specify proxyattrset <#idx> "1.1" in order to have searches requesting "1.1", namely no attributes, be cached. > I will work on this as soon as I am able to, although it seems this > won't be for a couple of weeks. I will be in touch. Thanks again > for your work and for your very timely response. Right now, I'm not planning to backport this fix to re23 because it seems to be an enhancement rather than a bugfix, and 2.4 __should be__ just 'round the corner. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by zep＠ni.enate.org 09 Aug '07

09 Aug '07

On Aug 6, 2007, at 6:43 AM, Pierangelo Masarati wrote: > I believe there's something odd in pcache's current behavior. In > fact, right now "proxyattrset 0" is already a valid directive, but > it implies "proxyattrset 0 *", which means all attributes. > Unfortunately, this seems to only work if no attribute is > requested, while it fails if a "*" is explicitly requested. Ah, I was not aware of this behaviour! > I've modified the propxycache code in HEAD so that a "1.1" can only > explicitly appear in a list if it's the only string. An empty > attribute set is no longer valid, to avoid confusion about the > meaning of non-explicit attribute sets. A "*" or a "+" can > explicitly appear in a proxyattrset statement, resulting in the > expected behavior. Use both to indicate that all attributes are in > the set. Let me confirm, that I should specify "proxyattrset 0 1.1" to match an empty attribute list, and only an empty attribute list. Will a '*' than match emptiness as well, or does it only match where there is some attribute specified by the client? > Please test. I will work on this as soon as I am able to, although it seems this won't be for a couple of weeks. I will be in touch. Thanks again for your work and for your very timely response. -Mike

1 0

ITS#4868
by ando＠sys-net.it 09 Aug '07

09 Aug '07

There remains an issue in back-sql: if a ';binary' attr is used in the filter, and the same attribute is requested with the ';binary' option, the latter is treated as a different attribute, and no value is returned because of sort of a malformed attribute inheritance test. For example, a search requesting 'userCertificate;binary' with a filter '(userCertificate=*)' would return no values for the userCertificate attribute, while if no ';binary' were used, userCertificate values would be returned. I'll commit a fix shortly. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5083) LDAP configuration problem
by quanah＠zimbra.com 09 Aug '07

09 Aug '07

--On Thursday, August 09, 2007 12:41 PM +0000 ranju(a)isl-bd.com wrote: > Full_Name: Mohammad nurul Huda > Version: 2.2.13-6.4E > OS: RedHat ES 4.0 Update 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.49.33.141) > > > When we run the following command in the LDAP configuration time it shows > the following error in the time of running below command: Please use openldap-software(a)openldap.org for software usage questions (i.e., I see no bug here). I will also note that OpenLDAP 2.2 is extremely old. I advise upgrading to a current, supported release. The current release is OpenLDAP 2.3.37. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5080) LDAP setup
by quanah＠zimbra.com 09 Aug '07

09 Aug '07

--On Thursday, August 09, 2007 4:29 AM +0000 srinibashudayasingh(a)gmail.com wrote: > Full_Name: srinibash udayasingh > Version: 2.3.7 > OS: red heart linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.14.7.138) This is not a bug. Please use openldap-software(a)openldap.org for usage questions. Please upgrade to a recent release before doing so (current release is 2.3.37). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5084) back-ldap does not return if remote server is unreachable
by ando＠sys-net.it 09 Aug '07

09 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando This is HEAD only as of today (re23 as of today works as expected). To reproduce: configure slapd with an ldap database pointing nowhere. p.

1 0

(ITS#5083) LDAP configuration problem
by ranju＠isl-bd.com 09 Aug '07

09 Aug '07

Full_Name: Mohammad nurul Huda Version: 2.2.13-6.4E OS: RedHat ES 4.0 Update 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.49.33.141) When we run the following command in the LDAP configuration time it shows the following error in the time of running below command: # ldapadd -x -D "cn=Manager,dc=<Domain>,dc=com" -W -f /etc/openldap/domain.com.ldif #Enter LDAP passwd: After puuting the ldap password it shows the following error message ldap_bind invalid credential (49) Another issue when i am seeing the log messages it shows the following error sql_select option missing auxprobfunce error no mechanisam available.

1 0

ITS#5082
by ando＠sys-net.it 09 Aug '07

09 Aug '07

See also discussion in thread <http://www.openldap.org/lists/openldap-software/200708/msg00063.html> 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5082) olcPasswordHash: Scheme not available
by mahashmi＠gmail.com 09 Aug '07

09 Aug '07

Full_Name: Mustafa A. Hashmi Version: 2.3.30 OS: Debian Etch (4.0) URL: Submission from: (NULL) (202.5.145.13) When slapd is initialized to read configuration via cn=config (-F /path/to/slapd.d), configuration directives are read before modules are loaded. This can result in slapd exiting when a configuration option, provided by a specific module, is found before the module is loaded. As an example: the directive password-hash {K5KEY} results in slapd existing with the following message: olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({K5KEY}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found The smbk5pwd module is loaded at a later stage during the initialization process. Please note: If cn=config.ldif is edited and the option removed, slapd will start normally and allow the option to be added at runtime.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs