Re: (ITS#5628) dereferencing user with translucent overlay
by akreffett＠cert.org
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
10 years, 8 months
(ITS#6876) Ldaps fault tolerance not working
by koshikov＠gmail.com
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.
10 years, 8 months
Fix for (ITS#6872)
by cmikk＠qwest.net
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
10 years, 8 months
Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by richm＠stanfordalumni.org
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
>
>
10 years, 8 months
Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by rhafer＠suse.de
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
10 years, 8 months
Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by hyc＠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.
>
> 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/
10 years, 8 months
Re: (ITS#6870) Undefined reference to ber_* with 2.4.24
by Ralf Haferkamp
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
10 years, 8 months
Re: (ITS#6874) slapd crashes while modifying a database
by rhafer＠suse.de
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
10 years, 8 months
Re: (ITS#6875) openldap distribution list
by Ralf Haferkamp
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.
10 years, 8 months
