- openldap-bugs - openldap.org

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

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

20 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 14 Mar '11

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

14 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs