|SLAPO-PCACHE(5)||File Formats Manual||SLAPO-PCACHE(5)|
slapo-pcache - proxy cache overlay to slapd
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 pcacheTemplate 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 pcache overlay can be prefixed by pcache-, 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:
CAVEAT: of course, the configuration of the proxy cache 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 pcacheAttrset and pcacheTemplate 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.
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 pcacheAttrset;
all attribute sets SHOULD be referenced by (at least) one pcacheTemplate directive;
The following adds a template with filter string (&(sn=)(givenName=)) and attributes mail, postaladdress, telephonenumber and a TTL of 1 hour.
pcacheAttrset 0 mail postaladdress telephonenumber pcacheTemplate (&(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 pcacheQueryid attribute should be configured, to assist in the removal of expired query data.
The configuration keywords have been renamed and the older form is deprecated. These older keywords are still recognized but may disappear in future releases.
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 pcacheTemplate TTL. These inconsistencies can be minimized by careful use of the TTR.
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.
slapd.conf(5), slapd-config(5), slapd-ldap(5), slapd-meta(5), slapd-sql(5), slapd(8).
Originally implemented by Apurva Kumar as an extension to back-meta; turned into an overlay by Howard Chu.