[Date Prev][Date Next]
RE: Proxy cache extension for OpenLDAP
At 05:39 AM 2002-09-09, Apurva Kumar wrote:
>The suggestion to use callback facility to support all the backends without
>modifying their codes can save a lot of work. However I am trying to figure
>out how to do the following operations required in the cache with this
>1) adding an entry without a parent.
>2) deleting an entry with children (without deleting the children).
>3) making a search with the search base not in the cache.
Sounds like just a few checks need to be disabled when the
caller is a proxy. An Operation flag could be used to
disable the checks... and a Backend flag could be used to
indicate the backend supports disabling the checks...
(sounds a lot like an "internal" control).
This may not be the best approach, just food for thought...
>For LDBM backend I could achieve the above by implementing three
>additional interfaces for adding/merging, searching and removing. I am not
>sure if all of these can be taken care of by the existing interfaces for
There is also a "tool" interface... but its not intended to
be used by slapd (as the tool interface is not thread safe).
>1) can probably be achieved by adding as root. For 3) the only solution I
>could think of was to use the backend's suffix as the search base for all
>the cache searches and filter out the entries not in the subtree using the
>callback function for send_search_entry. This is not very efficient.
>Would greatly appreciate any help in solving this problem.
>Research Staff Member,
>IBM India Research Lab
> "Howard Chu"
> <email@example.com> To: Apurva Kumar/India/IBM@IBMIN, <openldap-devel@OpenLDAP.org>
> Sent by: cc:
> owner-openldap-devel@O Subject: RE: Proxy cache extension for OpenLDAP
> 09/06/02 03:38 PM
>> -----Original Message-----
>> From: Apurva Kumar [mailto:firstname.lastname@example.org]
>> LDAP proxy cache docs in HTML.
>Thanks. It's a fascinating idea. The effect of ACLs on cached results isn't
>considered though; I guess you assume that all clients of the proxy will
>equal privileges on the remote server. (That's a fair enough assumption for
>many scenarios, it just needs to be stated.)
>You can implement your cache_backend APIs without directly modifying
>back-ldbm. Look at the callback facility, see backglue.c for an idea of how
>to use it. If you use the callback approach that backglue uses, your cache
>can interface to any of the existing backends without needing to modify
>code in any way. sasl.c and saslauthz.c also contain a number of examples
>how to perform searches using callbacks to execute a variety of different
>operations. (This callback facility is very powerful. We used it
>in Connexitor to do a lot of things that normal X.500-based directories
>do.) I would very much like to see a version of this code that doesn't rely
>on directly extending back-ldbm or any other backends (besides back-ldap).
>Also, there should be some kind of cache aging parameter to eliminate stale
>data from the cache. A trickle-refresh scheme might be interesting as well,
>but that's probably not necessary right away.
>It's a very good effort. I think the query containment and query template
>approach makes sense. Hopefully some more folks will examine this patch and
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support