openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(ITS#5774) Modifications not saved on file by back-ldif (on Windows)
by emmanuel.duru＠atosorigin.com 27 Oct '08

27 Oct '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) On Windows, modifications are not saved on file by back-ldif. This is the case for example with cn=config. Reading back-ldif code I see that when modifying an entry, back-ldif creates a temporary file containing the modified entry, and then renames the temporary file to the entry file. On Windows, renaming a file to an already existing file does not work, it gets an ERROR_ALREADY_EXISTS error (183), error code which is ignored by back-ldif.

1 0

RE: (ITS#5769) Behaviour of ldap_sort_entries on a multivalued attribute
by emmanuel.duru＠atosorigin.com 27 Oct '08

27 Oct '08

OK, forget it. > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : jeudi 23 octobre 2008 16:13 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5769) Behaviour of ldap_sort_entries on a multivalued > attribute > > emmanuel.duru(a)atosorigin.com wrote: > > > Currently, ldap_sort_entries when used with a multivalued attribute > assumes that > > the attribute values are in the same order for all the entries. It would > be > > better if this was not the case. > > For example, I would like to use ldap_sort_entries to sort entries > according to > > objectclass attribute, so as to group entries by kind of objects. > > Let be 3 entries: > > ==>cn=n1, objectclass: person, organizationalperson > > ==>ou=ou1, objectclass: organizationalunit > > ==>cn=n2, objectclass: organizationalperson, person > > result of ldap_sort_entries on objectclass: n2, ou1, n1, whereas I > expected n1, > > n2, ou1. > > ldap_sort_entries() is deprecated. As a consequence, I would not expect > any activity on it. It is the client's duty to sort the way it likes. > > 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#5773) bi_entry_get_rw() and overlays issue
by ando＠sys-net.it 26 Oct '08

26 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I think bi_entry_get_rw() needs work. > > Or maybe phase it out in favor of some other call? > >> In fact, as also discussed in ITS#5628, callers either return the >> entry or have no means to modify the arguments of the request. > > It has more troubles than that. See e.g. the notes about passing rw=1 > (write) to it here: > http://www.openldap.org/lists/openldap-devel/200803/msg00055.html > And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which > says to pass an rw=1 argument to bi_entry_release_rw(). Well, I see many places where an entry needs to be fetched. Typically, it needs to be done read-only. So the difference between bi_entry_get_ro() and an internal search is that if we are fine with the entry in-cache, we save lots of manipulation. However this might no longer suffice when overlays muck with the entry (like slapo-rwm). Moreover, when overlays are present, I see the need to: 1) run it like it came from outside, going thru all the overlays 2) go straight to the underlying database 3) go thru overlays starting at some point (e.g. when called from inside an overlay under the assumption the entry is fetched as that overlay would see it, so with only any possible mucking from overlays layered deeper than the caller). This probably needs to modify the way callbacks are actually called, allowing some "after self" feature in playing not just the overlay list, but also the response (and the cleanup). 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#5773) bi_entry_get_rw() and overlays issue
by h.b.furuseth＠usit.uio.no 26 Oct '08

26 Oct '08

ando(a)sys-net.it writes: > I think bi_entry_get_rw() needs work. Or maybe phase it out in favor of some other call? > In fact, as also discussed in ITS#5628, callers either return the > entry or have no means to modify the arguments of the request. It has more troubles than that. See e.g. the notes about passing rw=1 (write) to it here: http://www.openldap.org/lists/openldap-devel/200803/msg00055.html And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which says to pass an rw=1 argument to bi_entry_release_rw(). -- Hallvard

1 0

(ITS#5773) bi_entry_get_rw() and overlays issue
by ando＠sys-net.it 26 Oct '08

26 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I think bi_entry_get_rw() needs work. In fact, as also discussed in ITS#5628, callers either return the entry or have no means to modify the arguments of the request. This can be critical, for example, when slapo-rwm(5) is involved. In many cases, it might need to rewrite the ndn, or to map the attribute and the objectClass. However, this cannot be done without returning the entry, and thus directly performing a bi_entry_get_rw() to the original database, bypassing any further stacked overlay. Probably, the API of this call, and that of bi_entry_release_rw() should be modified in conformity to that of BI_op_func, possibly adding further structs to the main union. I'm not going to implement this right now, as I fear I might have overlooked something. Moreover, this change would have significant impact on existing code, since these calls are widely used. In the meanwhile I'm adding support for these two calls to slapo-rwm(5) along the above lines. p.

1 0

(ITS#5772) slapo-rwm does not normalize rewritten DN-valued attributes
by ando＠sys-net.it 26 Oct '08

26 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Only a_vals are rewritten; this is not an issue when used with back-ldap, but can be an issue when used with back-relay and in all cases overlays are expected to interact. A fix is coming. p.

1 0

(ITS#5771) autogroup overlay prevent slapd to works correctly
by Guillaume.Rousse＠inria.fr 25 Oct '08

25 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.224.237.5) Enabling the autogroup overlay make slapd unwilling to work: [guillaume@oberkampf ~]$ ldapsearch -LLL -x Server is unwilling to perform (53) Additional information: operation not supported within namingContext No need for dynamic entry in the DIT to trigger the error, just configuring the overlay as documented in its README file is enough: overlay autogroup autogroup-attrset groupOfURLs memberURL member

1 0

(ITS#5770) Unaligned BerElements
by h.b.furuseth＠usit.uio.no 24 Oct '08

24 Oct '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard This code fails to align the BerElement: char berbuf[LBER_ELEMENT_SIZEOF]; BerElement *ber = (BerElement *)berbuf; in clients/tools/common.c, servers/slapd/overlays/ppolicy.c. Fixing.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by h.b.furuseth＠usit.uio.no 24 Oct '08

24 Oct '08

Howard Chu writes: >> BTW, possibly "deref(erence)" is a confusing name for the control, >> since it is apparently not related to aliases. > > Oh please. Nor is it related to referrals or search references, and yet > these are all references, and "dereference" applies to them equally. Actually the docs do use different names for that - "follow"/"chase" referrals, or "chain" on the server side, vs. "deref"erence aliases. So if this is a new operation, I figured it wouldn't hurt to look for another word for whatever it is doing. But sure, it's no big thing. And in that regard it can already be a bit confusing that it's aliases and not referrals & search references which are "deref"erenced. -- Hallvard

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 24 Oct '08

24 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The current specification is formalized in a comment in >> overlays/deref.c; I intend to improve it and post it at >> <http://www.openldap.org/faq/data/cache/1469.html>. > > You've specified the syntax, but not the semantics. I don't see > any mention there of what this control does, though I suppose the > examples help if one knows what a GUID and a SID are. I will, in a more detailed document. > BTW, possibly "deref(erence)" is a confusing name for the control, > since it is apparently not related to aliases. "Dereference" means take DN-valued attributes, lookup the requested attributes from their entry and present the whole thing (name + attrs) as the control value. So ldapsearch -E deref=member:cn,sn will return a control value consisting in sequences of member values contained in the search, plus the corresponding values of cn and sn. 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

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