- openldap-bugs - openldap.org

(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 24 Mar '11

24 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 24 Mar '11

24 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

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by hyc＠symas.com 21 Mar '11

21 Mar '11

mm(a)FreeBSD.org wrote: > This problem is a generic problem of gcc version 4.4 and later. You're replying to a closed ITS. Not much point to that. > The new behaviour documented by GCC: > http://gcc.gnu.org/gcc-4.4/porting_to.html > > I recommend importing the patch from > http://www.openldap.org/its/index.cgi/Build?id=6832 The patch from ITS#6832 is already in CVS. That's what the "fixed in HEAD" status means. There's really nothing left to say or do here. > More information: > http://www.cyrius.com/journal/gcc/gcc-4.4-preprocessor-errors > http://gcc.gnu.org/viewcvs?view=revision&revision=136209 -- -- 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

(ITS#6875) openldap distribution list
by perfectwant＠hotmail.com 21 Mar '11

21 Mar '11

Full_Name: Jonathan Y Version: 3 OS: Ubuntu 10.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (219.76.238.78) Dear all, I would like to make a distribution list in openldap, also tried to use the FAQ posted method (proxyaddress) but it doesn't work. Any detail step by step documentation available about making distribution list? Thanks all. BR Jonathan

1 0

Re: (ITS#6832) fix #elif statement
by mm＠FreeBSD.org 20 Mar '11

20 Mar '11

To provide some background information, this problem is caused by a behaviour change of gcc version 4.4 and later. The new behaviour documented by GCC: http://gcc.gnu.org/gcc-4.4/porting_to.html More information: http://www.cyrius.com/journal/gcc/gcc-4.4-preprocessor-errors http://gcc.gnu.org/viewcvs?view=revision&revision=136209

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by mm＠FreeBSD.org 20 Mar '11

20 Mar '11

This problem is a generic problem of gcc version 4.4 and later. The new behaviour documented by GCC: http://gcc.gnu.org/gcc-4.4/porting_to.html I recommend importing the patch from http://www.openldap.org/its/index.cgi/Build?id=6832 More information: http://www.cyrius.com/journal/gcc/gcc-4.4-preprocessor-errors http://gcc.gnu.org/viewcvs?view=revision&revision=136209

1 0

(ITS#6874) slapd crashes while modifying a database
by dieter＠dkluenter.de 19 Mar '11

19 Mar '11

Full_Name: Dieter Kluenter Version: 2.4.24 OS: SLES11_x64 URL: Submission from: (NULL) (88.71.14.24) 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) linked libraries are /usr/lib/openldap> ldd slapd linux-vdso.so.1 => (0x00007fff8e9e1000) libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f633361e000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f633340f000) libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f6333205000) libdb-4.5.so => /usr/lib64/libdb-4.5.so (0x00007f6332ece000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6332cb1000) libslp.so.1 => /usr/lib64/libslp.so.1 (0x00007f6332a97000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f633287c000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f63324cd000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f6332292000) libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f6332087000) libc.so.6 => /lib64/libc.so.6 (0x00007f6331d27000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f6331b10000) libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f63318b4000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f63316b0000) /lib64/ld-linux-x86-64.so.2 (0x00007f633386f000) libz.so.1 => /lib64/libz.so.1 (0x00007f633149a000) -Dieter

1 0

