How To

How do I understand what the different DS Backends are used for in DS 5.x and 6.x?

Last updated Aug 10, 2020

The purpose of this article is to provide information on the default backends used in DS.


DS Backends

Note

This information is included in the documentation for DS 7 and later. See Configuration Guide › Data Storage for further information.

The following table details all the backends that are enabled by default: (excluding Changlelog which is disabled)

Backend Type Replicated? Part of Backup? Details
cn=admin data

LDIF

Yes Yes

Shared admin backend, includes:

  • Administrative identities (Global administrator cn=admin,cn=Administrators,cn=admin data used for replication)
  • Certificates/secret keys 
  • Server IDs of the replication topology
  • MUST be the same in all replicas
  • Used by dsreplication status command

Related file: admin-backend.ldif - contains the certificate for each replicated instance and the admin entry used for replication. The admin backend "cn=admin data" is created at startup using this file.

If an RS is out of sync, you can initialize or simply copy the ldif from another server, as it should be the same for all.

Additionally, for replicated servers, this file stores a password hash for the global administrator, such as cn=admin,cn=Administrators,cn=admin data. This file is located in the base directory.

Base directory: db/adminRoot in DS 6.5.x, /db/admin in DS 6 or /config in DS 5

Default value: org.opends.server.backends.LDIFBackend

cn=ads-truststore

TrustStore

No Yes

The db/ads-truststore/ads-truststore file stores the server key pair for securing replication connections and other replicas' public key certificates: Administration Guide › To Replace the Key Pair Used for Replication.

The ads-truststore is a mutable truststore for keys and certificates used by replication.

The ads-truststore holds a mirror, or copy, of the remote Administrative Directory Service (ADS) host's ADS key entry, so that the new instance can establish trust with existing servers in the ADS domain. The monitor displays the backend's general properties, such as writability mode, base DN, backend IDs, entry count and other properties.

Related files: ads-truststore JKS file and ads-truststore.pin (storepass and keypass)

Base directory: /db/ads-truststore

Default value: org.opends.server.backends.TrustStoreBackend

cn=backups

Backup

No No

Dynamic backend, which retrieves backup data upon request.

Base directory: N/A

Default value: org.opends.server.backends.BackupBackend

cn=changelog

Changelog

No No

External Change Log for replication to other replication servers. 

Base directory: /changelogDb

Default value: org.opends.server.backends.ChangelogBackend 

Default enabled: No 

See Administration Guide › To Enable the External Change Log.

cn=config

Configuration

No No

Local server configuration, for example:

  • Global ACIs (cn=Access Control Handler,cn=config)
  • Password Policies (cn=Password Policies,cn=config)
  • Indexes
  • Connection Handlers
  • Root DSE (cn=Root DSE,cn=config)
  • Server IDs of the replication topology (just like cn=admin data)
  • etc

Related file: config.ldif - contains the main configuration for the DS instance, including replication data. This file is located in /path/to/ds/config. You can use this with the ./dsconfig command.

Base directory: /config

Default value: org.opends.server.backends.ConfigurationBackend

cn=monitor

Monitor

No No

Monitoring information via ldapsearch on this suffix:

Nothing is stored, data is retrieved upon request and is dynamically generated.

Base directory: N/A

Default value: org.opends.server.backends.MonitorBackend

cn=schema

Schema

Yes Yes

The cn=schema suffix contains a single entry with attributes and object classes that define standard and custom LDAP schema.

Nothing is stored, it dynamically generates the schema entry whenever it is requested.

Related files: schema ldif files

Base directory: /db/schema

Default value: org.opends.server.backends.SchemaBackend

cn=tasks

Task

No Yes

Using the --incremental flag creates an internal task with the required backup parameters (no passwords) inside of an internal backend called cn=Tasks.

All backup or rebuild-index tasks are recorded in "cn=Tasks"dn: cn=Scheduled Tasks,cn=tasksdn: cn=Recurring Tasks,cn=tasks.

Related file: tasks.ldif is a file-based database that stores information on past, current and future tasks for the task scheduler backend, for example, backup tasks that are currently running or scheduled. You can use this with the ./manage-tasks command.

Base directory: /db/tasks

Default value: org.opends.server.backends.task.TaskBackend

Root DSE

RootDSE

No No

The root entry for the directory, technically the entry with DN "" (the empty string).

Contains information about what the server supports, including the other base DNs it serves.

Heartbeat requests target the remote directory server root DSE.

Used by cn=monitor

Base directory: N/A

Default value: org.opends.server.backends.RootDSEBackend

rootUser

LDIF

No Yes

RootDN (cn=Directory Manager base DN) entry which contains the privileges required to manage the DS instance.

Base directory: /db/rootUser

Default value: org.opends.server.backends.LDIFBackend

User Entries Database (for example, CTS)

JEBackend

Yes Yes

This is the actual directory database where user entries are stored.

Base directory: /db/{name}

Default value: org.opends.server.backends.jeb.JEBackend

LDAP search examples

The following section details simple ldapsearch examples for each backend type: 

cn=admin data

$ ./ldapsearch --port 1389 --hostname cts.example.com --baseDn "cn=admin data" --searchScope sub "(objectClass=*)

cn=ads-truststore

$ ./ldapsearch --port 1389 --hostname cts.example.com --baseDn cn=ads-truststore --searchScope sub "(objectClass=*)"

cn=config

$ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDn "cn=config" "(objectclass=*)"

cn=monitor

$ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDn "cn=monitor" --searchScope sub "(objectClass=*)" \*

cn=schema

$ ./ldapsearch --port 1389 --hostname cts.example.com --baseDn "cn=schema" --searchScope base '(&)' '+'

cn=tasks

$ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDn "cn=tasks" --searchScope sub "(objectClass=*)" \*

Root DSE

./ldapsearch --port 1389 --baseDn "" --searchScope base "(objectclass=*)" '(&)' '+'

rootUser

$ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDn "cn=Directory Manager" --searchScope sub "(objectClass=*)"
$ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDn "uid=Monitor" --searchScope sub "(objectClass=*)"
$ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDn "cn=Directory Manager" --searchScope base '(&)' '+'

User Entries Database

$ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDn ou=tokens --searchScope sub "(objectClass=*)"

See Also

Administration Guide › About Database Backends

Configuration Reference › LDIF Backend

Configuration Reference › Trust Store Backend

Configuration Reference › Backup Backend

Configuration Reference › Monitor Backend

Configuration Reference › Schema Backend

Configuration Reference › Task Backend

Configuration Reference › JE Backend

Related Training

N/A

Related Issue Tracker IDs

N/A



Copyright and TrademarksCopyright © 2020 ForgeRock, all rights reserved.
Loading...