openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs