On Feb 8, 2009, at 1:26 PM, Pierangelo Masarati wrote:
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?
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: ando@sys-net.it
-
mhardin＠symas.com