openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(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

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