Provided by:
slapd_2.4.15-1ubuntu3_i386 
NAME
slapo-pcache - proxycache overlay to slapd
SYNOPSIS
/etc/ldap/slapd.conf
DESCRIPTION
The pcache overlay to slapd(8) allows caching of LDAP search requests
(queries) in a local database. For an incoming query, the proxy cache
determines its corresponding template. If the template was specified as
cacheable using the proxytemplate directive and the request is
contained in a cached request, it is answered from the proxy cache.
Otherwise, 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 template string for a query can be obtained by
removing assertion values from the RFC 4515 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.
Examples of template strings are (mail=), (|(sn=)(cn=)),
(&(sn=)(givenName=)).
The config directives that are specific to the proxycache overlay can
be prefixed by proxycache-, 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:
overlay pcache
This directive adds the proxy cache overlay to the current
backend. The proxy cache overlay may be used with any backend
but is intended for use with the ldap, meta, and sql backends.
proxycache <database> <max_entries> <numattrsets> <entry_limit>
<cc_period>
The directive enables proxy caching in the current backend and
sets general cache parameters. A <database> 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
<max_entries> entries and continues till the cache size drops
below this size. <numattrsets> should be equal to the number of
following proxyattrset directives. Queries are cached only if
they correspond to a cacheable template (specified by the
proxytemplate directive) and the number of entries returned is
less than <entry_limit>. Consistency check is performed every
<cc_period> duration (specified in secs). In each cycle queries
with expired "time to live(TTL)" are removed. A sample cache
configuration is:
proxycache bdb 10000 1 50 100
proxyattrset <index> <attrs...>
Used to associate a set of attributes <attrs..> with an <index>.
Each attribute set is associated with an integer from 0 to
<numattrsets>-1. These indices are used by the proxytemplate
directive to define cacheable templates. A set of attributes
cannot be empty. A set of attributes can contain the special
attributes "*" (all user attributes), "+" (all operational
attributes) or both; in the latter case, any other attribute is
redundant and should be avoided for clarity. A set of
attributes can contain "1.1" as the only attribute; in this
case, only the presence of the entries is cached.
proxycachequeries <queries>
Specify the maximum number of queries to cache. The default is
10000.
proxycheckcacheability { TRUE | FALSE }
Check whether the results of a query being cached can actually
be returned from the cache by the proxy DSA. When enabled, the
entries being returned while caching the results of a query are
checked to ensure consistency with the schema known to the proxy
DSA. In case of failure, the query is not cached. By default,
the check is off.
proxysavequeries { TRUE | FALSE }
Specify whether the cached queries should be saved across
restarts of the caching proxy, to provide hot startup of the
cache. Only non-expired queries are reloaded. The default is
FALSE.
CAVEAT: of course, the configuration of the proxycache must not
change across restarts; the pcache overlay does not perform any
consistency checks in this sense. In detail, this option should
be disabled unless the existing proxyattrset and proxytemplate
directives are not changed neither in order nor in contents. If
new sets and templates are added, or if other details of the
pcache overlay configuration changed, this feature should not be
affected.
proxytemplate <template_string> <attrset_index> <ttl> [<negttl>
[<limitttl>]]
Specifies a cacheable template and "time to live" <ttl> of
queries belonging to the template. An optional <negttl> can be
used to specify that negative results (i.e., queries that
returned zero entries) should also be cached for the specified
amount of time. Negative results are not cached by default
(<negttl> set to 0). An optional <limitttl> can be used to
specify that results hitting a sizelimit should also be cached
for the specified amount of time. Results hitting a sizelimit
are not cached by default (<limitttl> set to 0).
response-callback { head | tail }
Specifies whether the response callback should be placed at the
tail (the default) or at the head (actually, wherever the
stacking 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 databases and thus returned after massaging the first
time, and before massaging when cached.
There are some constraints:
all values must be positive;
<entry_limit> must be less than or equal to <max_entries>;
<numattrsets> attribute sets SHOULD be defined by using the
directive proxyattrset;
all attribute sets SHOULD be referenced by (at least) one
proxytemplate directive;
The following adds a template with filter string (&(sn=)(givenName=))
and attributes mail, postaladdress, telephonenumber and a TTL of 1
hour.
proxyattrset 0 mail postaladdress telephonenumber
proxytemplate (&(sn=)(givenName=)) 0 3600
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
addition, an equality index on the queryid attribute should be
configured, to assist in the removal of expired query data.
CAVEATS
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 proxytemplate TTL.
The remote server should expose the objectClass attribute because the
underlying database that actually caches the entries may need it for
optimal local processing of the queries.
The proxy server should contain all the schema information required for
caching. Significantly, it needs the schema of attributes used in the
query templates. If the objectClass attribute is used in a query
template, it needs the definition of the objectClasses of the entries
it is supposed to cache. It is the responsibility of the proxy
administrator to keep the proxy schema lined up with that of the
proxied server.
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
back-ldap, proxy caching be used in conjunction with the identity
assertion feature of slapd-ldap(5) (see the idassert-bind and the
idassert-authz statements), so that remote server interrogation occurs
with a vanilla identity that has some relatively high search and read
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/ldap/slapd.conf
default slapd configuration file
SEE ALSO
slapd.conf(5), slapd-config(5), slapd-ldap(5), slapd-meta(5),
slapd-sql(5), slapd(8).
AUTHOR
Originally implemented by Apurva Kumar as an extension to back-meta;
turned into an overlay by Howard Chu.