:: RootR ::  Hosting Order Map Login   Secure Inter-Network Operations  
slapd-bdb(5) - phpMan

Command: man perldoc info search(apropos)  

SLAPD-BDB(5)                           File Formats Manual                           SLAPD-BDB(5)

       slapd-bdb, slapd-hdb - Berkeley DB backends to slapd


       The  bdb  backend to slapd(8) uses the Oracle Berkeley DB (BDB) package to store data.  It
       makes extensive use of indexing and caching to speed data access.

       Note that BDB is deprecated and support will  be  dropped  in  future  OpenLDAP  releases.
       Installations should use the mdb backend instead.

       hdb  is  a  variant of the bdb backend that uses a hierarchical database layout which sup‐
       ports subtree renames. It is both more space-efficient and more  execution-efficient  than
       the bdb backend.  It is otherwise identical to the bdb behavior, and all the same configu‐
       ration options apply.

       It is noted that these options  are  intended  to  complement  Berkeley  DB  configuration
       options  set  in  the  environment's  DB_CONFIG  file.   See Berkeley DB documentation for
       details on DB_CONFIG configuration options.  Where there is overlap, settings in DB_CONFIG
       take precedence.

       These  slapd.conf  options  apply to the bdb and hdb backend database.  That is, they must
       follow a "database bdb" or "database hdb" line and come before any subsequent "backend" or
       "database" lines.  Other database options are described in the slapd.conf(5) manual page.

       cachesize <integer>
              Specify  the  size in entries of the in-memory entry cache maintained by the bdb or
              hdb backend database instance.  The default is 1000 entries.

       cachefree <integer>
              Specify the number of entries to free from the entry cache when the  cache  reaches
              the cachesize limit.  The default is 1 entry.

       checkpoint <kbyte> <min>
              Specify the frequency for checkpointing the database transaction log.  A checkpoint
              operation flushes the database buffers to disk and writes a  checkpoint  record  in
              the  log.   The  checkpoint  will  occur if either <kbyte> data has been written or
              <min> minutes have passed since the last checkpoint.   Both  arguments  default  to
              zero,  in  which  case  they  are  ignored. When the <min> argument is non-zero, an
              internal task will run every <min> minutes to  perform  the  checkpoint.   See  the
              Berkeley DB reference guide for more details.

              Enable checksum validation of DB pages whenever they are read from disk.  This set‐
              ting can only be configured before any database files are created.

       cryptfile <file>
              Specify the pathname of a file containing an encryption key to use  for  encrypting
              the  database.  Encryption  is performed using Berkeley DB's implementation of AES.
              Note that encryption can only be configured before any database files are  created,
              and  changing  the  key  can only be done after destroying the current database and
              recreating it. Encryption is not enabled by  default,  and  some  distributions  of
              Berkeley DB do not support encryption.

       cryptkey <key>
              Specify  an  encryption  key to use for encrypting the database. This option may be
              used when a separate cryptfile is not desired. Only one of  cryptkey  or  cryptfile
              may be configured.

       dbconfig <Berkeley-DB-setting>
              Specify  a  configuration directive to be placed in the DB_CONFIG file of the data‐
              base directory. The dbconfig directive is just a convenience to allow all necessary
              configuration  to be set in the slapd.conf file.  The options set using this direc‐
              tive will only be written to the DB_CONFIG file if no such file existed  at  server
              startup time, otherwise they are completely ignored. This allows one to set initial
              values without overwriting/destroying a DB_CONFIG file that was already  customized
              through  other  means.   This directive may be specified multiple times, as needed.
              For example:
                   dbconfig set_cachesize 0 1048576 0
                   dbconfig set_lg_bsize 2097152

              Specify that on-disk database contents should not be immediately synchronized  with
              in  memory changes.  Enabling this option may improve performance at the expense of
              data security.  See the Berkeley DB reference guide for more details.

       dbpagesize  <dbfile> <size>
              Specify the page size to use for a particular  database  file,  in  units  of  1024
              bytes.  The  default  for  the id2entry file is 16, the default for all other files
              depends on the size of the underlying filesystem's block size (typically 4  or  8).
              The maximum that BerkeleyDB supports is 64. This setting usually should not need to
              be changed, but if BerkeleyDB's "db_stat -d" shows a large amount of overflow pages
              in  use in a file, setting a larger size may increase performance at the expense of
              data integrity. This setting only takes effect when a database is being newly  cre‐
              ated. See the Berkeley DB reference guide for more details.

       directory <directory>
              Specify  the  directory where the BDB files containing this database and associated
              indexes live.  A separate directory must  be  specified  for  each  database.   The
              default is /var/lib/ldap.

              Allow  reads of modified but not yet committed data.  Usually transactions are iso‐
              lated to prevent other operations from accessing uncommitted data.  This option may
              improve  performance,  but  may  also return inconsistent results if the data comes
              from a transaction that is later aborted.  In this case, the modified data is  dis‐
              carded and a subsequent search will return a different result.

       dncachesize <integer>
              Specify  the  maximum  number of DNs in the in-memory DN cache.  Ideally this cache
              should be large enough to contain the DNs of every entry in the database. If set to
              a  smaller  value  than  the  cachesize  it will be silently increased to equal the
              cachesize. The default value is 0 which means unlimited, i.e.  the  DN  cache  will
              grow without bound.

              It should be noted that the DN cache is allowed to temporarily grow beyond the con‐
              figured size. It does this if many entries are locked when it tries to do a  purge,
              because  that  means  they're  legitimately in use. Also, the DN cache never purges
              entries that have cached children, so depending on the shape of the DIT,  it  could
              have lots of cached DNs over the defined limit.

       idlcachesize <integer>
              Specify the size of the in-memory index cache, in index slots. The default is zero.
              A larger value will speed up frequent searches of indexed entries. An hdb  database
              needs  a  large idlcachesize for good search performance, typically three times the
              cachesize (entry cache size) or larger.

       index {<attrlist>|default} [pres,eq,approx,sub,<special>]
              Specify the indexes to maintain for the given attribute (or  list  of  attributes).
              Some  attributes only support a subset of indexes.  If only an <attr> is given, the
              indices specified for default are maintained.  Note that setting a default does not
              imply  that all attributes will be indexed. Also, for best performance, an eq index
              should always be configured for the objectClass attribute.

              A number of special index parameters may be specified.  The index type sub  can  be
              decomposed  into subinitial, subany, and subfinal indices.  The special type nolang
              may be specified to disallow use of this index by language subtypes.   The  special
              type  nosubtypes  may be specified to disallow use of this index by named subtypes.
              Note: changing index settings in slapd.conf(5)  requires  rebuilding  indices,  see
              slapindex(8);  changing  index  settings  dynamically  by LDAPModifying "cn=config"
              automatically causes rebuilding of the indices online in a background task.

              Tell slapindex to index one attribute at a time. By default, all indexed attributes
              in  an  entry  are  processed  at  the  same  time.  With this option, each indexed
              attribute is processed individually, using multiple passes through the entire data‐
              base. This option improves slapindex performance when the database size exceeds the
              dbcache size. When the dbcache is large enough, this option is not needed and  will
              decrease  performance.   Also  by  default, slapadd performs full indexing and so a
              separate slapindex run is not needed. With this option, slapadd  does  no  indexing
              and slapindex must be used.

       lockdetect {oldest|youngest|fewest|random|default}
              Specify  which  transaction  to  abort when a deadlock is detected.  The default is

       mode <integer>
              Specify the file protection mode that newly created  database  index  files  should
              have.  The default is 0600.

       searchstack <depth>
              Specify  the  depth of the stack used for search filter evaluation.  Search filters
              are evaluated on a stack to accommodate nested AND  /  OR  clauses.  An  individual
              stack  is  assigned  to  each server thread.  The depth of the stack determines how
              complex a filter can be evaluated without requiring any additional  memory  alloca‐
              tion. Filters that are nested deeper than the search stack depth will cause a sepa‐
              rate stack to be allocated for that particular search operation. These  allocations
              can  have  a  major  negative impact on server performance, but specifying too much
              stack will also consume a great deal of memory.  Each search stack uses 512K  bytes
              per level. The default stack depth is 16, thus 8MB per thread is used.

       shm_key <integer>
              Specify  a  key for a shared memory BDB environment. By default the BDB environment
              uses memory mapped files. If a non-zero value is specified, it will be used as  the
              key to identify a shared memory region that will house the environment.

       The bdb and hdb backends honor access control semantics as indicated in slapd.access(5).

              default slapd configuration file

              Berkeley DB configuration file

       slapd.conf(5),  slapd-config(5),  slapd-mdb(5),  slapd(8), slapadd(8), slapcat(8), slapin‐
       dex(8), Berkeley DB documentation.

       OpenLDAP Software is developed and maintained by The OpenLDAP  Project  <http://www.openl‐
       dap.org/>.   OpenLDAP  Software  is  derived from University of Michigan LDAP 3.3 Release.
       Originally begun by Kurt Zeilenga. Caching mechanisms  originally  designed  by  Jong-Hyuk
       Choi. Completion and subsequent work, as well as back-hdb, by Howard Chu.

OpenLDAP                                    2014/09/20                               SLAPD-BDB(5)

rootr.net - man pages