[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5927) assertion error when using pcache



mhardin@symas.com wrote:
> On Feb 7, 2009, at 9:21 AM, ando@sys-net.it wrote:
> 
>> mhardin@symas.com wrote:
>>> Sorry for the out-of-sequence reply. I'll test and let you know  
>>> what I
>>> find.
>> No problem.  Note that if this is the cause of this issue, and, in any
>> case, if you have some "range" attributes in your response, you still
>> have an issue with those values.
> 
> Yes. I'm not sure what to do about them in the medium term. Not having  
> slapd crash is a good first step, though :P

Are you confirming that the original issue is fixed?

>> It seems that, in the spirit of
>> OpenLDAP software, we could be relatively liberal in accepting those
>> values provided we are able to consolidate them in a single entry with
>> no ranges.  Apparently, what the proxies could do is:
>>
>> - whenever a range is obtained in a response
>> 	- iteratively query the server again for the same entry,
>> 	- requesting only that attribute for the next block of vals
>> 	- incrementally build the set of values
>> 	- return the consolidated entry
>>
>> This MUST be configurable, and documented as a nasty, expensive and
>> unnecessary hack.
>>
> 
> I had thought it might be possible to craft this functionality as an  
> overlay (we could call it "derange" :P), but I think you're right- it  
> is more appropriate that it be something configurable in back-meta and  
> back-ldap.

You can't handle that with an overlay, since the message containing this 
type of response is received by the proxy backends and would fail 
parsing unless handled there :).

> This functionality is particularly interesting when one  
> considers using Howard's nss_ov in conjunction with pcache and back- 
> ldap communicating with directory servers that were never intended to  
> handle the high loads that Unix/Linux name services can place on a  
> directory server ;-)
> 
> The high cost of the iterative searches might be mitigated through use  
> of pcache. I'm thinking the searches to consolidate the ranged  
> attributes would happen anyway, so better to do them in the proxy and  
> cache the results than make each individual client have to do them.

Yes.  Another possible issue is that we'd probably need to work a 
symmetric solution in those cases where a request needs values to be 
broken in ranges in order to be accepted by AD.

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@sys-net.it
-----------------------------------