:: RootR ::  Hosting Order Map Login   Secure Inter-Network Operations  
slapo-pcache(5) - phpMan

Command: man perldoc info search(apropos)  

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:

       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

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

       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 configura‐
              tion 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 imme‐
              diately 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 creden‐
              tials 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 Off‐
              line. There is no "time to live" parameter for the Bind  credentials;  the  creden‐
              tials  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 con‐
              figured as late as possible), to get a chance to return the  cached  results;  how‐
              ever, if executed early at response, it would cache entries that may be later "mas‐
              saged" 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 pcacheAt‐

              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  pcache‐
       Queryid 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.

              use pcache

              use pcacheAttrset

              use pcacheMaxQueries

              use pcacheValidate

              use pcachePersist

              use pcacheTemplate

              use pcachePosition

       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 pca‐
       cheTemplate 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.  Signifi‐
       cantly, 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 differ‐
       ent 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  privi‐
       leges  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 con‐
       junction 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 frac‐
       tion 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.

              default slapd configuration file

       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  over‐
       lay by Howard Chu.

OpenLDAP                                    2014/09/20                            SLAPO-PCACHE(5)

rootr.net - man pages