Man Linux: Main Page and Category List

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.

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

       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.