(ITS#6873) Feature request slapo-lastbind: authTimestamp and relax rules control
by michael＠stroeder.com 19 Mar '11

19 Mar '11

Full_Name: Michael Ströder Version: RE24 OS: URL: Submission from: (NULL) (84.163.41.116) Attribute authTimestamp should be writeable by a client if relax rules control is sent along with the add/modify request (similar to modifyTimestamp).

1 0

(ITS#6872) syncprov performs unnecessary refreshes when replicating a subtree.
by cmikk＠qwest.net 18 Mar '11

18 Mar '11

Full_Name: Chris Mikkelson Version: 2.4.24 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) I have a multi-master LDAP master, with slaves replicating different subtrees of the directory. If a slave disconnects, a change is made on the master, and the slave reconnects, the master sends the complete subtree rather than the changed entries or a NEW_COOKIE message. Slaves which replicate the complete directory work fine -- only the changed entries are sent. The following script recreates this: http://mikk.net/~chris/syncprov-bug/syncprov-bug-demo (This script assumes that schemas are in /usr/local/etc/openldap/schema and the slapd binary is in /usr/local/libexec. Both are default for the FreeBSD port of OpenLDAP, but may need to be modified for other environments.) The script output is here: http://mikk.net/~chris/syncprov-bug/syncprov-bug-demo.out Note that the first ldapsearch with base dc=qwest,dc=net receives just the changed entry, but the second search with the same cookie and base ou=accounts,dc=qwest,dc=net receives the complete ou=accounts subtree.

1 0

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

18 Mar '11

Am Freitag 18 M=E4rz 2011, 15:45:59 schrieb frank.offermanns(a)caseris.de: > Thanks for your help. > Now I have the next error: >=20 > Creating library file: .libs/libldif.dll.a > .libs/fetch.o: In function `ldif_open_url': > C:/msys/1.0/openldap-2.4.24/libraries/liblutil/fetch.c:67: undefined > reference to `ldap_pvt_hex_unescape' > collect2: ld returned 1 exit status > make[2]: *** [libldif.la] Error 1 > make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/openldap-2.4.24/libraries' > make: *** [all-common] Error 1 Hm, bad. Additionally it seems my last commit was wrong as well. It seems liblber=20 has a dependency on liblutil at least in some cases. I'll revert it again=20 for now. Ralf

1 0

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

18 Mar '11

Thanks for your help. Now I have the next error: Creating library file: .libs/libldif.dll.a .libs/fetch.o: In function `ldif_open_url': C:/msys/1.0/openldap-2.4.24/libraries/liblutil/fetch.c:67: undefined reference to `ldap_pvt_hex_unescape' collect2: ld returned 1 exit status make[2]: *** [libldif.la] Error 1 make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/openldap-2.4.24/libraries' make: *** [all-common] Error 1 Best regards, Frank Offermanns

1 0

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

18 Mar '11

Am Freitag 18 M=E4rz 2011, 08:49:08 schrieb frank.offermanns(a)caseris.de: > Now I get the following error: > make[2]: *** No rule to make target > `../../libraries/liblber/liblber.la', needed > by `liblutil.a'. Stop. > make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/openldap-2.4.24/libraries' > make: *** [all-common] Error 1 Yes, I just stumbled across the same problem. Reodering the directories=20 in libraries/Makefile.in to build liblber before liblutil and removing=20 the liblutil dependency from the test binaries in liblber (which isn't=20 needed anyways AFAICS) fixes the problem for me. =46ix commited to HEAD. Ralf

1 0

(ITS#6871) Feature Request: slapo-lastbind authTimeStamp attribute replicated in MMR deploy
by marco.pizzoli＠gmail.com 18 Mar '11

18 Mar '11

Full_Name: Marco Pizzoli Version: 2.4.24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.174.164.11) This is a feature request. I would like to obtain authTimestamp attribute (as created by contrib/slapo-lastbind) being replicated by MultiMaster Replication. Actually, to obtain this information I need to query each server and take the more recent entry found. Thanks Marco Pizzoli

1 0

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

18 Mar '11

Now I get the following error: make[2]: *** No rule to make target `../../libraries/liblber/liblber.la', needed by `liblutil.a'. Stop. make[2]: Leaving directory `/openldap-2.4.24/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/openldap-2.4.24/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#6867) Password replication does not work properly in LDAP using openldap 2.4.23
by hyc＠symas.com 17 Mar '11

17 Mar '11

djadeja(a)avaya.com wrote: > Full_Name: Divyaraj Jadeja > Version: 2.4.23 > OS: RHEL 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.152.14.67) > > > Issue : Password replication does not work properly in LDAP using openLDAP > 2.4.23. Bug reports in 2.4.23 are no longer being investigated. 2.4.24 is the current release. This report is lacking critical details, particularly the actual configurations used on each server, including ACLs, relevant password policies, exact LDAP commands issued in each step, etc. > > Scenario1a: > Steps to Reproduce: > 1. Installed my custom software on 2 machines with HA LDAP configured. > 2. Verify that the connectivity between both the machines is working fine. > 3. Stopped slapd on Machine2. > 4. Created a new user test1 of a particular group on the Machine1. > 5. Started slapd on Machine2. > 6. Verified that test1 user created in step 4 is present in the LDAP DB on > Machine2. > 7. Login user test1 on the Machine2. The password of user test1 expires, login > of the user is successful after changing the password. > 8. Login the same user test1 on Machine1. > > Actual Result : > The changed password is not accepted on Machine1. > If the original password of user test1 is entered then the password is accepted > and the password expires again. > > Scenario 1b (minor modification in steps): > Created a new user. Ensure slapd on both Machine1& Machine2 is up& running. > Login this user on Machine2, password of this user expires, change the password. > Run ldapsearch command on both the machines. Password is changed on the > secondary dialer but the same is not replicated on the primary dialer. > > Expected Result : User's password must get replicated across all the Machines. > > Scenario 2 in which LDAP replication does not work. > > Steps to Reproduce: > 1. Set up 2 machines with HA-LDAP configured. > 2. Ensure that there is proper connectivity between both the machines. > 3. Stop slapd on machine1. > 4. Create a new user test2. > 5. Start slapd on machine1. > 6. Verify that the user is replicated on machine1. > 7. Cange the password, group& description and save. > > Actual Result : Changes are present on Machine1 but do not get replicated to > Machine2 even though slapd is up on both the machines. > > Additional Observations: > 1. This was observed intermittently. The default log is not leading anywhere, > will try setting advanced log& then replicating the issue. > 2. The pwd not replicating replicates after some time arnd 10 mins approx, will > find the time again. -- -- 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 17 Mar '11

17 Mar '11

Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.24 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.243) > > > I am able to compile OpenLDAP 2.4.23 with Berkeley DB 4.8.30 with MSYS and > windows with configure params: > configure --prefix=/mingw --enable-acceslog --with-tls > > But if I try to compile OpenLDAP 2.4.24 I get several undefined references to > ber_* functions when liblutil is build. > > According to Howard Chu it seems to be a bug in the Makefile introduced with the > new libldif. > > Thanks for your help, > Frank Offermanns > Now fixed in HEAD. -- -- 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

