openldap-bugs January 2009

openldap-bugs@openldap.org

50 participants
201 discussions

Re: (ITS#5916) Allow alias dereferencing in search C API
by Kurt＠OpenLDAP.org 31 Jan '09

31 Jan '09

On Jan 31, 2009, at 11:21 AM, hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> ando(a)sys-net.it writes: >>>> Proxy backends use ldap_set_option(3) to set alias dereferencing >>>> when >>>> requested by a search operation (and do not clean it up >>>> afterwards, as >>>> far as I can tell). Since LDAP handlers are pooled and reused, >>>> this >>>> behavior is inherently broken. >>> I note you committed this with an ldap_int_* interface. >> >> Yes, that's because I needed it internally. > > I think ldap_pvt would make more sense. _int_ means internal to the library. _pvt_ means private to OpenLDAP Software. > I recall complaining about this deficiency in the API back in 1998, > when I > first wrote back-ldap. Alias deref has always been a part of the > protocol, but > it has always been missing from the API. Perplexing... Yes, of course, one might use the client control mechanism to add an ability to set deref on a call by call basis instead of introducing yet another function. > > >>> But it could >>> be useful outside OpenLDAP code too. >> >> Yes, that will probably be the next step. But to make it publicly >> available I should have called it ldap_search_ext2, or >> ldap_search_really_ext or something like that. I think we need to >> make >> it public based on demand and after a ballot on the name. > > Ok. > >>> Seems to me this is what client-side controls are for. Extending >>> the >>> client-side functionality without needing a new API. >> >> Well, since alias dereferencing is part of the protocol, I think >> using a >> client-side control is sort of an overkill :) > > Agreed. > > -- > -- 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#5916) Allow alias dereferencing in search C API
by hyc＠symas.com 31 Jan '09

31 Jan '09

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> Proxy backends use ldap_set_option(3) to set alias dereferencing when >>> requested by a search operation (and do not clean it up afterwards, as >>> far as I can tell). Since LDAP handlers are pooled and reused, this >>> behavior is inherently broken. >> I note you committed this with an ldap_int_* interface. > > Yes, that's because I needed it internally. I think ldap_pvt would make more sense. I recall complaining about this deficiency in the API back in 1998, when I first wrote back-ldap. Alias deref has always been a part of the protocol, but it has always been missing from the API. Perplexing... >> But it could >> be useful outside OpenLDAP code too. > > Yes, that will probably be the next step. But to make it publicly > available I should have called it ldap_search_ext2, or > ldap_search_really_ext or something like that. I think we need to make > it public based on demand and after a ballot on the name. Ok. >> Seems to me this is what client-side controls are for. Extending the >> client-side functionality without needing a new API. > > Well, since alias dereferencing is part of the protocol, I think using a > client-side control is sort of an overkill :) Agreed. -- -- 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#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 31 Jan '09

31 Jan '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Proxy backends use ldap_set_option(3) to set alias dereferencing when >> requested by a search operation (and do not clean it up afterwards, as >> far as I can tell). Since LDAP handlers are pooled and reused, this >> behavior is inherently broken. > > I note you committed this with an ldap_int_* interface. Yes, that's because I needed it internally. > But it could > be useful outside OpenLDAP code too. Yes, that will probably be the next step. But to make it publicly available I should have called it ldap_search_ext2, or ldap_search_really_ext or something like that. I think we need to make it public based on demand and after a ballot on the name. > Seems to me this is what client-side controls are for. Extending the > client-side functionality without needing a new API. Well, since alias dereferencing is part of the protocol, I think using a client-side control is sort of an overkill :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by h.b.furuseth＠usit.uio.no 31 Jan '09

31 Jan '09

ando(a)sys-net.it writes: > Proxy backends use ldap_set_option(3) to set alias dereferencing when > requested by a search operation (and do not clean it up afterwards, as > far as I can tell). Since LDAP handlers are pooled and reused, this > behavior is inherently broken. I note you committed this with an ldap_int_* interface. But it could be useful outside OpenLDAP code too. Seems to me this is what client-side controls are for. Extending the client-side functionality without needing a new API. -- Hallvard

1 0

(ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 31 Jan '09

31 Jan '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Proxy backends use ldap_set_option(3) to set alias dereferencing when requested by a search operation (and do not clean it up afterwards, as far as I can tell). Since LDAP handlers are pooled and reused, this behavior is inherently broken. The only reason for doing this is that the C API does not allow to explicitly define alias dereferencing when sending a search request. This is a feature request for an internal API extension (ldap_int_search*) that allows alias dereferencing. The current C API (essentially, ldap_search_ext*) should wrap the new one, until promoted to public. A patch is coming. p.

1 0

Re: (ITS#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by ando＠sys-net.it 31 Jan '09

31 Jan '09

jorge.perez(a)adaptia.net wrote: > When we have two slapds with a established meta connection between them and the > connection is reset, for example by a router, the next search query will always > be send with never in dereferencing. > > Steps to reproduce: > > - Established a meta connection between 2 slapds > - Reset the connection, for example with cutter > - Send a search dereferencing with something different to never. > - See the results are no dereferenced. Actually, I was reviewing this fix, and it seems that the code for alias dereferencing is inherently broken, essentially because the (C) API for alias dereferencing is broken. In fact, back-ldap and back-meta reuse and pool connections, so setting this parameter using ldap_set_option() will actually affect all (search) operations occurring simultaneously in an unprotected manner. I think this needs to be fixed. The simplest (and my favorite) solution would be to have back-ldap and back-meta discontinue aliasing support. Another option, which I do not consider particularly viable, is to separately pool connections with different alias dereferencing strategies Finally (my second favorite option) is to add a new C API for ldap_search* operations that allows to explicitly set the alias dereferencing parameter. This API does not need to be public, since it is mostly useful inside the proxy backends. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 30 Jan '09

30 Jan '09

Ok, but we should mention this somewhere like in the admin guide perhaps. ------Original Message------ From: Quanah Gibson-Mount Sender: To: Gavin Henry To: openldap-its(a)openldap.org Subject: Re: slapo-unique man page misleading (ITS#5908) Sent: 30 Jan 2009 19:13 --On Friday, January 30, 2009 7:08 PM +0000 Gavin Henry <ghenry(a)suretecsystems.com> wrote: > Ok, so this should be in the man page. Where else should this be listed > that affects other overlays? Eh, I'm not sure it should be in the man page. The point is, if you ever want guaranteed atomic writes, you have to use slapo-accesslog to serialize them. That's an issue that affects other LDAP servers as well. AS Pierangelo said: There is no guarantee of DSA-wide or even database-wide atomicity in write operations, including internal ones. This was never even intended to be in place. This is a known design limitation not only of slapo-unique, but also of slapd (and, I'd say, of LDAP itself). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: slapo-unique man page misleading (ITS#5908)
by quanah＠zimbra.com 30 Jan '09

30 Jan '09

--On Friday, January 30, 2009 7:08 PM +0000 Gavin Henry <ghenry(a)suretecsystems.com> wrote: > Ok, so this should be in the man page. Where else should this be listed > that affects other overlays? Eh, I'm not sure it should be in the man page. The point is, if you ever want guaranteed atomic writes, you have to use slapo-accesslog to serialize them. That's an issue that affects other LDAP servers as well. AS Pierangelo said: There is no guarantee of DSA-wide or even database-wide atomicity in write operations, including internal ones. This was never even intended to be in place. This is a known design limitation not only of slapo-unique, but also of slapd (and, I'd say, of LDAP itself). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 30 Jan '09

30 Jan '09

Ok, so this should be in the man page. Where else should this be listed that affects other overlays? ------Original Message------ From: Quanah Gibson-Mount Sender: To: Gavin Henry To: openldap-its(a)openldap.org Subject: Re: slapo-unique man page misleading (ITS#5908) Sent: 30 Jan 2009 19:04 --On Thursday, January 29, 2009 3:48 PM +0000 ghenry(a)suretecsystems.com wrote: >> Huh? slapo-unique only does internal searches. The writes are all user >> ops, >> and accesslog will serialize all of them. > > So, where does this leave us? If you want guaranteed atomic writes, use slapo-accesslog on your master to serialize them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: slapo-unique man page misleading (ITS#5908)
by quanah＠zimbra.com 30 Jan '09

30 Jan '09

--On Thursday, January 29, 2009 3:48 PM +0000 ghenry(a)suretecsystems.com wrote: >> Huh? slapo-unique only does internal searches. The writes are all user >> ops, >> and accesslog will serialize all of them. > > So, where does this leave us? If you want guaranteed atomic writes, use slapo-accesslog on your master to serialize them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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 January 2009