.TH SLAPO-PCACHE 5 "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" Copyright 1998-2005 The OpenLDAP Foundation, All Rights Reserved.
+.\" Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved.
.\" Copying restrictions apply. See the COPYRIGHT file.
.\" Copyright 2001, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
.\" $OpenLDAP$
The following cache specific directives can be used to configure the proxy
cache:
.TP
-.B overlay proxycache
-This directive adds the proxycache overlay to the current backend. The
-proxycache overlay may be used with any backend but is intended for use
+.B 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
.BR ldap ,
.BR meta ,
.RS
proxycache \fBbdb 10000 1 50 100\fP
.RE
+.TP
+.B proxycachequeries <queries>
+Specify the maximum number of queries to cache. The default is 10000.
+
.TP
.B proxyattrset <index> <attrs...>
Used to associate a set of attributes <attrs..> with an <index>. Each attribute
used by the \fBproxytemplate\fP directive to define cacheable templates.
.TP
-.B proxytemplate <template_string> <attrset_index> <ttl>
+.B proxytemplate <template_string> <attrset_index> <ttl> [<negttl>]
Specifies a cacheable template and "time to live" (in sec) <ttl> of queries
-belonging to the template.
+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 number of seconds. Negative
+results are not cached by default.
+
+.TP
+.B response-callback { head | tail }
+Specifies whether the response callback should be placed at the
+.B tail
+(the default) or at the
+.B 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 \fIafter\fP massaging the first
+time, and \fIbefore\fP massaging when cached.
+
+.TP
+There are some constraints:
+
+all values must be positive;
+
+.B <entry_limit>
+must be less than or equal to
+.BR <max_entries> ;
+
+.B <numattrsets>
+attribute sets SHOULD be defined by using the directive
+.BR proxyattrset ;
+
+all attribute sets SHOULD be referenced by (at least) one
+.B proxytemplate
+directive;
.LP
-The following adds a template with filter string \fB((&sn=)(givenName=))\fP
+The following adds a template with filter string \fB(&(sn=)(givenName=))\fP
and attributes mail, postaladdress, telephonenumber and a TTL of 1 hour.
.LP
.RS
.fi
.RE
.LP
-Any valid directives for the chosen database type may be used.
+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 \fBqueryid\fP attribute should be configured, to
+assist in the removal of expired query data.
+.SH 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
+.B proxytemplate
+.BR TTL .
+
+The remote server should expose the
+.B objectClass
+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
+.BR back-ldap ,
+proxy caching be used in conjunction with the
+.I identity assertion
+feature of
+.BR slapd-ldap (5)
+(see the
+.B idassert-bind
+and the
+.B idassert-authz
+statements), so that remote server interrogation occurs with a vanilla identity
+that has some relatively high
+.B search
+and
+.B 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.
.SH FILES
+
.TP
ETCDIR/slapd.conf
default slapd configuration file
projects / openldap / blobdiff