mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2024-12-27 03:20:22 +08:00
Code Issues Packages Projects Releases Wiki Activity

(L)MDB updates

Browse Source
This commit is contained in:
Quanah Gibson-Mount 2014-04-25 16:04:19 -05:00
parent f48242de00
commit 49ae28a2ee
6 changed files with 39 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/guide/admin/appendix-common-errors.sdf
View File

@ -587,10 +587,10 @@ Some times, `make test' fails at the very first test with an obscure message lik
> make test
> make[1]: Entering directory `/ldap_files/openldap-2.4.6/tests'
> make[2]: Entering directory `/ldap_files/openldap-2.4.6/tests'
> Initiating LDAP tests for BDB...
> Initiating LDAP tests for MDB...
> Cleaning up test run directory leftover from previous run.
> Running ./scripts/all...
> >>>>> Executing all LDAP tests for bdb
> >>>>> Executing all LDAP tests for mdb
> >>>>> Starting test000-rootdse ...
> running defines.sh
> Starting slapd on TCP/IP port 9011...
@ -606,7 +606,7 @@ Some times, `make test' fails at the very first test with an obscure message lik
> ldap_sasl_bind_s: Can't contact LDAP server (-1)
> >>>>> Test failed
> >>>>> ./scripts/test000-rootdse failed (exit 1)
> make[2]: *** [bdb-yes] Error 1
> make[2]: *** [mdb-yes] Error 1
> make[2]: Leaving directory `/ldap_files/openldap-2.4.6/tests'
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/ldap_files/openldap-2.4.6/tests'

2
doc/guide/admin/aspell.en.pws
View File

@ -1688,3 +1688,5 @@ uidNumber
CA's
CAs
namingContext
mdb
lmdb

2
doc/guide/admin/backends.sdf
View File

@ -37,7 +37,7 @@ Note: An {{hdb}} database needs a large {{idlcachesize}} for good search perform
typically three times the {{cachesize}} (entry cache size) or larger.
Note: The {{hdb}} backend has superseded the {{bdb}} backend, and both will
soon be deprecated in favor of the new {{mdb}} backend. See below.
are deprecated in favor of the new {{mdb}} backend. See below.
H3: back-bdb/back-hdb Configuration

10
doc/guide/admin/install.sdf
View File

@ -114,7 +114,11 @@ Kerberos, is highly recommended.
H3: Database Software
OpenLDAP's {{slapd}}(8) {{TERM:BDB}} and {{TERM:HDB}} primary database backends
OpenLDAP's {{slapd}}(8) {{TERM:MDB}} primary database backend uses the {{LMDB}}
software included with the OpenLDAP source. There is no need to download any
additional software to have {{MDB}} support.
OpenLDAP's {{slapd}}(8) {{TERM:BDB}} and {{TERM:HDB}} depricated database backends
require {{ORG[expand]Oracle}} {{PRD:Berkeley DB}}.
If not available at configure time, you will not be able to build
{{slapd}}(8) with these primary database backends.
@ -130,7 +134,7 @@ download page
There are several versions available. Generally, the most recent
release (with published patches) is recommended. This package is required
if you wish to use the {{TERM:BDB}} or {{TERM:HDB}} database backends.
if you wish to use the deprecated {{TERM:BDB}} or {{TERM:HDB}} database backends.
Note: Please see {{SECT:Recommended OpenLDAP Software Dependency Versions}} for
more information.
@ -185,7 +189,7 @@ variables.
> ./configure [options] [variable=value ...]
As an example, let's assume that we want to install OpenLDAP with
BDB backend and TCP Wrappers support. By default, BDB
MDB backend and TCP Wrappers support. By default, MDB
is enabled and TCP Wrappers is not. So, we just need to specify
{{EX:--enable-wrappers}} to include TCP Wrappers support:

16
doc/guide/admin/maintenance.sdf
View File

@ -14,7 +14,13 @@ Backup strategies largely depend on the amount of change in the database
and how much of that change an administrator might be willing to lose in a
catastrophic failure. There are two basic methods that can be used:
1. Backup the Berkeley database itself and periodically back up the transaction
1. Backup the LMDB database itself
The LMDB database can be copied live using the mdb_copy command. If the database
is a sparse file via the use of the "writemap" environment flag, the resulting
copy will be the actual size of the database rather than a sparse copy.
2. Backup the Berkeley database itself and periodically back up the transaction
log files:
Berkeley DB produces transaction logs that can be used to reconstruct
@ -30,7 +36,7 @@ copied offsite. This method affords good protection, with minimal space
overhead.
2. Periodically run slapcat and back up the LDIF file:
3. Periodically run slapcat and back up the LDIF file:
Slapcat can be run while slapd is active. However, one runs the risk of an
inconsistent database- not from the point of slapd, but from the point of
@ -46,13 +52,11 @@ files can be rather large and the accumulation of the day's backups could
add up to a substantial amount of space.
You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8)
back-bdb or back-hdb databases.
back-mdb, back-bdb, or back-hdb databases.
> slapcat -f slapd.conf -b "dc=example,dc=com"
For back-bdb and back-hdb, this command may be ran while slapd(8) is running.
MORE on actual Berkeley DB backups later covering db_recover etc.
For back-mdb, back-bdb, and back-hdb, this command may be ran while slapd(8) is running.
H2: Berkeley DB Logs

18
doc/guide/admin/monitoringslapd.sdf
View File

@ -216,6 +216,7 @@ backends, as well as backends loaded by modules. For example:
> monitoredInfo: monitor
> monitoredInfo: bdb
> monitoredInfo: hdb
> monitoredInfo: mdb
This indicates the {{config}}, {{ldif}}, {{monitor}}, {{bdb}},
and {{hdb}} backends are available.
@ -267,11 +268,24 @@ contains information about a particular backend. For example:
> supportedControl: 1.3.6.1.4.1.4203.1.10.1
> supportedControl: 1.2.840.113556.1.4.1413
> supportedControl: 1.3.6.1.4.1.4203.666.11.7.2
>
> dn: cn=Backend 5,cn=Backends,cn=Monitor
> monitoredInfo: mdb
> monitorRuntimeConfig: TRUE
> supportedControl: 1.3.6.1.1.12
> supportedControl: 2.16.840.1.113730.3.4.2
> supportedControl: 1.3.6.1.4.1.4203.666.5.2
> supportedControl: 1.2.840.113556.1.4.319
> supportedControl: 1.3.6.1.1.13.1
> supportedControl: 1.3.6.1.1.13.2
> supportedControl: 1.3.6.1.4.1.4203.1.10.1
> supportedControl: 1.2.840.113556.1.4.1413
> supportedControl: 1.3.6.1.4.1.4203.666.11.7.2
For each of these objects, monitorInfo indicates which backend the
information in the object is about. For instance, the {{EX:cn=Backend
3,cn=Backends,cn=Monitor}} object contains (in the example) information
about the {{bdb}} backend.
5,cn=Backends,cn=Monitor}} object contains (in the example) information
about the {{mdb}} backend.
!block table
Attribute|Description