On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote: > [email protected] wrote: >> Some additional information: >> Some objects being returned from AD have very large multi-valued >> attributes (for example, member). AD is returning them in the >> ";range" format, but they are not getting past back-meta. For >> example, a direct search for the object in AD will return stuff >> like this: >> member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User >> Accounts,OU=Common,DC=my-company,DC=com >> but doing the same search through slapd/back-meta using the same >> credentials, the member attribute is not displayed at all. There >> are no attribute maps in place that would cause this. > > If this is the cause, then back-meta should try to register the > attribute name as a "proxied" attribute type, and slapd should be > unable to correctly decode it because it contains a "=". Back-meta > in the end should just ignore the whole attribute. >
Thanks, Pierangelo. That led me to ITS#5472 and several other postings about the same issue. In particular: > [Petter Reinholdtsen said] >> This notation is not handled by ldap_get_values(), and it return >> NULL, resulting in a group with zero members. > [Kurt Zielenga replied] > This is proper and well-intended behavior. You asked for values of > returned under the attribute description "member", not the (invalid) > attribute description "member;range=0-1499". Two attribute > descriptions which share the same attribute type do not necessarily > refer to the same attribute. This clearly explains the assertion pcache is reporting. Well-intended behavior or not, there is a problem here because pcache takes down the server whenever it encounters attribute values of this form. Given Kurt's later comments about the provenance and ancestry of this "standard", it seems to me the right thing for back-meta (and back- ldap, for that matter) to do might be to just make the attribute completely disappear. Appropriate messages output in debug mode or at a particular log level might announce the fact that the attribute is being disappeared. The pcache overlay, for its part, instead of asserting, might instead log a warning and refuse to cache the object. Sound reasonable? -Matt > 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] > ----------------------------------- >
