openldap-bugs December 2007

openldap-bugs@openldap.org

45 participants
166 discussions

(ITS#5256) encoding of guide.sdf
by dieter＠dkluenter.de 02 Dec '07

02 Dec '07

Full_Name: Dieter Kluenter Version: REL_ENG_2_4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.202.173) Hi, the guide *.sdf files are UTF-8 encoded, but the online availeable HTML files seem to be iso8859-1 encoded, which leeds to display errors, an example is part 9.2.1. ... proxy’s efficiency ... -Dieter

1 0

Re: (ITS#5254) core dump on Solaris 9 when with threads
by hyc＠symas.com 01 Dec '07

01 Dec '07

mills(a)cc.umanitoba.ca wrote: > Full_Name: Gary Mills > Version: openldap-2.3.38 > OS: Solaris 9 SPARC > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.78.105.29) back-ldbm is deprecated and has been deleted from OpenLDAP 2.4. It is known to have many problems. Berkeley DB 3.1.17 is ancient, and also known to have many bugs. Don't use ldbm, and use a recent version of BerkeleyDB. Nobody is going to spend any time investigating these broken code bases. > > > Here's how openldap-2.3.38 was built: > > PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH > > env CC=cc \ > INSTALL=/usr/ucb/install \ > CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix > -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ > LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix > -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ > ./configure \ > --disable-proctitle \ > --enable-crypt \ > --disable-bdb \ > --disable-hdb \ > --enable-ldbm \ > --enable-perl > > In simple tests with an ldbm database, it works correctly. With many clients, > it > dump core hundreds of times a day. The dumps vary, but suggest a memory > management > problem. Here are two: -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5254) core dump on Solaris 9 when with threads
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

I neglected to mention that compiling Openldap without threads resulted in a perfectly stable server. Threads seem to be handled incorrectly, somehow. -- -Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

1 0

(ITS#5255) Outlook 2003 says: The search could not be completed.
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) Here's how Openldap was compiled: PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH env CC=cc \ INSTALL=/usr/ucb/install \ CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ ./configure \ --disable-proctitle \ --enable-crypt \ --disable-bdb \ --disable-hdb \ --enable-ldbm \ --without-threads \ --enable-perl When using an ldbm database, Microsoft Outlook 2003 clients report this error when they attempt a search: The search could not be completed. MAPI_E_CALL_FAILED The LDAP logs show this message: critical control unavailable in context This happens because Openldap advertizes the pagedResults control, even though the ldbm backend does not support it. When OL 2003 obtains the list of available controls, the LDAP server does not know which back end it will use. When OL 2003 does a query, it goes to the ldbm back end which does not support that control. OL 2003 marks it critical, making the situation impossible. In this situation, I'm using only the ldbm back end, so I removed the pagedResults control in servers/slapd/controls.c to fix the problem. Here's my patch: *** controls.Oc Tue Jan 2 15:43:55 2007 --- controls.c Thu Nov 29 19:53:12 2007 *************** *** 123,132 **** --- 123,134 ---- SLAP_CTRL_GLOBAL|SLAP_CTRL_SEARCH, NULL, parseValuesReturnFilter, LDAP_SLIST_ENTRY_INITIALIZER(next) }, #endif + #ifdef VANILLA { LDAP_CONTROL_PAGEDRESULTS, (int)offsetof(struct slap_control_ids, sc_pagedResults), SLAP_CTRL_SEARCH, NULL, parsePagedResults, LDAP_SLIST_ENTRY_INITIALIZER(next) }, + #endif #ifdef LDAP_DEVEL { LDAP_CONTROL_SORTREQUEST, (int)offsetof(struct slap_control_ids, sc_sortedResults), Adding an access list to the config file did not work.

1 0

