openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(ITS#7447) backsql and german umlaute
by metzdorf＠geograt.de 20 Nov '12

20 Nov '12

Full_Name: Herbert Metzdorf Version: 2.4.30 OS: Windows 7 / 2008 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.138.76.52) I am using thunderbird to query the openldap with the sql backend. Queries with german umlaut's give no result because of wrong lower/uppercase conversion. Look at the following log snippets: 50ab7cdb ==> limits_get: conn=1008 op=1 self="[anonymous]" this="ou=adressen,dc=geograt,dc=de" 50ab7cdb ==>backsql_search(): base="ou=adressen,dc=geograt,dc=de", filter="(|(?mail=*searchäoöuü*)(cn=*searchäoöuü*)(givenName=*searchäoöuü*)(sn=*searchäoöuü*))", scope=2,50ab7cdb deref=0, attrsonly=0, attributes to load: custom list 50ab7cdb ==>backsql_get_db_conn() ... 50ab7cdb <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,ldap_persons.sysid,'inetOrgPerson' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ldap_persons WHERE ldap_persons.sysid=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE CONCAT('%',UPPER(?)) AND (1=0 OR (UPPER(vorname||' '||nachname) LIKE '%SEARCHäOöUü%') OR (UPPER(vorname) LIKE '%SEARCHäOöUü%') OR (UPPER(nachname) LIKE '%SEARCHäOöUü%')) The search expression in converted to uppercase but this fails for the umlaut's. Is there a parameter to configure this behavior, or do you know a workaround? Thanks for your help Herbert

1 0

Re: (ITS#7446) slapadd OBSOLETE object class fails
by michael＠stroeder.com 19 Nov '12

19 Nov '12

masarati(a)aero.polimi.it wrote: > Maybe "manage" should be passed to > slap_tool_entry_check(), and write tools (slapadd, slapmodify) could have > an explicit '-o manage' option to enable handling of these cases. I'd regard slapadd to be in kind of a manage mode by default. E.g. it does not check constraints. And as said OBSOLETE attribute types are already accepted. Ciao, Michael.

1 0

Re: (ITS#7446) slapadd OBSOLETE object class fails
by masarati＠aero.polimi.it 19 Nov '12

19 Nov '12

> Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (79.227.170.198) > > > Importing an LDIF file with slapadd which contains entries with an object > class > marked as OBSOLETE in the schema fails. > > Importing entries with OBSOLETE attribute types seems to work just fine. > > If object classes are marked as OBSOLETE it's clear that it should be > impossible > to add new entries via LDAP based on such an object class. But it should > still > be possible to restore old entries from backup. Currently, slap_tool_entry_check() sets "manage" to 0 when calling entry_schema_check(); setting it to !0 would allow loading of OBSOLETE objectClasses. Maybe "manage" should be passed to slap_tool_entry_check(), and write tools (slapadd, slapmodify) could have an explicit '-o manage' option to enable handling of these cases. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7446) slapadd OBSOLETE object class fails
by michael＠stroeder.com 19 Nov '12

19 Nov '12

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (79.227.170.198) Importing an LDIF file with slapadd which contains entries with an object class marked as OBSOLETE in the schema fails. Importing entries with OBSOLETE attribute types seems to work just fine. If object classes are marked as OBSOLETE it's clear that it should be impossible to add new entries via LDAP based on such an object class. But it should still be possible to restore old entries from backup.

1 0

(ITS#7445) slapo-deref: deref control should only be register when actually enabled
by rhafer＠suse.de 19 Nov '12

19 Nov '12

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.81.246) This is similar to ITS#6647 (which was about sssvlv). Support for the deref control should only be advertised in rootDSE when at least one instance of the deref overlay is present. Patch is on the way.

1 0

(ITS#7444) Check the return value of ldap_pvt_thread_set_concurrency
by tixu＠cs.ucsd.edu 16 Nov '12

16 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, Still the verbosity idea. In the current version of slapd, when handling users' "concurrency" setting, slapd does not check the return value of "ldap_pvt_thread_set_concurrency" (essentially the return value of "pthread_setconcurrency") to see whether the setting is successful or not. So when the user setting is inappropriate (i.e., too big), slapd says nothing. But users have no way to be aware of such configuration failure. I suggest to check and notify users in this case. Here's the patch: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:52:37.211421828 -0800 @@ -1530,7 +1530,14 @@ break; case CFG_CONCUR: - ldap_pvt_thread_set_concurrency(c->value_int); + + if(ldap_pvt_thread_set_concurrency(c->value_int) != 0) { + snprintf( c->cr_msg, sizeof( c->cr_msg ), + "concurrency=%d is not valid; using the default setting", + c->value_int ); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0 ); + + } break; case CFG_THREADS:

1 0

(ITS#7443) Data range of index_intlen
by tixu＠cs.ucsd.edu 16 Nov '12

16 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, I suggest to make the verbosity upon changing users' configuration settings, especially some of the configuration specifications are not written in the manpage. It's too strong to assume that all the users carefully read the source code. This can save users' time to diagnose why slapd does not behave as their expectation. This ITS is for the "index_intlen" directive. ---------- What the manpage says ---------- index_intlen <integer> Specify the key length for ordered integer indices. The most significant bytes of the binary integer will be used for index keys. The default value is 4, which provides exact indexing for 31 bit values. A floating point representation is used to index too large values. ------------------------------------------------------ Actually, 4 is not only the default value but also the minimum value. From the source code, I knew the index_intlen is with the data range [4, 255]. Any out-of-range value will be converted to the boundaries without notifying users. Here's the patch I proposed: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:10:40.111362005 -0800 @@ -1754,10 +1754,16 @@ break; case CFG_IX_INTLEN: - if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) + if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d smaller than minimum value %d --> auto convert to the minimum.", c->value_int, SLAP_INDEX_INTLEN_DEFAULT); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = SLAP_INDEX_INTLEN_DEFAULT; - else if ( c->value_int > 255 ) + } + else if ( c->value_int > 255 ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d larger than maximum value 255 --> auto convert to the maximum.", c->value_int); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = 255; + } index_intlen = c->value_int; index_intlen_strlen = SLAP_INDEX_INTLEN_STRLEN( index_intlen );

