openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6879) Typo in Makefile of slapo-lastbind
by michael＠stroeder.com 25 Mar '11

25 Mar '11

Full_Name: Michael Ströder Version: RE24 OS: URL: Submission from: (NULL) (84.128.253.71) There's a typo in the Makefile for slapo-lastbind found under contrib/ Index: Makefile =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/lastbind/Makefile,v retrieving revision 1.2.2.3 diff -u -r1.2.2.3 Makefile --- Makefile 24 Mar 2011 18:13:52 -0000 1.2.2.3 +++ Makefile 25 Mar 2011 17:40:25 -0000 @@ -31,4 +31,4 @@ install: lastbind.la mkdir -p $(prefix)/libexec/openldap - $(LIBTOOL) --mode=onstall cp lastbind.la $(prefix)/libexec/openldap + $(LIBTOOL) --mode=install cp lastbind.la $(prefix)/libexec/openldap

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by quanah＠zimbra.com 24 Mar '11

24 Mar '11

--On Thursday, March 24, 2011 4:28 PM +0000 tjgates(a)castlebranch.com wrote: > Full_Name: Tyler Gates > Version: 2.4.21 > OS: Ubuntu 10.04.2 LTS/CentOS 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.106.216.17) > > > I have a caching proxy server (2.4.21) in front of two multi-masters. > After about 1 to 3 days it will segfault only when caching is enabled. > Log files are normally pretty useless but are normally in the operation > of removing stale queries: Bug reports with 2.4.21 are not being pursued. Please use a current release (2.4.24) and verify whether or not the issue still exists there. --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#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 24 Mar '11

24 Mar '11

Full_Name: Tyler Gates Version: 2.4.21 OS: Ubuntu 10.04.2 LTS/CentOS 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.106.216.17) I have a caching proxy server (2.4.21) in front of two multi-masters. After about 1 to 3 days it will segfault only when caching is enabled. Log files are normally pretty useless but are normally in the operation of removing stale queries: Mar 24 09:55:36 directory-proxy2 slapd[5363]: REMOVING TEMP ATTR : TEMPLATE=ba2c2b64-ea65-102f-96bd-2f354737277c Mar 24 09:55:36 directory-proxy2 slapd[5363]: STALE QUERY REMOVED, SIZE=0 Mar 24 09:55:36 directory-proxy2 slapd[5363]: STORED QUERIES = 22 Mar 24 09:55:36 directory-proxy2 slapd[5363]: STALE QUERY REMOVED, CACHE =1 entries Mar 24 09:55:36 directory-proxy2 slapd[5363]: Lock CR index = 0xb8848c00 I've attached to the running process using gdb and got the following: ************************************************************************** Program received signal SIGPIPE, Broken pipe. Program received signal SIGPIPE, Broken pipe. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb61b4b70 (LWP 5365)] tavl_delete (root=0x0, data=0xb890bac0, fcmp=0xb6b64910 <pcache_query_cmp>) at /build/buildd/openldap-2.4.21/libraries/liblutil/tavl.c:200 200 /build/buildd/openldap-2.4.21/libraries/liblutil/tavl.c: No such file or directory. in /build/buildd/openldap-2.4.21/libraries/liblutil/tavl.c (gdb) Continuing. [Thread 0xb1effb70 (LWP 7113) exited] [Thread 0xb2d9cb70 (LWP 10996) exited] [Thread 0xb3a9fb70 (LWP 9738) exited] [Thread 0xb47a2b70 (LWP 8550) exited] [Thread 0xb65b5b70 (LWP 5364) exited] [Thread 0xb61b4b70 (LWP 5365) exited] [Thread 0xb5cb2b70 (LWP 5673) exited] Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) bt No stack. ********************************************************************** As you can see I cannot get a back trace, but I still have the gdb shell running so I run any other commands if needed. I've run version 2.4.18 on a CentOS machine with the same setup and I get segfaults only when pcache is enabled although I've never run it under gdb.

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24 - Fixed
by frank.offermanns＠caseris.de 24 Mar '11

24 Mar '11

I can confirm that HEAD can be build with MSYS and Windows now. This ITS can be closed. Thanks a lot for your help. Best regards, Frank Offermanns

1 0

(ITS#6877) Bug in slapo-cloack Makefile(?)
by marco.pizzoli＠gmail.com 24 Mar '11

24 Mar '11

Full_Name: Marco Pizzoli Version: 2.4.24/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) Hi, in trying to compile overlay slapo-cloack I needed to hack a little the associated Makefile. I needed to add the following line: BEFORE: ==================== CPPFLAGS+=-I../../../include_-I../../../servers/slapd_ CPPFLAGS+=-DSLAPD_OVER_CLOAK=SLAPD_MOD_DYNAMIC LIBS=-lldap_r_-llber_-lcrypto ===================== AFTER: ==================== CPPFLAGS+=-I../../../include -I../../../servers/slapd CPPFLAGS+=-DSLAPD_OVER_CLOAK=SLAPD_MOD_DYNAMIC LIBTOOL=../../../libtool LIBS=-lldap_r -llber -lcrypto ==================== Hope this helps. Marco Pizzoli

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24 - Build still broken
by hyc＠symas.com 24 Mar '11

24 Mar '11

frank.offermanns(a)caseris.de wrote: > Now I get the next compile error: Should be fixed now in HEAD. > > c:\mingw\bin\ar.exe: creating ../liboverlays.a > make[3]: Leaving directory `/openldap-2.4.24/servers/slapd/overlays' > ../../build/mkversion -v "2.X" -s -n Versionstr slapd> version.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > main.o > main.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > globals > .o globals.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > bconfig > .o bconfig.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > config. > o config.c > gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o > daemon. > o daemon.c > daemon.c: In function `slapd_daemon_init': > daemon.c:1644: error: incompatible types in assignment > daemon.c:1644: error: incompatible types in assignment > daemon.c: In function `slapd_daemon': > daemon.c:2904: error: incompatible types in assignment > daemon.c:2904: error: incompatible types in assignment > make[2]: *** [daemon.o] Error 1 > make[2]: Leaving directory `/openldap-2.4.24/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/openldap-2.4.24/servers' > make: *** [all-common] Error 1 > > Regards, > Frank Offermanns > > > -- -- Howard Chu CTO, 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#6870) Undefined reference to ber_* with 2.4.24 - Build still broken
by frank.offermanns＠caseris.de 24 Mar '11

24 Mar '11

Now I get the next compile error: c:\mingw\bin\ar.exe: creating ../liboverlays.a make[3]: Leaving directory `/openldap-2.4.24/servers/slapd/overlays' ../../build/mkversion -v "2.X" -s -n Versionstr slapd > version.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o main.o main.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o globals .o globals.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o bconfig .o bconfig.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o config. o config.c gcc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o daemon. o daemon.c daemon.c: In function `slapd_daemon_init': daemon.c:1644: error: incompatible types in assignment daemon.c:1644: error: incompatible types in assignment daemon.c: In function `slapd_daemon': daemon.c:2904: error: incompatible types in assignment daemon.c:2904: error: incompatible types in assignment make[2]: *** [daemon.o] Error 1 make[2]: Leaving directory `/openldap-2.4.24/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/openldap-2.4.24/servers' make: *** [all-common] Error 1 Regards, Frank Offermanns

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by hyc＠symas.com 23 Mar '11

23 Mar '11

