-s# $OpenLDAP$
+# $OpenLDAP$
# Copyright 2005-2007 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
database definitions, and assorted other items. A sample config tree
is shown in Figure 5.1.
-!import "config_dit.gif"; align="center"; title="Sample configuration tree"
+!import "config_dit.png"; align="center"; title="Sample configuration tree"
FT[align="Center"] Figure 5.1: Sample configuration tree.
Other objects may be part of the configuration but were omitted from
This directive grants access (specified by <accesslevel>) to a
set of entries and/or attributes (specified by <what>) by one or
-more requesters (specified by <who>).
+more requestors (specified by <who>).
See the {{SECT:Access Control}} section of this chapter for a
summary of basic usage.
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 checkpont. Both arguments default
+<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.
no such file exists yet, the {{EX:DB_CONFIG}} file will be created and the
settings in this attribute will be written to it. If the file exists,
its contents will be read and displayed in this attribute. The attribute
-is multi-valued, to accomodate multiple configuration directives. No default
+is multi-valued, to accommodate multiple configuration directives. No default
is provided, but it is essential to use proper settings here to get the
best server performance.
Ideally the BDB cache must be
at least as large as the working set of the database, the log buffer size
-should be large enough to accomodate most transactions without overflowing,
+should be large enough to accommodate most transactions without overflowing,
and the log directory must be on a separate physical disk from the main
database files. And both the database directory and the log directory
should be separate from disks used for regular system activities such as
H4: olcDbSearchStack: <integer>
Specify the depth of the stack used for search filter evaluation.
-Search filters are evaluated on a stack to accomodate nested {{EX:AND}} /
+Search filters are evaluated on a stack to accommodate nested {{EX:AND}} /
{{EX:OR}} clauses. An individual stack is allocated for each server thread.
The depth of the stack determines how complex a filter can be evaluated
without requiring any additional memory allocation. Filters that are
The next section of the example configuration file defines another
BDB database. This one handles queries involving the
{{EX:dc=example,dc=net}} subtree but is managed by the same entity
-as the first database. Note that without line 51, the read access
+as the first database. Note that without line 52, the read access
would be allowed due to the global access rule at line 19.
-E: 42. # BDB definition for example.net
-E: 43. dn: olcDatabase=bdb,cn=config
-E: 44. objectClass: olcDatabaseConfig
-E: 45. objectClass: olcBdbConfig
-E: 46. olcDatabase: bdb
-E: 47. olcSuffix: "dc=example,dc=net"
-E: 48. olcDbDirectory: /usr/local/var/openldap-data-net
-E: 49. olcRootDN: "cn=Manager,dc=example,dc=com"
-E: 50. olcDbIndex: objectClass eq
-E: 51. olcAccess: to * by users read
+E: 43. # BDB definition for example.net
+E: 44. dn: olcDatabase=bdb,cn=config
+E: 45. objectClass: olcDatabaseConfig
+E: 46. objectClass: olcBdbConfig
+E: 47. olcDatabase: bdb
+E: 48. olcSuffix: "dc=example,dc=net"
+E: 49. olcDbDirectory: /usr/local/var/openldap-data-net
+E: 50. olcRootDN: "cn=Manager,dc=example,dc=com"
+E: 51. olcDbIndex: objectClass eq
+E: 52. olcAccess: to * by users read
projects / openldap / blobdiff