1 0

(ITS#7442) Data range of index_intlen
by tixu＠cs.ucsd.edu 16 Nov '12

16 Nov '12

1 0

(ITS#7441) cn=config filters ignore {number}
by h.b.furuseth＠usit.uio.no 16 Nov '12

16 Nov '12

Full_Name: Hallvard B Furuseth Version: 2.4.33 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard cn=config ignores the {number} prefix in filters: "(olcDatabase={2}hdb)" -> matches all HDB databases "(olcdatabase={2})" -> none ldapcompare does the opposite: "olcdatabase:{2}hdb" -> TRUE (at DN olcdatabase={2}hdb,cn=config) "olcdatabase:{2} -> FALSE "olcdatabase:hdb" -> FALSE

1 0

Re: (ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 16 Nov '12

16 Nov '12

I just uploaded a slightly updated patch to: ftp://ftp.openldap.org/incoming/rhafer-20121116-Use-non-blocking-IO-during-… The code is now only enabled when LDAP_USE_NON_BLOCKING_TLS is defined. Mainly because NSS and GNUTLS show some issues with not-blocking sockets. See my mail on -devel. Additionally the non-blocking handshake is only done if LDAP_OPT_TIMEOUT is set. Previously I used LDAP_OPT_NETWORK_TIMEOUT but IMO LDAP_OPT_TIMEOUT is the better choice. On Thu, Nov 01, 2012 at 05:36:54PM +0000, rhafer(a)suse.de wrote: > I've just uploaded: > > ftp://ftp.openldap.org/incoming/rhafer-Use-non-blocking-IO-during-SSL-Hands… > [..] Ralf

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