openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7159) Fix a crash in back-sql
by timo.teras＠iki.fi 08 Feb '12

08 Feb '12

Full_Name: Timo Teräs Version: 2.4.28 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.235.194) The back-sql crashes on startup with following backtrace: #0 0x0000045655d11efc in config_generic_wrapper () #1 0x0000045655d1187e in read_config_file () #2 0x0000045655d08fb6 in read_config () #3 0x0000045655cffc15 in main () This is because the be_cf_ocs is not initialized properly.

1 0

(ITS#7158) Fix a crash in back-sql
by timo.teras＠iki.fi 08 Feb '12

08 Feb '12

1 0

Re: (ITS#7157) UTF-8 support for "mail" attribute
by quanah＠zimbra.com 07 Feb '12

07 Feb '12

--On Tuesday, February 07, 2012 9:03 PM +0000 alfiej(a)opera.com wrote: > Full_Name: Alfie John > Version: 2.4.23 > OS: Debian Squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.245.36.226) > > > When searching for Chinese names in the "to:" field under Thunderbird, I > see asserted_value_validate_normalize() not returning LDAP_SUCCESS in > filter.c. This is because the "mail" attribute in core.schema is of type > "IA5 String" but the Chinese name falls outside the character set. > > The work around I have is to modify the "mail" attributetype in the > core.schema from: > > attributetype ( 0.9.2342.19200300.100.1.3 > NAME ( 'mail' 'rfc822Mailbox' ) > DESC 'RFC1274: RFC822 Mailbox' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > > to: > > attributetype ( 0.9.2342.19200300.100.1.3 > NAME ( 'mail' 'rfc822Mailbox' ) > DESC 'RFC1274: RFC822 Mailbox' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > Dieter Kl?nter pointed out on the openldap-technical mailing list that > this breaks RFC-5322. However Charles T. Brooks suggests: > > Non-english character sets are going to become part of > hostnames and DNS. That's inevitable. > > Mail addresses are based on DNS hostnames. > > Ergo, mail attributes will one day need to support all possible > characters. > > Given that, I think the above changes to core.schema seem worthwhile. I would say then, that the proper place to bring this up would be with the IETF. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7157) UTF-8 support for "mail" attribute
by alfiej＠opera.com 07 Feb '12

07 Feb '12

Full_Name: Alfie John Version: 2.4.23 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.245.36.226) When searching for Chinese names in the "to:" field under Thunderbird, I see asserted_value_validate_normalize() not returning LDAP_SUCCESS in filter.c. This is because the "mail" attribute in core.schema is of type "IA5 String" but the Chinese name falls outside the character set. The work around I have is to modify the "mail" attributetype in the core.schema from: attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) to: attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) DESC 'RFC1274: RFC822 Mailbox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) Dieter Klünter pointed out on the openldap-technical mailing list that this breaks RFC-5322. However Charles T. Brooks suggests: Non-english character sets are going to become part of hostnames and DNS. That's inevitable. Mail addresses are based on DNS hostnames. Ergo, mail attributes will one day need to support all possible characters. Given that, I think the above changes to core.schema seem worthwhile.

1 0

