[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5927) assertion error when using pcache
Sorry for the out-of-sequence reply. I'll test and let you know what I
find.
Cheers,
-Matt
On Feb 7, 2009, at 8:53 AM, mhardin@symas.com wrote:
> On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote:
>
>> mhardin@symas.com 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: ando@sys-net.it
>> -----------------------------------
>>
>
>