]> git.sur5r.net Git - openldap/blob - doc/man/man5/slapo-pcache.5
ITS#7928 fix syncprov abandon cleanup
[openldap] / doc / man / man5 / slapo-pcache.5
1 .TH SLAPO-PCACHE 5 "RELEASEDATE" "OpenLDAP LDVERSION"
2 .\" Copyright 1998-2014 The OpenLDAP Foundation, All Rights Reserved.
3 .\" Copying restrictions apply.  See the COPYRIGHT file.
4 .\" Copyright 2001, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
5 .\" $OpenLDAP$
6 .SH NAME
7 slapo\-pcache \- proxy cache overlay to slapd
8 .SH SYNOPSIS
9 ETCDIR/slapd.conf
10 .SH DESCRIPTION
11 The
12 .B pcache
13 overlay to
14 .BR slapd (8)
15 allows caching of LDAP search requests (queries) in a local database.
16 For an incoming query, the
17 proxy cache determines its corresponding \fBtemplate\fP. If the template
18 was specified as cacheable using the \fBpcacheTemplate\fP directive
19 and the request is contained in a cached request, it is answered from 
20 the proxy cache.
21 Otherwise, the search is performed as usual and cacheable search results 
22 are saved in the cache for use in future queries.
23 .LP
24
25 A template is defined by a filter string and an index identifying a set of
26 attributes. The \fBtemplate string\fP for a query can be obtained by
27 removing assertion values from the RFC 4515 representation of its search
28 filter. A query belongs to a template if its template string and set of
29 projected attributes correspond to a cacheable template.
30 Examples of template strings are \fB(mail=)\fP, \fB(|(sn=)(cn=))\fP,
31 \fB(&(sn=)(givenName=))\fP.
32
33 .LP 
34 The config directives that are specific to the
35 .B pcache
36 overlay can be prefixed by
37 .BR pcache\- ,
38 to avoid conflicts with directives specific to the underlying database
39 or to other stacked overlays.  This may be particularly useful for those
40 directives that refer to the backend used for local storage.
41 The following cache specific directives can be used to configure the proxy
42 cache: 
43 .TP
44 .B overlay pcache
45 This directive adds the proxy cache overlay to the current backend. The
46 proxy cache overlay may be used with any backend but is intended for use
47 with the
48 .BR ldap ,
49 .BR meta ,
50 and
51 .BR sql
52 backends. Please note that the underlying backend must have a configured
53 .BR rootdn.
54 .TP
55 .B pcache <database> <max_entries> <numattrsets> <entry_limit> <cc_period> 
56 The directive enables proxy caching in the current backend and sets general
57 cache parameters. A <database> backend will be used internally to maintain
58 the cached entries. The chosen database will need to be configured as well,
59 as shown below. Cache replacement is invoked when the cache size grows to 
60 <max_entries> entries and continues till the cache size drops below this size.
61 <numattrsets> should be equal to the number of following \fBpcacheAttrset\fP
62 directives. Queries are cached only if they correspond to a cacheable template
63 (specified by the \fBpcacheTemplate\fP directive) and the number of entries
64 returned is less than <entry_limit>. Consistency check is performed every
65 <cc_period> duration (specified in secs). In each cycle queries with expired
66 "time to live(\fBTTL\fP)" are removed. A sample cache configuration is: 
67 .LP
68 .RS
69 pcache \fBbdb 10000 1 50 100\fP
70 .RE
71
72 .TP
73 .B pcacheAttrset <index> <attrs...>
74 Used to associate a set of attributes <attrs..> with an <index>. Each attribute
75 set is associated with an integer from 0 to <numattrsets>\-1. These indices are
76 used by the \fBpcacheTemplate\fP directive to define cacheable templates. 
77 A set of attributes cannot be empty.  A set of attributes can contain the
78 special attributes "*" (all user attributes), "+" (all operational attributes)
79 or both; in the latter case, any other attribute is redundant and should
80 be avoided for clarity.  A set of attributes can contain "1.1" as the only
81 attribute; in this case, only the presence of the entries is cached.
82 Attributes prefixed by "undef:" need not be present in the schema.
83
84 .TP
85 .B pcacheMaxQueries <queries>
86 Specify the maximum number of queries to cache. The default is 10000.
87
88 .TP
89 .B pcacheValidate { TRUE | FALSE }
90 Check whether the results of a query being cached can actually be returned
91 from the cache by the proxy DSA.  When enabled, the entries being returned
92 while caching the results of a query are checked to ensure consistency
93 with the schema known to the proxy DSA.  In case of failure, the query
94 is not cached.  By default, the check is off.
95
96 .TP
97 .B pcacheOffline { TRUE | FALSE }
98 Set the cache to offline mode. While offline, the consistency checker
99 will be stopped and no expirations will occur. This allows the cache
100 contents to be used indefinitely while the proxy is cut off from network
101 access to the remote DSA.  The default is FALSE, i.e. consistency
102 checks and expirations will be performed.
103
104 .TP
105 .B pcachePersist { TRUE | FALSE }
106 Specify whether the cached queries should be saved across restarts
107 of the caching proxy, to provide hot startup of the cache.  Only non-expired
108 queries are reloaded.  The default is FALSE.
109
110 .BR CAVEAT :
111 of course, the configuration of the proxy cache must not change
112 across restarts; the pcache overlay does not perform any consistency
113 checks in this sense.
114 In detail, this option should be disabled unless the existing
115 .B pcacheAttrset
116 and
117 .B pcacheTemplate
118 directives are not changed neither in order nor in contents.
119 If new sets and templates are added, or if other details of the pcache
120 overlay configuration changed, this feature should not be affected.
121
122 .TP
123 .B pcacheTemplate <template_string> <attrset_index> <ttl> [<negttl> [<limitttl> [<ttr>]]]
124 Specifies a cacheable template and "time to live" <ttl> of queries 
125 belonging to the template. An optional <negttl> can be used to specify
126 that negative results (i.e., queries that returned zero entries)
127 should also be cached for the specified amount of time. Negative
128 results are not cached by default (<negttl> set to 0).
129 An optional <limitttl> can be used to specify that results
130 hitting a sizelimit should also be cached for the specified amount of time.
131 Results hitting a sizelimit are not cached by default (<limitttl> set to 0).
132 An optional <ttr> "time to refresh" can be used to specify that cached
133 entries should be automatically refreshed after a certain time. Entries
134 will only be refreshed while they have not expired, so the <ttl> should
135 be larger than the <ttr> for this option to be useful. Entries are not
136 refreshed by default (<ttr> set to 0).
137
138 .TP
139 .B pcacheBind <filter_template> <attrset_index> <ttr> <scope> <base>
140 Specifies a template for caching Simple Bind credentials based on an
141 already defined \fBpcacheTemplate\fP. The <filter_template> is similar
142 to a <template_string> except that it may have some values present. Its
143 purpose is to allow the overlay to generate filters similar to what other
144 applications do when they do a Search immediately before a Bind. E.g.,
145 if a client like nss_ldap is configured to search for a user with the
146 filter "(&(objectClass=posixAccount)(uid=<username>))" then the corresponding
147 template "(&(objectClass=posixAccount)(uid=))" should be used here. When
148 converted to a regular template e.g. "(&(objectClass=)(uid=))" this
149 template and the <attrset_index> must match an already defined
150 \fBpcacheTemplate\fP clause. The "time to refresh" <ttr> determines the
151 time interval after which the cached credentials may be refreshed. The
152 first Bind request that occurs after that time will trigger the refresh
153 attempt. Refreshes are not performed when the overlay is Offline. There
154 is no "time to live" parameter for the Bind credentials; the credentials
155 will expire according to the \fBpcacheTemplate\fP ttl. The <scope> and
156 <base> should match the search scope and base used by the authentication
157 clients. The cached credentials are not stored in cleartext, they are
158 hashed using the default password hash.
159 By default Bind caching is not enabled.
160
161 .TP
162 .B pcachePosition { head | tail }
163 Specifies whether the response callback should be placed at the
164 .B tail
165 (the default) or at the 
166 .B head
167 (actually, wherever the stacking sequence would make it appear) 
168 of the callback list.  This affects how the overlay interacts with other
169 overlays, since the proxycache overlay should be executed as early 
170 as possible (and thus configured as late as possible), to get 
171 a chance to return the cached results; however, if executed early
172 at response, it would cache entries that may be later "massaged"
173 by other databases and thus returned \fIafter\fP massaging the first
174 time, and \fIbefore\fP massaging when cached.
175
176 .TP
177 There are some constraints:
178
179 all values must be positive;
180
181 .B <entry_limit>
182 must be less than or equal to
183 .BR <max_entries> ;
184
185 .B <numattrsets>
186 attribute sets SHOULD be defined by using the directive
187 .BR pcacheAttrset ;
188
189 all attribute sets SHOULD be referenced by (at least) one
190 .B pcacheTemplate
191 directive; 
192
193 .LP
194 The following adds a template with filter string \fB(&(sn=)(givenName=))\fP 
195 and attributes mail, postaladdress, telephonenumber and a TTL of 1 hour. 
196 .LP
197 .RS
198 .nf
199 pcacheAttrset \fB0 mail postaladdress telephonenumber\fP
200 pcacheTemplate \fB(&(sn=)(givenName=)) 0 3600\fP
201 .fi
202 .RE
203
204 .LP
205 Directives for configuring the underlying database must also be given, as
206 shown here:
207 .LP
208 .RS
209 .nf
210 directory /var/tmp/cache
211 cachesize 100
212 .fi
213 .RE
214 .LP
215 Any valid directives for the chosen database type may be used. Indexing
216 should be used as appropriate for the queries being handled. In addition,
217 an equality index on the \fBpcacheQueryid\fP attribute should be configured, to
218 assist in the removal of expired query data.
219 .SH BACKWARD COMPATIBILITY
220 The configuration keywords have been renamed and the older form is
221 deprecated. These older keywords are still recognized but may disappear
222 in future releases.
223
224 .TP
225 .B proxycache
226 use pcache
227
228 .TP
229 .B proxyattrset
230 use pcacheAttrset
231
232 .TP
233 .B proxycachequeries
234 use pcacheMaxQueries
235
236 .TP
237 .B proxycheckcacheability
238 use pcacheValidate
239
240 .TP
241 .B proxysavequeries
242 use pcachePersist
243
244 .TP
245 .B proxytemplate
246 use pcacheTemplate
247
248 .TP
249 .B response-callback
250 use pcachePosition
251
252 .SH CAVEATS
253 Caching data is prone to inconsistencies because updates on the remote server
254 will not be reflected in the response of the cache at least (and at most)
255 for the duration of the
256 .B pcacheTemplate
257 .BR TTL .
258 These inconsistencies can be minimized by careful use of the TTR.
259
260 The remote server should expose the
261 .B objectClass 
262 attribute because the underlying database that actually caches the entries 
263 may need it for optimal local processing of the queries.
264
265 The proxy server should contain all the schema information required for caching.
266 Significantly, it needs the schema of attributes used in the query templates.
267 If the objectClass attribute is used in a query template, it needs the definition
268 of the objectClasses of the entries it is supposed to cache.
269 It is the responsibility of the proxy administrator to keep the proxy schema
270 lined up with that of the proxied server.
271
272 Another potential (and subtle) inconsistency may occur when data is retrieved 
273 with different identities and specific per-identity access control
274 is enforced by the remote server.
275 If data was retrieved with an identity that collected only partial results
276 because of access rules enforcement on the remote server, other users
277 with different access privileges on the remote server will get different
278 results from the remote server and from the cache.
279 If those users have higher access privileges on the remote server, they will 
280 get from the cache only a subset of the results they would get directly 
281 from the remote server; but if they have lower access privileges, they will 
282 get from the cache a superset of the results they would get directly 
283 from the remote server.
284 Either occurrence may or may not be acceptable, based on the security policy
285 of the cache and of the remote server.
286 It is important to note that in this case the proxy is violating the security
287 of the remote server by disclosing to an identity data that was collected 
288 by another identity.
289 For this reason, it is suggested that, when using
290 .BR back-ldap ,
291 proxy caching be used in conjunction with the 
292 .I identity assertion
293 feature of
294 .BR slapd\-ldap (5)
295 (see the
296 .B idassert\-bind
297 and the
298 .B idassert\-authz
299 statements), so that remote server interrogation occurs with a vanilla identity 
300 that has some relatively high
301 .B search
302 and
303 .B read
304 access privileges, and the "real" access control is delegated to the proxy's ACLs.
305 Beware that since only the cached fraction of the real datum is available
306 to the cache, it may not be possible to enforce the same access rules that
307 are defined on the remote server.
308 When security is a concern, cached proxy access must be carefully tailored.
309 .SH FILES
310
311 .TP
312 ETCDIR/slapd.conf
313 default slapd configuration file
314 .SH SEE ALSO
315 .BR slapd.conf (5),
316 .BR slapd\-config (5),
317 .BR slapd\-ldap (5),
318 .BR slapd\-meta (5),
319 .BR slapd\-sql (5),
320 .BR slapd (8).
321 .SH AUTHOR
322 Originally implemented by Apurva Kumar as an extension to back-meta;
323 turned into an overlay by Howard Chu.