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: [EMAIL PROTECTED]
-----------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
