[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
-----------------------------------