openldap-bugs March 2011

openldap-bugs@openldap.org

47 participants
119 discussions

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

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2011