- openldap-bugs - openldap.org

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 27 Mar '11

27 Mar '11

I've installed version 2.4.24 and been running it for a few days now. I'll report back in a few days on it's outcome. On Mar 24, 2011, at 1:34 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --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#6880 published: SECURITY: ldap_free_urllist segfault
by openldap-its＠OpenLDAP.org 27 Mar '11

27 Mar '11

Private ITS#6880 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6880

1 0

(ITS#6881)
by rottex＠gmx.net 26 Mar '11

26 Mar '11

This is a multi-part message in MIME format. --------------090304070908010006050102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit double post of ITS#6880 since openldap homepage had an error while submitting. please delete this one ! THX --------------090304070908010006050102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body bgcolor="#ffffff" text="#000000"> double post of ITS#6880 since openldap homepage had an error while submitting. please delete this one ! THX </body> </html> --------------090304070908010006050102--

1 0

Another fix for (ITS#6872)
by cmikk＠qwest.net 25 Mar '11

25 Mar '11

I have found another corner case which can cause this behavior. If syncprov_findcsn() cannot find an entry with CSN matching the cookie mincsn, it tries to search for an entry with CSN less than or equal to the mincsn. For this search, it sets the unchecked limit to 1. If the scope of the search is not the whole database, this can cause the search to fail. The entryCSN filter identifies one candidate, and if that candidate is out of scope the search will fail, causing a full refresh. Two potential fixes here would be: 1) Set the hard or soft limits to 1 instead of the unchecked limit. This search is used to determine if an expensive full refresh is necessary, so a more expensive check may be acceptable. 2) Search the overlaid database for the desired entryCSN instead of just the replicated subtree. This is what I've implemented locally. The patch (against 2.4.24): diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index 349b580..a7147a2 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -679,6 +679,8 @@ again: fop.ors_limit = &fc_limits; memset( &fc_limits, 0, sizeof( fc_limits )); fc_limits.lms_s_unchecked = 1; + fop.o_req_dn = si->si_contextdn; + fop.o_req_ndn = si->si_contextdn; fop.ors_filterstr.bv_len = snprintf( buf, sizeof( buf ), "(entryCSN<=%s)", cf.f_av_value.bv_val ); } -- Chris Mikkelson | Problems are posed by fools like me; cmikk(a)qwest.net | But only Heuristics can search a tree.

1 0

Re: (ITS#6879) Typo in Makefile of slapo-lastbind
by quanah＠zimbra.com 25 Mar '11

25 Mar '11

--On Friday, March 25, 2011 7:37 PM +0000 michael(a)stroeder.com wrote: > 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/ Fixed. --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#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

(ITS#6876) Ldaps fault tolerance not working
by koshikov＠gmail.com 23 Mar '11

23 Mar '11

Full_Name: Nikita Koshikov Version: 2.4.24 OS: gentoo-linux kernel 2.6.26 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.82.218.210) Using openldap libraries for connection to Microsoft AD server with different software(dovecot\squid) fault tolerance not working with ldaps protocol. Example: uris = ldaps://host1 ldaps://host2 When host1 is completly down - ldapsearch successfully connects to host2 and get data, but when host1 is up, but rejecting connection on port - library not trying host2 - it just return error - connection reject. This have been tested with openldap version 2.4.24 and 2.3.43(centos 5) - both works the same. This behavior observed with ldapsearch, dovecot-imap server, squid server.

1 0

Fix for (ITS#6872)
by cmikk＠qwest.net 22 Mar '11

22 Mar '11

I have uploaded a patch to the ftp incoming directory as: chris-mikkelson-20110322.patch The issue was that, when called from syncprov_op_search, syncprov_findcsn uses the minimum CSN from the consumer cookie rather than the mincsn value calculated by syncprov_op_search. The patch passes syncprov_findcsn() the mincsn value calculated in syncprov_op_search(). This appears to fix the issue in my tests. Thanks, -- Chris Mikkelson | Disclaimer: the plural of "anecdote" is not "data." cmikk(a)qwest.net | -- spencer(a)engin.umich.edu

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by richm＠stanfordalumni.org 22 Mar '11

22 Mar '11

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. > > 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. > Ralf > >

1 0

Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by rhafer＠suse.de 22 Mar '11

22 Mar '11

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. I am bit confused about how this was supposed to work orginally (libldif=20 as a standalone library). Ralf

1 0

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

22 Mar '11

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. > > 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. And as yet another option, why not build it alongside libldap... -- -- 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
by hyc＠symas.com 22 Mar '11

22 Mar '11

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. 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. -- -- 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
by Ralf Haferkamp 22 Mar '11

22 Mar '11

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. Ralf

1 0

Re: (ITS#6874) slapd crashes while modifying a database
by rhafer＠suse.de 21 Mar '11

21 Mar '11

Am Samstag 19 M=E4rz 2011, 14:37:46 schrieb dieter(a)dkluenter.de: > While modifying a database, either subordinate or not, slapd crashes. > Debugging and configuration information can be found here: > http://pastebin.de/16349 (debugging) > http://pastebin.de/16350 (slapd.conf) I wonder if such a configuration is even supposed to work. The accesslog=20 overlay on the master is configured for the glued database=20 (dc=3Ddkluenter,dc=3Dde). On the slave however you have individual syncrepl= =20 configuration for each subordinate database. Wouldn't it be correct to=20 have separate accesslog databases for the subordinates? Additionally I think that at least the "overlay syncprov" for the=20 subordinate databases on the master is wrong (as syncprov is already=20 configured for the glued database). Not sure if it is harmful though. A more selfcontained and stripped down example configuration with actual=20 data and information on which operation exactly fails could also help=20 debugging this (assuming that your config turns out to be valid). Ralf

1 0

Re: (ITS#6875) openldap distribution list
by Ralf Haferkamp 21 Mar '11

21 Mar '11

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.

1 0

(ITS#6810) closing issue...
by bruno.haleblian＠gmail.com 21 Mar '11

21 Mar '11

Valgrind only crashes and complains about running out of memory. Current issue has been solved anyway. Explananation : A partner site had connected a replica thru a load balanced Virtual IP adress. Correcting this misconfiguration obviously stopped crashing. I'm now facing a memory leak with 2.4.24 for which I'll open a new Issue if necessary. Thanks for your support. B.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs