Manual Pages for UNIX Darwin command on man slapo-pcache

SLAPO-PCACHE(5) SLAPO-PCACHE(5)

NAME

slapo-pcache - proxycache overlay

SYNOPSIS

/etc/openldap/slapd.conf

DESCRIPTION

The ppccaacchhee overlay to ssllaappdd(8) allows caching of LDAP search requests (queries) in a local database. For an incoming query, the proxy cache determines its corresponding tteemmppllaattee. If the template was specified as

cacheable using the pprrooxxyytteemmppllaattee directive and the request is con-

tained in a cached request, it is answered from the proxy cache. Oth-

erwise, the search is performed as usual and cacheable search results are saved in the cache for use in future queries. A template is defined by a filter string and an index identifying a set of attributes. The tteemmppllaattee ssttrriinngg for a query can be obtained by removing assertion values from the RFC 2254 representation of its search filter. A query belongs to a template if its template string and

set of projected attributes correspond to a cacheable template. Exam-

ples of template strings are ((mmaaiill==)), ((||((ssnn==))((ccnn==)))), ((&&((ssnn==))((ggiivveenn-

NNaammee==)))). The config directives that are specific to the pprrooxxyyccaacchhee overlay can

be prefixed by pprrooxxyyccaacchhee-, to avoid conflicts with directives specific

to the underlying database or to other stacked overlays. This may be particularly useful for those directives that refer to the backend used for local storage. The following cache specific directives can be used to configure the proxy cache: oovveerrllaayy ppccaacchhee

This directive adds the proxy cache overlay to the current back-

end. The proxy cache overlay may be used with any backend but is intended for use with the llddaapp, mmeettaa, and ssqqll backends. pprrooxxyyccaacchhee <> <> <> <> <> The directive enables proxy caching in the current backend and sets general cache parameters. A backend will be used internally to maintain the cached entries. The chosen database will need to be configured as well, as shown below. Cache replacement is invoked when the cache size grows to entries and continues till the cache size drops below this size. should be equal to the number of following pprrooxxyyaattttrrsseett directives. Queries are cached only if

they correspond to a cacheable template (specified by the pprrooxx-

yytteemmppllaattee directive) and the number of entries returned is less than . Consistency check is performed every duration (specified in secs). In each cycle queries with expired "time to live(TTTTLL)" are removed. A sample cache configuration is: proxycache bbddbb 1100000000 11 5500 110000 pprrooxxyyccaacchheeqquueerriieess <> Specify the maximum number of queries to cache. The default is 10000. pprrooxxyyaattttrrsseett <> <> Used to associate a set of attributes with an . Each attribute set is associated with an integer from 0 to

-1. These indices are used by the pprrooxxyytteemmppllaattee

directive to define cacheable templates. pprrooxxyytteemmppllaattee <> <> <> [[<>]] Specifies a cacheable template and "time to live" (in sec) of queries belonging to the template. An optional can be used to specify that negative results (i.e., queries that returned zero entries) should also be cached for the specified number of seconds. Negative results are not cached by default.

rreessppoonnssee-ccaallllbbaacckk {{ hheeaadd || ttaaiill }}

Specifies whether the response callback should be placed at the

ttaaiill (the default) or at the hheeaadd (actually, wherever the stack-

ing sequence would make it appear) of the callback list. This affects how the overlay interacts with other overlays, since the proxycache overlay should be executed as early as possible (and thus configured as late as possible), to get a chance to return the cached results; however, if executed early at response, it

would cache entries that may be later "massaged" by other data-

bases and thus returned after massaging the first time, and before massaging when cached. There are some constraints: all values must be positive; <> must be less than or equal to <>; <> attribute sets SHOULD be defined by using the directive pprrooxxyyaattttrrsseett;

all attribute sets SHOULD be referenced by (at least) one pprrooxx-

yytteemmppllaattee directive; The following adds a template with filter string ((&&((ssnn==))((ggiivveennNNaammee==)))) and attributes mail, postaladdress, telephonenumber and a TTL of 1 hour. proxyattrset 00 mmaaiill ppoossttaallaaddddrreessss tteelleepphhoonneennuummbbeerr proxytemplate ((&&((ssnn==))((ggiivveennNNaammee==)))) 00 33660000 Directives for configuring the underlying database must also be given, as shown here: directory /var/tmp/cache cachesize 100 Any valid directives for the chosen database type may be used. Indexing

should be used as appropriate for the queries being handled. In addi-

tion, an equality index on the qquueerryyiidd attribute should be configured, to assist in the removal of expired query data. CCAAVVEEAATTSS Caching data is prone to inconsistencies because updates on the remote server will not be reflected in the response of the cache at least (and at most) for the duration of the pprrooxxyytteemmppllaattee TTTTLL. The remote server should expose the oobbjjeeccttCCllaassss attribute because the underlying database that actually caches the entries may need it for optimal local processing of the queries. Another potential (and subtle) inconsistency may occur when data is

retrieved with different identities and specific per-identity access

control is enforced by the remote server. If data was retrieved with an identity that collected only partial results because of access rules enforcement on the remote server, other users with different access privileges on the remote server will get different results from the remote server and from the cache. If those users have higher access privileges on the remote server, they will get from the cache only a subset of the results they would get directly from the remote server; but if they have lower access privileges, they will get from the cache a superset of the results they would get directly from the remote server. Either occurrence may or may not be acceptable, based on the security policy of the cache and of the remote server. It is important to note that in this case the proxy is violating the security of the remote server by disclosing to an identity data that was collected by another identity. For this reason, it is suggested that, when using

bbaacckk-llddaapp, proxy caching be used in conjunction with the identity

assertion feature of ssllaappdd-llddaapp(5) (see the iiddaasssseerrtt-bbiinndd and the

iiddaasssseerrtt-aauutthhzz statements), so that remote server interrogation occurs

with a vanilla identity that has some relatively high sseeaarrcchh and rreeaadd access privileges, and the "real" access control is delegated to the proxy's ACLs. Beware that since only the cached fraction of the real datum is available to the cache, it may not be possible to enforce the same access rules that are defined on the remote server. When security is a concern, cached proxy access must be carefully tailored. FILES /etc/openldap/slapd.conf default slapd configuration file