(ITS#5254) core dump on Solaris 9 when with threads
by mills＠cc.umanitoba.ca 01 Dec '07

01 Dec '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 SPARC URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) Here's how openldap-2.3.38 was built: PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH env CC=cc \ INSTALL=/usr/ucb/install \ CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \ LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \ ./configure \ --disable-proctitle \ --enable-crypt \ --disable-bdb \ --disable-hdb \ --enable-ldbm \ --enable-perl In simple tests with an ldbm database, it works correctly. With many clients, it dump core hundreds of times a day. The dumps vary, but suggest a memory management problem. Here are two: # mdb /usr/local/libexec/slapd /var/core/core.slapd.3610 Loading modules: [ libc.so.1 libthread.so.1 ld.so.1 ] > ::status debugging core file of slapd (32-bit) from electra executable file: /opt/local/libexec/slapd initial argv: slapd threading model: multi-threaded status: process terminated by SIGSEGV (Segmentation Fault) > ::stack is_ad_subtype+0x4c(30000, 3b0120, 33abb0, 33a698, 181ae30, 15949a4) attrs_find+0x2c(181b458, 3b0120, 33a698, 400, 181ae30, 15949a4) 0x8cba4(3d0e08, 17d4e80, 15949c4, 3bd000, 0, fdbff725) test_filter+0x388(3d0e08, 17d4e80, 15949c4, 14baa8, ffffffe0, fdbff8b1) 0x8c808(3d0e08, 17d4e80, 15949c4, 7, ffffffe0, fdbff8f1) test_filter+0x784(3d0e08, 17d4e80, 15949d4, 2, 0, 0) ldbm_back_search+0x12d0(3d0e08, fdbffd50, 0, fdbff2a4, 0, fdbff9fd) fe_op_search+0x594(3d0e08, fdbffd50, 3d0efc, fdbffab0, 0, 0) do_search+0xf54(3d0e08, fdbffd50, fdbffd40, 0, 0, 0) 0x5bbf8(fdbffe14, 3d0e08, 0, 0, 0, 0) 0x153f5c(3aacb8, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0) # mdb /usr/local/libexec/slapd /var/core/core.slapd.25318 Loading modules: [ libc.so.1 libthread.so.1 ld.so.1 ] > ::status debugging core file of slapd (32-bit) from electra executable file: /opt/local/libexec/slapd initial argv: slapd threading model: multi-threaded status: process terminated by SIGSEGV (Segmentation Fault) > ::stack str2entry2+0xfec(40c010, 0, 2ee1bc, 7, ffffffe0, fe3ff8f1) id2entry_rw+0x484(3d0820, 1da9, 0, 2, 0, 0) ldbm_back_search+0xa14(3d0e08, fe3ffd50, 0, fe3ff2a4, 81010100, ff00) fe_op_search+0x594(3d0e08, fe3ffd50, 3d0efc, 14388f4, fe3ffab0, 1438e4c) do_search+0xf54(3d0e08, fe3ffd50, fe3ffd40, 0, 0, 0) 0x5bbf8(fe3ffe14, 3d0e08, 0, 0, 0, 0) 0x153f5c(3aacb8, 0, 0, 0, 0, 0) libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0)

1 0

Re: (ITS#5252) Several SQL Bugs in back-sql
by ando＠sys-net.it 01 Dec '07

01 Dec '07

h.goebel(a)goebel-consult.de wrote: > Full_Name: > Version: 2.3.38 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.207.201.247) > > > Debugging marks in sql-statement may lead to wrong results. > > The interface I implemented yields statements like this when using Thunderbird > for searching for 'Klaus'. Thunderbird tries to look up in email, name and given > name. > Ans in my setup, search is restricted to "(objectclass=evolutionPerson)". > > SELECT DISTINCT > ldap_entries.id,res_partner_address.id, > text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM > ldap_entries,res_partner_address,ldap_entry_objclasses > WHERE > res_partner_address.id=ldap_entries.keyval > AND ldap_entries.oc_map_id=1 > AND 9=9 > AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id > AND ldap_entry_objclasses.oc_name='evolutionPerson')) > AND (( upper(email) LIKE '%KLAUS%') > OR (upper(name) LIKE '%KLAUS%') > OR 7=7 > OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%'))) > > 1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done > on email, name or givenname. Thus all records are returned. > > 2) "2=2 OR" renders the restriction to a specific objectclass useless. > > In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this > part away. And exactly this is the problem. This is required to implement attribute and objectClass inheritance, which is required by LDAP. So please don't call them "bugs", they're required hacks. If they're not in place, back-sql would give the wrong response to queries; if they're in place, back-sql would give the right response, possibly inefficiently on braindead RDBMSes. Please choose what you prefer: the wrong answer quickly or the right one maybe slower? 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2007