richm(a)stanfordalumni.org wrote: > On 03/22/2011 08:31 AM, rhafer(a)suse.de wrote: >> Am Dienstag 22 M=E4rz 2011, 11:39:33 schrieb hyc(a)symas.com: >>> hyc(a)symas.com wrote: >>>> Ralf Haferkamp wrote: >>>>> I changed the state back to "Open" as the problem is not really >>>>> solved yet. I wonder if we should revert the original fix to >>>>> liblutil/Makefile.in for now to have at least a working built back >>>>> on non-Windows Platforms. >>>> =20 >>>> Revert is fine to get HEAD building cleanly for now. Seems like the >>>> best solution longterm is to move libldif into its own directory >>>> since the rest of liblutil doesn't depend on it. >>> =20 >>> And as yet another option, why not build it alongside libldap... >> Shouldn't we just integrate it with libldap? AFAICS libldif uses stuff=20 >> from libldap (ldap_pvt_hex_unescape) anyways and libldap (ldifutil.c)=20 >> needs libldif. Yeah, that makes the most sense. I've just moved it over for now, the code is untouched so the names are still ldif_* (as opposed to ldap_ldif_*). I don't see any good reason to change the names. >> I am bit confused about how this was supposed to work orginally (libldif=20 >> as a standalone library). > I don't know if openldap ever had a truly standalone libldif. It's fine > with me if the ldif functionality is provided by libldap. Sounds good. HEAD now builds cleanly. -- -- Howard Chu CTO, 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#6875) openldap distribution list
by perfectwant＠hotmail.com 23 Mar '11

23 Mar '11

--_cbeddd50-e8ab-4067-9263-41b148d632ab_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit Dear Support, The p[em;da[-technical list seems to list all related e-mail and forward to my e-mail. Is that true? BR Jonathan > Date: Mon, 21 Mar 2011 10:00:26 +0000 > From: openldap-its(a)OpenLDAP.org > To: perfectwant(a)hotmail.com > Subject: Re: (ITS#6875) openldap distribution list > CC: openldap-its(a)OpenLDAP.org > > The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. > Nothing in your report is indicative of a bug in OpenLDAP. > If you have questions about use of OpenLDAP Software which are > not answered in the documentation, FAQ, and archives, use the > OpenLDAP-technical list. This issue report will be closed. --_cbeddd50-e8ab-4067-9263-41b148d632ab_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: 8bit <html> <head> <style></style> </head> <body class='hmmessage'>  Dear Support,   The p[em;da[-technical list seems to list all related e-mail and forward to my e-mail. Is that true?   BR Jonathan > Date: Mon, 21 Mar 2011 10:00:26 +0000 > From: openldap-its(a)OpenLDAP.org > To: perfectwant(a)hotmail.com > Subject: Re: (ITS#6875) openldap distribution list > CC: openldap-its(a)OpenLDAP.org > > The OpenLDAP-ITS address is for reporting bugs in OpenLDAP software. > Nothing in your report is indicative of a bug in OpenLDAP. > If you have questions about use of OpenLDAP Software which are > not answered in the documentation, FAQ, and archives, use the > OpenLDAP-technical list. This issue report will be closed. </body> </html> --_cbeddd50-e8ab-4067-9263-41b148d632ab_--

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by akreffett＠cert.org 23 Mar '11

23 Mar '11

I ran in to this issue when attempting to enforce group ACLs on a translucent proxy where all group information is stored on the proxied directory. I implemented a hack in 2.3.43 (RHEL-5, we're a bit behind the times) to implement bi_entry_get_rw on slapo-translucent and rewire calls within the overlay from be_entry_get_rw to overlay_entry_get_ov. To prevent internal calls to be_entry_get_rw from invoking the new function (and potentially resulting in infinite recursion) I reworked the calls to overlay_entry_get_ov to use on->on_next instead of the top of the overlay stack. I believe that this was the original intent of these uses anyway to obtain the local-backend information so the call should start at the next overlay, or directly to the underlying database if there are no other overlays on the stack. I also applied a small patch to backover.c to support passing NULL to the on parameter of overlay_entry_get_ov and its release function to signify that the bottom of the overlay stack has been reached and to just call the backend database. When merging remote and local records the local records were duped and released immediately and the dupes appended to the returned entry and the caller left responsible to call entry_free. I have not thoroughly tested this code and I will need to rewrite it for 2.4 anyway (when we move to it, hopefully later this year) but wanted to check if there has been any progress on this issue that would obviate my need to port this to 2.4. If not, aside from what I described above am I missing any glaring issues that I would need to address to get a complete solution to this issue? Thanks, Aaron Reffett

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