openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 03 Aug '09

03 Aug '09

Jim van Keulen wrote: > hyc(a)symas.com wrote: > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. > > If it was fixed in January, why does openldap-2.4.16 (20090411) still > exhibit the described behaviour? I don't believe what you're seeing now is due to the situation Ando described. -- -- 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#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 03 Aug '09

03 Aug '09

Confirmed working. Also experienced (possibly unrelated?) segfault on slapadd. hyc(a)symas.com wrote: > Fixed now in CVS HEAD. > > mbuschman(a)cashnetusa.com wrote: > >> Full_Name: Marshall Buschman >> Version: 2.4.17 >> OS: Debian Etch >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (38.98.177.132) >> >> > > >> I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the >> autogroup overlay, and I get the following error when I do an ldapsearch: >> >> $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com >> # extended LDIF >> ... >> # search result >> search: 2 >> result: 53 Server is unwilling to perform >> text: operation not supported within namingContext >> >> Relevant config: >> ---------------------------------------------- >> moduleload autogroup >> >> database bdb >> suffix "dc=cashnetusa,dc=com" >> >> overlay autogroup >> autogroup-attrset groupOfURLs memberURL member >> ---------------------------------------------- >> >> OpenLDAP does start normally without the overlay. >> >> > > >

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 03 Aug '09

03 Aug '09

hyc(a)symas.com wrote: > The filter behavior you're describing was noted in ITS#5756, fixed in January. If it was fixed in January, why does openldap-2.4.16 (20090411) still exhibit the described behaviour? regards, Jim van Keulen

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> masarati(a)aero.polimi.it wrote: >> As far as I recall, this is a known issue, although I could not locate >> early postings discussing this issue. What happens is that proxy cache >> makes use of the first item in the filter to discriminate between >> responses. In your filter template, the first item is the objectClass >> equality, which means that any filter with that objectClass value, >> regardless of the uid value, is treated as a duplicate of the first one. >> If you reverse the order of the equality filters you'll get the expected >> behavior. There should be another open ITS for this issue, but I can't >> locate it right now. > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. That's exactly the ITS I was looking for. Apparently I didn't use the right keywords, or just overlooked it. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 03 Aug '09

03 Aug '09

masarati(a)aero.polimi.it wrote: > As far as I recall, this is a known issue, although I could not locate > early postings discussing this issue. What happens is that proxy cache > makes use of the first item in the filter to discriminate between > responses. In your filter template, the first item is the objectClass > equality, which means that any filter with that objectClass value, > regardless of the uid value, is treated as a duplicate of the first one. > If you reverse the order of the equality filters you'll get the expected > behavior. There should be another open ITS for this issue, but I can't > locate it right now. The filter behavior you're describing was noted in ITS#5756, fixed in January. -- -- 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

(ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

[Resending because I forgot the ITS number in the subject] I have a simple prototype that on add/modrdn populates/maintains an attribute (rdnValue) with the distinguished values of the naming attributes of the RDN. While doing this, it also checks for uniqueness of the rdnValue value within siblings. You can find it here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c> Please test and comment. I hope it does what intended. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

Please keep replies to the list, so the issue can be tracked. > Thank you for your help. Reversal of the filters is easily done. > However the searches I try to cache are taken from Samba. I have no > control over the way searches are done in Samba. I understand from the > documentation that the search template must be exact the same as the > search filter to be cachable. So this solution does not solve my > problem, I guess. Clear. I understand this issue needs to be fixed somehow. The reason for just using the first simple filter in composite filters is probably related to the fact it did not require extensive data manipulation, as probably would the definition of a criterion that accounts for the whole filter. The ITS remains open as a software bug. p.

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The ITS remains open, as the man page clearly needs to be improved to avoid any misunderstanding. An example would probably suffice. p. > masarati(a)aero.polimi.it wrote: >> The "strict" and the "ignore" keywords must be part of a single >> argument. >> In fact, the unique_uri statement only takes one argument, consisting of >> the optional "strict" and "ignore" keywords followed by a list of URIs. >> In order to be recognized as a single argument, the whole thing needs to >> be included in double quotes, like >> >> unique_uri "strict >> ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" >> >> p. > ahh I understand - this in mind the manpage makes sense, too. ;-) > > unique_uri <[strict ][ignore ]URI[URI...]...> > > Thanks a lot for the clarification! > > > >

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by daniel＠pluta.biz 03 Aug '09

03 Aug '09

masarati(a)aero.polimi.it wrote: > The "strict" and the "ignore" keywords must be part of a single argument. > In fact, the unique_uri statement only takes one argument, consisting of > the optional "strict" and "ignore" keywords followed by a list of URIs. > In order to be recognized as a single argument, the whole thing needs to > be included in double quotes, like > > unique_uri "strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" > > p. ahh I understand - this in mind the manpage makes sense, too. ;-) unique_uri <[strict ][ignore ]URI[URI...]...> Thanks a lot for the clarification!

1 0

Re: (ITS#6172) Crash with baseObject in back-sql
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> openssl(a)mkarcher.dialup.fu-berlin.de wrote: > >> slapd gets terminated by libc with an "invalid free" error message when >> using >> the baseObject configuration option (whether with or without file) at >> the time >> of the first query. >> >> This is caused by freeing an entry using "free" that has been allocated >> using >> "entry_dup". This does not match (any more?). Essentially what the code >> was >> trying to to is to duplicate the sql_baseObject to bsi_e. The fix I >> suggest adds >> a function "entry_dup_to" to slapd so that backends can do this >> operation >> cleanly without having to create a temporary dynamic object there is no >> obvious >> clean way to get rid of. > > I'd rather have a function that returns the entry struct to the pool > without calling entry_clean(), to avoid as much as possible code > duplication. In any case, good catch. All in all, I favored using your patch as is. It's now in HEAD, please test. Thanks, p.

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