openldap-bugs

openldap-bugs@openldap.org

1 participants
20895 discussions

(ITS#4748) Implement [NETWORK_]TIMEOUT options for ldap.conf
by tiamat＠komi.mts.ru 13 Nov '06

13 Nov '06

Full_Name: Alex Deiter Version: 2.3.29 OS: Solaris 9 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.224) Hi, Please review my patch which implement two new ldap.conf options: TIMEOUT and NETWORK_TIMEOUT. These options are very useful to the wide list of applications, which do not operate these parameters directly: samba, isc dhcp/bind, sendmail and many other things. I offer two variants: with use ldap_set_option: ftp://ftp.openldap.org/incoming/alex-deiter-061112.patch and without it: ftp://ftp.openldap.org/incoming/alex-deiter-061113.patch Thanks a lot!

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by Kurt＠OpenLDAP.org 12 Nov '06

12 Nov '06

At 09:26 PM 11/12/2006, temp1(a)ips.gov.au wrote: >Full_Name: IT Manager 2 >Version: 2.3 & 2.4 >OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 >URL: >Submission from: (NULL) (220.233.132.66) > > >Src ./servers/slapd/schema_init.c >Function nisNetgroupTripleValidate > >Fails validate of NIS Netgroup triplet when an underscore is used in a username, >hostname or domainname. I believe this is the intended behavior. >Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". RFC 2307 is more restrictive. >suggest change line > } else if ( !AD_CHAR( *p ) ) { > to > } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { > >Regards >IT Manager 2

1 0

(ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by temp1＠ips.gov.au 12 Nov '06

12 Nov '06

Full_Name: IT Manager 2 Version: 2.3 & 2.4 OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 URL: Submission from: (NULL) (220.233.132.66) Src ./servers/slapd/schema_init.c Function nisNetgroupTripleValidate Fails validate of NIS Netgroup triplet when an underscore is used in a username, hostname or domainname. Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". suggest change line } else if ( !AD_CHAR( *p ) ) { to } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { Regards IT Manager 2

1 0

(ITS#4746) memory leak in syncrepl consumer
by hyc＠OpenLDAP.org 12 Nov '06

12 Nov '06

Full_Name: Howard Chu Version: RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc syncrepl_updateCookie leaks the CSN that it queues up. Detected with valgrind.

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

Pierangelo Masarati wrote: > Howard Chu wrote: >> OK. And we have usually used DEBUG_ANY for fatal messages of this >> type. The point I'm making now is that config errors are no longer >> always fatal; it depends on whether we're starting up or already running. > But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools > now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages > would let them always pop up with tools __and__ run-time; run-time it > shouldn't be a big deal, it's just another informative message in the > logs; with the tools it should make the difference. I have no > preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by > default in tools, or OR config messages with LDAP_DEBUG_NONE. OK, that makes sense. Perhaps we should define LDAP_DEBUG_ERROR (or _FATAL) as an alias of LDAP_DEBUG_NONE. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 11 Nov '06

11 Nov '06

Howard Chu wrote: > OK. And we have usually used DEBUG_ANY for fatal messages of this > type. The point I'm making now is that config errors are no longer > always fatal; it depends on whether we're starting up or already running. But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages would let them always pop up with tools __and__ run-time; run-time it shouldn't be a big deal, it's just another informative message in the logs; with the tools it should make the difference. I have no preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by default in tools, or OR config messages with LDAP_DEBUG_NONE. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Another possibility would be to always enable LDAP_DEBUG_CONFIG for the >> tools. The only reason I suggest this is because I would prefer that >> runtime configuration errors are only logged when specifically >> requested, not at DEBUG_ANY. Since the error messages are already >> returnes to the client in the protocol, it's not always necessary to log >> them separately. >> > The point is that I'd like to separate informative messages about > configuration (LDAP_DEBUG_CONFIG) from __the__ message that described > why slaptest failed (or slapd refuses to start). Right now, either you > get all (which is annoying) or none (which is frustrating). Apparently, > unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and > OR it to all messages followed by "return ARG_BAD_CONF;", we need > another LDAP_DEBUG_*. OK. And we have usually used DEBUG_ANY for fatal messages of this type. The point I'm making now is that config errors are no longer always fatal; it depends on whether we're starting up or already running. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 11 Nov '06

11 Nov '06

hyc(a)symas.com wrote: > Another possibility would be to always enable LDAP_DEBUG_CONFIG for the > tools. The only reason I suggest this is because I would prefer that > runtime configuration errors are only logged when specifically > requested, not at DEBUG_ANY. Since the error messages are already > returnes to the client in the protocol, it's not always necessary to log > them separately. > The point is that I'd like to separate informative messages about configuration (LDAP_DEBUG_CONFIG) from __the__ message that described why slaptest failed (or slapd refuses to start). Right now, either you get all (which is annoying) or none (which is frustrating). Apparently, unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and OR it to all messages followed by "return ARG_BAD_CONF;", we need another LDAP_DEBUG_*. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> It seems that slapd stops without configuration error message if unknown >> attribute types are set for parameter unique_attributes (slapo-unique). It would >> be nice if a descriptive message is displayed (like in other cases). >> > I think this occurs if debug is set to "config" or "-1". However, it > would be more appropriate to log configuration errors that result in > failures at "any", so that whatever logging is set they show up. For > this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG > should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that > they show up when caught by tools with default logging (e.g. > slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. > I'd vote for the latter. Another possibility would be to always enable LDAP_DEBUG_CONFIG for the tools. The only reason I suggest this is because I would prefer that runtime configuration errors are only logged when specifically requested, not at DEBUG_ANY. Since the error messages are already returnes to the client in the protocol, it's not always necessary to log them separately. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

--On Saturday, November 11, 2006 9:10 PM +0000 hyc(a)symas.com wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.28 >> OS: Linux 2.6 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.66.155.86) >> >> >> When building OpenLDAP 2.3.28, I found that libslapi is full of undefined >> symbols. Is it not being linked correctly? >> > Do you actually have a slapi plugin that isn't working? There's no > evidence of a bug here. Most dynamic libraries that depend on other > objects are full of undefined symbols. Nope, I don't use slapi at all, other than to enable it to disable the broken acl cacheing in 2.3. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs