On Feb 8, 2009, at 1:26 PM, Pierangelo Masarati wrote: > [email protected] wrote: >> On Feb 7, 2009, at 9:21 AM, [email protected] wrote: >>> [email protected] 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?
Unfortunately not. The morning I tested the fix you checked into HEAD and still got an assertion error in pcache at the same point when caching group objects that contain range specifiers. I have core files and would be happy to provide additional information if you need it. > > >>> 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 :). So I've learned :) > > >> 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. Ugh. I suppose so, although my interest in that is relatively low at this point. > > > p. > > -Matt > 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: [email protected] > ----------------------------------- >
