bionic (5) slapo-pcache.5.gz

Provided by: slapd_2.4.45+dfsg-1ubuntu1.11_amd64 bug

NAME

       slapo-pcache - proxy cache 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 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:

       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. Please note
              that the underlying backend must have a configured rootdn.

       pcache <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  pcacheAttrset  directives.  Queries  are
              cached only if they correspond to a cacheable template (specified by the pcacheTemplate 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:

              pcache mdb 10000 1 50 100

       pcacheAttrset <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 pcacheTemplate 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.  Attributes prefixed by "undef:" need not be present in the schema.

       pcacheMaxQueries <queries>
              Specify the maximum number of queries to cache. The default is 10000.

       pcacheValidate { 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.

       pcacheOffline { TRUE | FALSE }
              Set  the  cache  to  offline  mode.  While offline, the consistency checker will be stopped and no
              expirations will occur. This allows the cache contents to be used indefinitely while the proxy  is
              cut  off from network access to the remote DSA.  The default is FALSE, i.e. consistency checks and
              expirations will be performed.

       pcachePersist { 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 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.

       pcacheTemplate <template_string> <attrset_index> <ttl> [<negttl> [<limitttl> [<ttr>]]]
              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).  An optional <ttr>  "time  to  refresh"
              can be used to specify that cached entries should be automatically refreshed after a certain time.
              Entries will only be refreshed while they have not expired, so the <ttl> should be larger than the
              <ttr> for this option to be useful. Entries are not refreshed by default (<ttr> set to 0).

       pcacheBind <filter_template> <attrset_index> <ttr> <scope> <base>
              Specifies   a   template  for  caching  Simple  Bind  credentials  based  on  an  already  defined
              pcacheTemplate. The <filter_template> is similar to a <template_string> except that  it  may  have
              some values present. Its purpose is to allow the overlay to generate filters similar to what other
              applications do when they do a Search immediately before a Bind. E.g., if a client  like  nss_ldap
              is configured to search for a user with the filter "(&(objectClass=posixAccount)(uid=<username>))"
              then the corresponding template "(&(objectClass=posixAccount)(uid=))" should be  used  here.  When
              converted   to   a   regular   template  e.g.  "(&(objectClass=)(uid=))"  this  template  and  the
              <attrset_index> must match an already defined pcacheTemplate clause. The "time to  refresh"  <ttr>
              determines  the  time interval after which the cached credentials may be refreshed. The first Bind
              request that occurs after that time will trigger the refresh attempt. Refreshes are not  performed
              when  the  overlay  is Offline. There is no "time to live" parameter for the Bind credentials; the
              credentials will expire according to the pcacheTemplate ttl. The <scope> and <base>  should  match
              the  search  scope  and  base  used  by the authentication clients. The cached credentials are not
              stored in cleartext, they are hashed using the default password hash.  By default Bind caching  is
              not enabled.

       pcachePosition { 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 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.

BACKWARD COMPATIBILITY

       The configuration keywords have been renamed and the older form is deprecated. These older  keywords  are
       still recognized but may disappear in future releases.

       proxycache
              use pcache

       proxyattrset
              use pcacheAttrset

       proxycachequeries
              use pcacheMaxQueries

       proxycheckcacheability
              use pcacheValidate

       proxysavequeries
              use pcachePersist

       proxytemplate
              use pcacheTemplate

       response-callback
              use pcachePosition

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  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.

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.