openldap-bugs March 2011

openldap-bugs@openldap.org

47 participants
119 discussions

Re: (ITS#5628) dereferencing user with translucent overlay
by akreffett＠cert.org 23 Mar '11

23 Mar '11

I ran in to this issue when attempting to enforce group ACLs on a translucent proxy where all group information is stored on the proxied directory. I implemented a hack in 2.3.43 (RHEL-5, we're a bit behind the times) to implement bi_entry_get_rw on slapo-translucent and rewire calls within the overlay from be_entry_get_rw to overlay_entry_get_ov. To prevent internal calls to be_entry_get_rw from invoking the new function (and potentially resulting in infinite recursion) I reworked the calls to overlay_entry_get_ov to use on->on_next instead of the top of the overlay stack. I believe that this was the original intent of these uses anyway to obtain the local-backend information so the call should start at the next overlay, or directly to the underlying database if there are no other overlays on the stack. I also applied a small patch to backover.c to support passing NULL to the on parameter of overlay_entry_get_ov and its release function to signify that the bottom of the overlay stack has been reached and to just call the backend database. When merging remote and local records the local records were duped and released immediately and the dupes appended to the returned entry and the caller left responsible to call entry_free. I have not thoroughly tested this code and I will need to rewrite it for 2.4 anyway (when we move to it, hopefully later this year) but wanted to check if there has been any progress on this issue that would obviate my need to port this to 2.4. If not, aside from what I described above am I missing any glaring issues that I would need to address to get a complete solution to this issue? Thanks, Aaron Reffett

1 0

(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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2011