Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by rhafer＠suse.de
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
10 years, 10 months
Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by frank.offermanns＠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
10 years, 10 months
Re: (ITS#6867) Password replication does not work properly in LDAP using openldap 2.4.23
by hyc＠symas.com
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/
10 years, 10 months
Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by hyc＠symas.com
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/
10 years, 10 months
(ITS#6870) Undefined reference to ber_* with 2.4.24
by Frank.Offermanns＠caseris.de
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
10 years, 10 months
(ITS#6869) slapd segfaults during search traffic spike
by smkoch＠ornl.gov
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
10 years, 10 months
(ITS#6868) When used in conjunction with the translucent overlay, the rwm overlay filters out auxiliary objectclasses
by ali.pouya＠free.fr
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
10 years, 10 months
(ITS#6867) Password replication does not work properly in LDAP using openldap 2.4.23
by djadeja＠avaya.com
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.
10 years, 10 months
