[Date Prev][Date Next]
Re: (ITS#5927) assertion error when using pcache
Sorry for the out-of-sequence reply. I'll test and let you know what I
On Feb 7, 2009, at 8:53 AM, email@example.com wrote:
> On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote:
>> firstname.lastname@example.org 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
>>> 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?
>> Ing. Pierangelo Masarati
>> OpenLDAP Core Team
>> SysNet s.r.l.
>> via Dossi, 8 - 27100 Pavia - ITALIA
>> Office: +39 02 23998309
>> Mobile: +39 333 4963172
>> Fax: +39 0382 476497
>> Email: email@example.com