(ITS#6870) Undefined reference to ber_* with 2.4.24
by Frank.Offermanns＠caseris.de 17 Mar '11

17 Mar '11

Full_Name: Frank Offermanns Version: 2.4.24 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.243) I am able to compile OpenLDAP 2.4.23 with Berkeley DB 4.8.30 with MSYS and windows with configure params: configure --prefix=/mingw --enable-acceslog --with-tls But if I try to compile OpenLDAP 2.4.24 I get several undefined references to ber_* functions when liblutil is build. According to Howard Chu it seems to be a bug in the Makefile introduced with the new libldif. Thanks for your help, Frank Offermanns

1 0

Re: (ITS#6869) slapd segfaults during search traffic spike
by Howard Chu 16 Mar '11

16 Mar '11

This bug report is nonsense. The stack trace you attached does not come from slapd at all.

1 0

(ITS#6869) slapd segfaults during search traffic spike
by smkoch＠ornl.gov 16 Mar '11

16 Mar '11

Full_Name: Scott Koch Version: 2.4.23 OS: Centos 5.5 URL: Submission from: (NULL) (160.91.194.16) Problem Description: slapd segfaults during spike of ldap lookups. There are no error messages in the logs. See the gdb output below. Server Information: There are three identical read only(searches only) replicas(using syncrepl) that all demonstrate this problem that sit behind an IPVS load balancer. The servers run on Centos 5.5 x86_64 Vmware ESX4.0 virtual machines with 2GB of ram. The directory being served has just over 10,000 entries using the hdb database backend. openldap: @(#) $OpenLDAP: slapd 2.4.23 (Sep 24 2010 08:31:21) $ bdb: Berkeley DB 4.8.30: (April 9, 2010) gdb bt: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x40b5c940 (LWP 21140)] 0x00002b9c35b6b6b8 in pSD_WalkWorkQueue (Context=0x40b5c070, pWorkQueueVoid=0x0, HashKey=0, pfnbMatchEntry=0x2b9c35b58479 <bMgtCallback>, pSearchEntry=0x0) at work_queue.c:803 803 work_queue.c: No such file or directory. in work_queue.c (gdb) bt #0 0x00002b9c35b6b6b8 in pSD_WalkWorkQueue (Context=0x40b5c070, pWorkQueueVoid=0x0, HashKey=0, pfnbMatchEntry=0x2b9c35b58479 <bMgtCallback>, pSearchEntry=0x0) at work_queue.c:803 #1 0x00002b9c35b58435 in MgtSendThread (param=0x0) at acmgt.c:169 #2 0x00000033c560673d in start_thread () from /lib64/libpthread.so.0 #3 0x00000033c4ed3d1d in clone () from /lib64/libc.so.6 Let me know if there is more information and/or configuration files that I can provide to assist in tracking this down. Thanks, -Scott

1 0

(ITS#6868) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by ali.pouya＠free.fr 16 Mar '11

16 Mar '11

Full_Name: Ali POUYA Version: 2.4.24 OS: Redhat EL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.3) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses To produce the problem in the test environment you can proceed as follows : # Go to the tests directory : cd openldap-2.4.24/tests # Save the files which will be modified : cp data/test-translucent-add.ldif data/test-translucent-add.ldif.orig cp data/slapd-translucent-local.conf data/slapd-translucent-local.conf.orig # Add an auxiliary objectClass to the local directory LDIF file : cat >> data/test-translucent-add.ldif << ! > objectClass: extensibleObject > ! # Run the translucent test : ./run test034-translucent # The test does not succed, which is normal because we added an auxiliary objectClass. # Now simply add "overlay rwm" in the local config : sed -i 's/^database config/\noverlay rwm\n\ndatabase config/' data/slapd-translucent-local.conf # The test succeeds ! meaning that the auxiliary objectClass was filtered out by the rwm (was hided). I confirm that rwm works fine for the auxiliary objectClasses when used without the translucent overlay. Thanks for your help Best Regards Ali Pouya

1 0

(ITS#6867) Password replication does not work properly in LDAP using openldap 2.4.23
by djadeja＠avaya.com 16 Mar '11

16 Mar '11

Full_Name: Divyaraj Jadeja Version: 2.4.23 OS: RHEL 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.152.14.67) Issue : Password replication does not work properly in LDAP using openLDAP 2.4.23. Scenario1a: Steps to Reproduce: 1. Installed my custom software on 2 machines with HA LDAP configured. 2. Verify that the connectivity between both the machines is working fine. 3. Stopped slapd on Machine2. 4. Created a new user test1 of a particular group on the Machine1. 5. Started slapd on Machine2. 6. Verified that test1 user created in step 4 is present in the LDAP DB on Machine2. 7. Login user test1 on the Machine2. The password of user test1 expires, login of the user is successful after changing the password. 8. Login the same user test1 on Machine1. Actual Result : The changed password is not accepted on Machine1. If the original password of user test1 is entered then the password is accepted and the password expires again. Scenario 1b (minor modification in steps): Created a new user. Ensure slapd on both Machine1 & Machine2 is up & running. Login this user on Machine2, password of this user expires, change the password. Run ldapsearch command on both the machines. Password is changed on the secondary dialer but the same is not replicated on the primary dialer. Expected Result : User's password must get replicated across all the Machines. Scenario 2 in which LDAP replication does not work. Steps to Reproduce: 1. Set up 2 machines with HA-LDAP configured. 2. Ensure that there is proper connectivity between both the machines. 3. Stop slapd on machine1. 4. Create a new user test2. 5. Start slapd on machine1. 6. Verify that the user is replicated on machine1. 7. Cange the password, group & description and save. Actual Result : Changes are present on Machine1 but do not get replicated to Machine2 even though slapd is up on both the machines. Additional Observations: 1. This was observed intermittently. The default log is not leading anywhere, will try setting advanced log & then replicating the issue. 2. The pwd not replicating replicates after some time arnd 10 mins approx, will find the time again.

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by hyc＠symas.com 16 Mar '11

16 Mar '11

This is a multi-part message in MIME format. --------------070307090101090304000508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Quanah Gibson-Mount wrote: > > > --On March 9, 2011 9:42:18 AM -0800 Howard Chu<hyc(a)symas.com> wrote: > >> Quanah Gibson-Mount wrote: >>> >>> >>> --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >>>> Tested, and working. Thanks for the fix. >>> >>> We're still seeing this happen sporadically with slapindex -q<attribute> >>> >>> i.e., reindexing a single attribute instead of the entire DB >> >> Can't reproduce it here, need a test case. > > It's hard to come up with one. We've only had this one instance on one > machine. I reproduced your hang by adding a sleep(1) in front of the trickle task. This patch fixes it. I can't commit at the moment because cvs-master.openldap.org is not answering. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------070307090101090304000508 Content-Type: text/plain; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" Index: tools.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/tools.c,v retrieving revision 1.141 diff -u -r1.141 tools.c --- tools.c 11 Mar 2011 21:16:13 -0000 1.141 +++ tools.c 16 Mar 2011 06:35:09 -0000 @@ -1,5 +1,5 @@ /* tools.c - tools for slap tools */ -/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/tools.c,v 1.141 2011-03-11 21:16:13 hyc Exp $ */ +/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/tools.c,v 1.141 2011/03/11 21:16:13 hyc Exp $ */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 2000-2011 The OpenLDAP Foundation. @@ -162,6 +162,12 @@ slapd_shutdown = 1; #ifdef USE_TRICKLE ldap_pvt_thread_mutex_lock( &bdb_tool_trickle_mutex ); + + /* trickle thread may not have started yet */ + while ( !bdb_tool_trickle_active ) + ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond_end, + &bdb_tool_trickle_mutex ); + ldap_pvt_thread_cond_signal( &bdb_tool_trickle_cond ); while ( bdb_tool_trickle_active ) ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond_end, @@ -1256,6 +1262,7 @@ ldap_pvt_thread_mutex_lock( &bdb_tool_trickle_mutex ); bdb_tool_trickle_active = 1; + ldap_pvt_thread_cond_signal( &bdb_tool_trickle_cond_end ); while ( 1 ) { ldap_pvt_thread_cond_wait( &bdb_tool_trickle_cond, &bdb_tool_trickle_mutex ); --------------070307090101090304000508--

1 0

Re: (ITS#6862) Patch - Mozilla NSS - redux: disable pkcs11 fork checking for the software token
by hyc＠symas.com 15 Mar '11

15 Mar '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.24 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.24-use-strdup-for-nofork-envva… > Submission from: (NULL) (76.113.111.209) > > > There was still a problem with the fix for > http://www.openldap.org/its/index.cgi?findid=6811 > > Under certain conditions, and with certain shells, the PR_SetEnv with the > constant string was causing free() assertion failures in unrelated software. > > # su - foo > free(0x173bd2) below bottom of memory. (memtop = 0x9898800 membot = 0x973e000) > # gdb /bin/tcsh coredump > (gdb) bt > #0 0x00ed9416 in __kernel_vsyscall () > #1 0x006e02f1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0x006e1d5e in abort () at abort.c:92 > #3 0x08084e6a in free (cp=0x8f2bd2) at tc.alloc.c:313 > #4 0x08063d83 in blkfree (av0=0x9e7d988) at sh.misc.c:158 > #5 0x0805af6f in tsetenv (name=0x80a3420 L"GROUP", val=0x9e32608 > L"valid_group") at sh.func.c:1725 > #6 0x0804d910 in main (argc=<value optimized out>, argv=0xbfa7e4f4) at > sh.c:561 > > Using PR_SetEnv with a strdup()ed string solved the problem. At the expense of a small memory leak. Whatever happened to making PR_SetEnv() take care of this itself? http://osdir.com/ml/mozilla.devel.nspr/2005-02/msg00011.html I thought the point of NSPR was to provide a consistent cross-platform API. If PR_SetEnv() is documented to behave a particular way, and it doesn't, then this bug should be fixed in NSPR. If NSPR is unable to provide a consistent API... I'm getting the feeling that you're plugging an unmaintainable code base in here. -- -- 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

(ITS#6866) Math Error in Discussion of Delta-Syncrepl
by jong.limb＠dss.virginia.gov 15 Mar '11

15 Mar '11

Full_Name: Jong K. Limb Version: 2.4.23 OS: Linux URL: Submission from: (NULL) (166.67.66.8) In the Replication chapter, section 18.2.1 discusses the drawbacks to LDAP Sync replication. It gives the following paragraph: For example, suppose you have a database consisting of 100,000 objects of 1 KB each. Further, suppose you routinely run a batch job to change the value of a single two-byte attribute value that appears in each of the 100,000 objects on the master. Not counting LDAP and TCP/IP protocol overhead, each time you run this job each consumer will transfer and process 1 GB of data to process 200KB of changes! The math is incorrect. If 100,000 objects are of 1000 bytes each, that results in 100,000,000 bytes which is 100MB, not 1GB. This gives a false impression of the drawbacks of LDAP Sync replication.

1 0

(ITS#6865) delta-sync - contextCSN not updating on provider
by yuribank＠gmail.com 15 Mar '11

15 Mar '11

Full_Name: Yuri Bank Version: 2.4.23-24 OS: Linux Ubuntu 10.10 URL: http://yuri.easytospell.net/consumer.provider.txt Submission from: (NULL) (67.180.182.165) This issue exists in both versions 2.4.23 and 2.4.24 I've found an interesting problem with delta-sync replication in which the ContextCSN on my consumers is higher than the contextCSN on my provider. This is because the Provider does not properly update its contextCSN for its base suffix (dc=test,dc=com) when changes are made to group membership. Of couse, if it so happens that the last change in my database was not a group membership change, then the contextCSNs will be consistent between my consumers and provider. I use the following command to check the ContextCSN on each consumer: Consumer: 1 root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 Consumer: 2 ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 So we can see that the two consumers have matching contextCSNs: ContextCSN. 20110313041653.752098Z#000000#000#000000 Lets check the Provider now. Provider: root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" ContextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.709140Z#000000#000#000000 The providers CSN is smaller!? Lets take a closer look and search cn=accesslog These are the last two entries: ( first the user was added, and then the user was added to a group) # 20110313041653.000003Z, accesslog dn: reqStart=20110313041653.000003Z,cn=accesslog objectClass: auditAdd reqStart: 20110313041653.000003Z reqEnd: 20110313041653.000004Z reqType: add reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqResult: 0 reqMod: sn:+ Bank reqMod: userPassword:+ {SASL}banky reqMod: uid:+ banky reqMod: objectClass:+ top reqMod: objectClass:+ person reqMod: objectClass:+ shadowAccount reqMod: structuralObjectClass:+ person reqMod: cn:+ Bank, Yuri(banky) reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 reqMod: creatorsName:+ cn=admin,dc=test,dc=com reqMod: createTimestamp:+ 20110313041653Z reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 reqMod: modifiersName:+ cn=admin,dc=test,dc=com reqMod: modifyTimestamp:+ 20110313041653Z # 20110313041653.000006Z, accesslog dn: reqStart=20110313041653.000006Z,cn=accesslog objectClass: auditModify reqStart: 20110313041653.000006Z reqEnd: 20110313041653.000007Z reqType: modify reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com reqResult: 0 reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 reqMod: modifiersName:= cn=admin,dc=test,dc=com reqMod: modifyTimestamp:= 20110313041653Z You can see that the consumers have the latest entryCSN (20110313041653.752098Z) as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z) before that as its contextCSN: If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the same result as the consumers: 20110313041653.752098Z#000000#000#000000 As you can see, the provider is not using the latest entryCSN as its ContextCSN, where as the consumer nodes are. Also notice that the last modification was to group membership. This problem only seems to exist when Adding/Removing users from a group. A side effect of this issue causes brand new consumers to get stuck in an infinite loop while syncing for the first time. A work around is to make a random change to a User/Person, such as injecting a random number into their description field AFTER making a change to a group membership. Such a change will: A. cause the Provider to correctly update its contextCSN, B. provider and all consumer[s] will have the same contextCSN C. brand new consumers can be added without getting stuck in an infinite loop when syncing the database. ( they seem to get stuck on the last entry which makes sense if the last entry has a higher entryCSN than that of the Providers contextCSN? ) Confgiuration: ( See URL ) http://yuri.easytospell.net/consumer.provider.txt Overlays: syncprov accesslog memberof Please feel free to email me about reproducing this problem. I have a lab with various configurations and would be happy to give access to anyone interested. - Yuri Bank

1 0

(ITS#6864) delta-sync - contextCSN not updating on provider
by yuribank＠gmail.com 15 Mar '11

15 Mar '11

Full_Name: Yuri Bank Version: 2.4.23-24 OS: Linux Ubuntu 10.10 URL: http://yuri.easytospell.net/consumer.provider.txt Submission from: (NULL) (67.180.182.165) This issue exists in both versions 2.4.23 and 2.4.24 I've found an interesting problem with delta-sync replication in which the ContextCSN on my consumers is higher than the contextCSN on my provider. This is because the Provider does not properly update its contextCSN for its base suffix (dc=test,dc=com) when changes are made to group membership. Of couse, if it so happens that the last change in my database was not a group membership change, then the contextCSNs will be consistent between my consumers and provider. I use the following command to check the ContextCSN on each consumer: Consumer: 1 root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 Consumer: 2 ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 So we can see that the two consumers have matching contextCSNs: ContextCSN. 20110313041653.752098Z#000000#000#000000 Lets check the Provider now. Provider: root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" ContextCSN dn: dc=test,dc=com dn: dc=test,dc=com contextCSN: 20110313041653.709140Z#000000#000#000000 The providers CSN is smaller!? Lets take a closer look and search cn=accesslog These are the last two entries: ( first the user was added, and then the user was added to a group) # 20110313041653.000003Z, accesslog dn: reqStart=20110313041653.000003Z,cn=accesslog objectClass: auditAdd reqStart: 20110313041653.000003Z reqEnd: 20110313041653.000004Z reqType: add reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqResult: 0 reqMod: sn:+ Bank reqMod: userPassword:+ {SASL}banky reqMod: uid:+ banky reqMod: objectClass:+ top reqMod: objectClass:+ person reqMod: objectClass:+ shadowAccount reqMod: structuralObjectClass:+ person reqMod: cn:+ Bank, Yuri(banky) reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 reqMod: creatorsName:+ cn=admin,dc=test,dc=com reqMod: createTimestamp:+ 20110313041653Z reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 reqMod: modifiersName:+ cn=admin,dc=test,dc=com reqMod: modifyTimestamp:+ 20110313041653Z # 20110313041653.000006Z, accesslog dn: reqStart=20110313041653.000006Z,cn=accesslog objectClass: auditModify reqStart: 20110313041653.000006Z reqEnd: 20110313041653.000007Z reqType: modify reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com reqResult: 0 reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 reqMod: modifiersName:= cn=admin,dc=test,dc=com reqMod: modifyTimestamp:= 20110313041653Z You can see that the consumers have the latest entryCSN (20110313041653.752098Z) as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z) before that as its contextCSN: If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the same result as the consumers: 20110313041653.752098Z#000000#000#000000 As you can see, the provider is not using the latest entryCSN as its ContextCSN, where as the consumer nodes are. Also notice that the last modification was to group membership. This problem only seems to exist when Adding/Removing users from a group. A side effect of this issue causes brand new consumers to get stuck in an infinite loop while syncing for the first time. A work around is to make a random change to a User/Person, such as injecting a random number into their description field AFTER making a change to a group membership. Such a change will: A. cause the Provider to correctly update its contextCSN, B. provider and all consumer[s] will have the same contextCSN C. brand new consumers can be added without getting stuck in an infinite loop when syncing the database. ( they seem to get stuck on the last entry which makes sense if the last entry has a higher entryCSN than that of the Providers contextCSN? ) Confgiuration: ( See URL ) http://yuri.easytospell.net/consumer.provider.txt Overlays: syncprov accesslog memberof Please feel free to email me about reproducing this problem. I have a lab with various configurations and would be happy to give access to anyone interested. - Yuri Bank

1 0

Re: (ITS#6861) slapd and syncrepl performance problem
by quanah＠zimbra.com 14 Mar '11

14 Mar '11

--On Thursday, March 10, 2011 4:36 PM +0000 jeff_wheeler67(a)comcast.net wrote: > Full_Name: Jeff Wheeler > Version: 2.4.20 This release is significantly out of date, and missing numerous replication related patches. I advise attempting to reproduce with a current release. --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

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by h.b.furuseth＠usit.uio.no 14 Mar '11

14 Mar '11

dvladi(a)websense.com writes: > You are right, ldap_int_thread_mutex_(X) functions were introduced in > 2.3.8 on 10/06/2005. > > But there is NO declaration or function definition anywhere in the code. Fixed in HEAD to ldap_pvt_thread_mutex_init() after an overeager namespace cleanup. (I had confused it with some libldap_r debug stuff.) The other ldap_int_* stuff looks OK. -- Hallvard

1 0

(ITS#6863) possible null pointer dereference in NSS
by jvcelak＠redhat.com 14 Mar '11

14 Mar '11

Full_Name: Jan Vcelak Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/jan-vcelak-nss-null-pointer-dereference-110… Submission from: (NULL) (209.132.186.34) Hello. Recent NSS patch, which adds full non-blocking semantics (ITS #6714), introduced possible NULL pointer dereference by mistake. This patch fixes the problem. Jan

1 0

(ITS#6862) Patch - Mozilla NSS - redux: disable pkcs11 fork checking for the software token
by rmeggins＠redhat.com 10 Mar '11

10 Mar '11

Full_Name: Rich Megginson Version: 2.4.24 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.24-use-strdup-for-nofork-envva… Submission from: (NULL) (76.113.111.209) There was still a problem with the fix for http://www.openldap.org/its/index.cgi?findid=6811 Under certain conditions, and with certain shells, the PR_SetEnv with the constant string was causing free() assertion failures in unrelated software. # su - foo free(0x173bd2) below bottom of memory. (memtop = 0x9898800 membot = 0x973e000) # gdb /bin/tcsh coredump (gdb) bt #0 0x00ed9416 in __kernel_vsyscall () #1 0x006e02f1 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x006e1d5e in abort () at abort.c:92 #3 0x08084e6a in free (cp=0x8f2bd2) at tc.alloc.c:313 #4 0x08063d83 in blkfree (av0=0x9e7d988) at sh.misc.c:158 #5 0x0805af6f in tsetenv (name=0x80a3420 L"GROUP", val=0x9e32608 L"valid_group") at sh.func.c:1725 #6 0x0804d910 in main (argc=<value optimized out>, argv=0xbfa7e4f4) at sh.c:561 Using PR_SetEnv with a strdup()ed string solved the problem. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6860) slapadd accepts duplicate objectclasses
by masarati＠aero.polimi.it 10 Mar '11

10 Mar '11

hyc(a)symas.com wrote: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Klünter >> Version: 2.4.24 >> OS: SLES11_x64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.18.17) >> >> >> A ldif generator created out of a total of 100,000 entries 10,000 entries with >> duplicate objectclasses i.e. >> >> dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: inetOrgPerson >> objectClass: top >> objectClass: person >> objectClass: organizationalPerson >> objectClass: inetOrgPerson >> cn: Al-BasiM >> sn: Al-Basi >> >> This ldif has been loaded by slapadd without any warnings. The only parameter >> applied where -l and -f. > > This is normal. slapadd doesn't do validation, you are expected to feed it > valid output from slapcat. This documented behavior has not changed in a decade. Let me add that in recent releases you can specify -o value-check=yes to enforce value checking (incurring in the related penalty). This would have revealed the error. p.

1 0

(ITS#6861) slapd and syncrepl performance problem
by jeff_wheeler67＠comcast.net 10 Mar '11

10 Mar '11

Full_Name: Jeff Wheeler Version: 2.4.20 OS: RHEL4.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.103.136.179) Under ldapsearch/modify load of approximately 160 simultaneous sessions towards the First Master only, after several hours replication falls behind and searches and modifies that previously were <1 second now take 10 seconds+. We see also these messages continually every 5 seconds or so: Mar 10 04:02:05 auvhen2be01 slapd[29178]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Mar 10 04:02:05 auvhen2be01 slapd[29178]: conn=2249 op=13995: attribute "entryCSN" index add failure LDAP is configured in 2-way multi-master mirrormode on 2 Quad core HP blades with 72GB RAM each. Cache size set to 10GB, id2entry=18GB. The replication agreements are as such: olcSyncrepl: {0}rid=2 provider=ldap://auvhen4be05-traffic.vm.vodafone.net.au b indmethod=simple timeout=0 network-timeout=0 binddn="cn=Directory Manager,o=h 3gau" credentials="admin123" starttls=no filter="(objectclass=*)" searchbase= "o=h3gau" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" .. olcOverlay: {0}syncprov olcSpCheckpoint: 100 600 .. Eventually, the syncrepl connection goes to TIME_WAIT state and replications stop. Restarting slapd does not fix and we have to reload from backup. We tuned the following and no longer does slapd repl connection go to TIME_WAIT, however it still falls hours behind on updates and performs slowly as before. Cache size set to 20GB, olcDbIDLcacheSize: 20000000000, olcThreads: 32 Restarting slapd results in the repl connection binding, searching, but then unbinds immediately: Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 ACCEPT from IP=10.176.77.23:50798 (IP=10.176.77.47:389) Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" method=128 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" mech=SIMPLE ssf=0 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 RESULT tag=97 err=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH base="o=h3gau" scope=2 deref=0 filter="(objectClass=*)" Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH attr=* + Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=2 UNBIND Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 closed

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs