[Pkg-openldap-devel] Bug#497697: Bug#497697: closed by Steve Langasek <vorlon at debian.org> (Re: Bug#497697: slapd - pcache does not return cached entries [FIXED])

[Pierangelo Masarati]

Bastian Blank wrote:
> On Wed, Sep 03, 2008 at 03:00:59PM -0700, Quanah Gibson-Mount wrote:
>>> This is fixed upstream, and will be in OpenLDAP 2.4.12.
>> Or to be more concise, the documentation has been updated for 
>> slapd-ldap(5) and slapd-meta(5) to more clearly note the requirement for 
>> the schema info, etc.
> 
> The ldap backend works fine even if the schema entries are missing and
> it only have to push the data through to the client. (It looks a little
> bit weird, well.)

Not entirely true: you can't use undefined attributes/objectClasses in 
filters or in request DN (and, I guess, in any schema-related request 
bit).  If any undefined schema item appears in the response, it gets 
mapped as "proxied", which means it remains dangling (no syntax, no 
matching rules, no inheritance).

> For the pcache overlay it seems to be a "must" to have all object
> classes available which may ever show up. And this needs to be
> documented there.

In the given case, as far as I could tell, since the proxy template was 
(objectClass=), the local database is being searched for values of the 
objectClass attribute.  An undefined objectClass causes the local search 
to fail.

> Anyway, may it possible to filter all unknown attributes/objectclasses
> in the ldap backend at once?

Yes and no.  It used to be like that, but since users requested for as 
much data as possible to be returned, the "proxied" feature was added. 
Perhaps it should be optional.  Consider that without that feature, you 
wouldn't get anything from the proxy, which sounds a bit radical.  The 
cache needs to be stricter than the proxy since it needs to perform 
essential schema-related operations on data, like searching for cached 
entries.  Hence, the different requirements on the schema.

>> Other fixes for slapo-pcache behavior when things are misconfigured may 
>> be made, but that has not yet happened.
> 
> IMHO it have to ignore the complete local search result if it gets
> unexpected errors from a match function.

The patch I just committed does exactly that: as soon as an entry, 
within a query response, would not match the filter when applied 
locally, the entire query is not catched.  This causes a little 
performance degradation because the filter also needs to be applied by 
the proxy.  The query will always be answered resorting to the remote 
server, unless the proxy administrator fixes the schema.

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 at sys-net.it
-----------------------------------