Re: (ITS#7156) definement missing in ldapsearch.c
by h.b.furuseth＠usit.uio.no 07 Feb '12

07 Feb '12

On Tue, 7 Feb 2012 12:19:04 GMT, Kick.Tobias(a)web.de wrote: > It seems that in ldapsearch.c a ifdef-statement for HAVE_SYS_TIME_H > is missing like this: > > #ifdef HAVE_SYS_TIME_H > #include <sys/time.h> > #endif Fixed in master: Added #include <ac/time.h> which does the above. Please test. -- Hallvard

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

Raphaël Ouazana-Sustowski wrote: > On Tue, 07 Feb 2012 14:36:22 +0100, Michael Ströder wrote: >> Raphaël Ouazana-Sustowski wrote: >>> Wouldn't it be possible to have a more generic solution, eg: while each >>> configuration change, OpenLDAP tests that configuration is still valid. >> >> While checking the configuration data itself seems feasible it does >> not scale well to check all entries whether they still contain a >> certain schema element. > > Again I was talking about a more generic case. ??? > For the specific case of schema modification, I don't think that OpenLDAP > doesn't start if some entries are missing some schema elements. Schema and all entries have to be consistent. Periodically checking with slapschema whether everything's still alright is a good idea. > My point is only that OpenLDAP should not bring the administrator to > a situation where he cannot restart the service. Nothing prevents an admin to do rm -rf /var/openldap/databases so to some degree an admin has to know what he does. Ciao, Michael.

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

Raphaël Ouazana-Sustowski wrote: > Wouldn't it be possible to have a more generic solution, eg: while each > configuration change, OpenLDAP tests that configuration is still valid. While checking the configuration data itself seems feasible it does not scale well to check all entries whether they still contain a certain schema element. Also if you use slapo-accesslog and it contains removed attributes in attributes redMod or reqOld you cannot fully restore the accesslog DB with slapadd. So using OBSOLETE is best practice. Experimental things you do in your test environment without asking for support is completely up to you. Ciao, Michael.

1 0

Re: (ITS#7153) OpenLDAP doesn't start after some configuration modifications
by michael＠stroeder.com 07 Feb '12

07 Feb '12

raphael.ouazana(a)linagora.com wrote: > This is a little bit like shooting himself in the foot: > a/ Create a new attribute with back-config > b/ Create a second new attribute which inherits from the first one with > back-config > c/ Remove the first attribute with back-config > d/ OpenLDAP does not complain. But when you restart the server, you get an error > message. It boils down to that back-config should not allow to remove schema elements which are somewhere used. In this context "used" means 1. referenced in another schema element or 2. used in an entry in one of the database backends. While 1. could be easily checked by slapd thinking about 2. leads to the conclusion that schema elements should not be removable at all. There's a possibility to mark schema elements as OBSOLETE. This is what I consider best practice. Also it still keeps the old OID reserved. (My web2ldap displays OBSOLETE schema elements as struck out in the schema viewer so one can easily notice whether there are OBSOLETE attribute types referenced e.g. in an active object class.) Ciao, Michael.

1 0

(ITS#7156) definement missing in ldapsearch.c
by Kick.Tobias＠web.de 07 Feb '12

07 Feb '12

Full_Name: Tobias Kick Version: 2.4.28 OS: MinGW URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.16.0.17) When configured in portable.h #define HAVE_SYS_TIME_H 1 the compiler brings the error: make[2]: Entering directory `/mingw64/tmp/openldap-2.4.28/clients/tools' ../../build/mkversion -v "2.4.28" -s ldapsearch > ldsversion.c gcc -g -O2 -I../../include -I../../include -c -o ldapsearch.o ldapsearch.c ldapsearch.c: In function 'dosearch': ldapsearch.c:1379:17: error: storage size of 'tv' isn't known ldapsearch.c:1380:17: error: storage size of 'tv_timelimit' isn't known make[2]: *** [ldapsearch.o] Error 1 make[2]: Leaving directory `/mingw64/tmp/openldap-2.4.28/clients/tools' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/mingw64/tmp/openldap-2.4.28/clients' make: *** [all-common] Error 1 It seems that in ldapsearch.c a ifdef-statement for HAVE_SYS_TIME_H is missing like this: #ifdef HAVE_SYS_TIME_H #include <sys/time.h> #endif

1 0

(ITS#7153) OpenLDAP doesn't start after some configuration modifications
by raphael.ouazana＠linagora.com 07 Feb '12

07 Feb '12

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) Hi, This is a little bit like shooting himself in the foot: a/ Create a new attribute with back-config b/ Create a second new attribute which inherits from the first one with back-config c/ Remove the first attribute with back-config d/ OpenLDAP does not complain. But when you restart the server, you get an error message. More problematically, you cannot modify the configuration anymore, because slapcating the configuration to edit it gives you the same error message: $ sbin/slapcat -F etc/openldap/slapd.d -n0 olcAttributeTypes: value #0 olcAttributeTypes: AttributeType not found: "xxx" config error processing cn={22}yyy,cn=schema,cn=config: olcAttributeTypes: AttributeType not found: "xxx" slapcat: bad configuration directory!

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