[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? >> 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: [email protected] -----------------------------------
