openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5256) encoding of guide.sdf
by kurt＠OpenLDAP.org 02 Dec '07

02 Dec '07

On Dec 2, 2007, at 8:10 PM, ghenry(a)suretecsystems.com wrote: > <quote who="dieter(a)dkluenter.de"> >> 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 ... > > Is this something I can fix, or is it part of the doc build for the > main > site? You can avoid using non-ASCII characters... > > >> >> -Dieter >> >> >> > >

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 02 Dec '07

02 Dec '07

> Please upload a new patch file which contains both of these notices and then > your diff (updated if > appropriate), and then send an email update to the ITS referencing the new > patch file. Here we are: ftp://ftp.openldap.org/incoming/manu-071202.patch ftp://ftp.openldap.org/incoming/manu-pkg-071202.tgz -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5256) encoding of guide.sdf
by hyc＠symas.com 02 Dec '07

02 Dec '07

hyc(a)symas.com wrote: > ghenry(a)suretecsystems.com wrote: >> <quote who="dieter(a)dkluenter.de"> >>> 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 ... >> Is this something I can fix, or is it part of the doc build for the main >> site? > > It's in the SDF source files, therefore something you should fix. I don't know > what text editor you used on those files, but you should use something else, > or use one that you can set to just ISO8859-1. > > I can't think of a grep regex that will detect 8-bit characters, but you need > to find them all and get rid of them. (Used a binary editor to generate a regexp for [ 0x80 - 0xff ]). There were only two occurrences in the sdf files; both in backends.sdf. Both are the same character, an apostrophe used instead of a single quote. (binary patch xx) X=`cat xx` % grep "[$X]" *.sdf backends.sdf:same connection. This connection pooling strategy can enhance the proxys backends.sdf:maybe stored procedures cant be considered programming, anyway ;). -- -- 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#5256) encoding of guide.sdf
by hyc＠symas.com 02 Dec '07

02 Dec '07

ghenry(a)suretecsystems.com wrote: > <quote who="dieter(a)dkluenter.de"> >> 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 ... > > Is this something I can fix, or is it part of the doc build for the main > site? It's in the SDF source files, therefore something you should fix. I don't know what text editor you used on those files, but you should use something else, or use one that you can set to just ISO8859-1. I can't think of a grep regex that will detect 8-bit characters, but you need to find them all and get rid of them. -- -- 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#5256) encoding of guide.sdf
by ghenry＠suretecsystems.com 02 Dec '07

02 Dec '07

<quote who="dieter(a)dkluenter.de"> > 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 ... Is this something I can fix, or is it part of the doc build for the main site? > > -Dieter > > >

1 0

(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 02 Dec '07

02 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

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