Create a 389 Directory Server Instance with dscreate and an INF File

An INF file gives you a repeatable, reviewable way to create a 389 Directory Server instance without stepping through dscreate interactive prompts. In this guide, I'll generate a template from the installed dscreate version, edit the values that matter for the deployment, protect the file because it can hold the Directory Manager password, and run dscreate from-file to provision the instance.

Before you start:

• Install 389 Directory Server — 389-ds-base installed; this guide assumes packages are present and focuses on INF-driven instance creation
• 389 Directory Server architecture — instance, suffix, and backend terminology
• Free LDAP and LDAPS ports on the host for the instance you plan to create

Tested on: Rocky Linux 10.2; 389 Directory Server 3.2.0.

When should you use a dscreate INF file?

Use an INF file when you need the same instance layout more than once or when you want human review before anything is written to disk.

Interactive creation with dscreate interactive is covered in Install 389 Directory Server. Non-root instance layouts, multiple instances on one host, and general dsctl or dsconf usage belong in their own chapters.

Plan the Directory Server instance

Decide these values before you generate the template. Three names often get mixed up:

The instance name is fixed after creation. The suffix is the directory namespace. The backend is the server-side object that connects that suffix to LMDB storage and indexes. They are related but not interchangeable.

Confirm the LDAP and LDAPS ports are free on the host before you run dscreate from-file. If another service already owns 389 or 636, choose unused ports in the INF file.

Generate the dscreate INF template

Generate the template from the dscreate version on the server, not from an old blog post or another distribution's package.

Write the template to a file:

dscreate create-template /root/ldap1.inf

The command exits silently on success and leaves a commented INF file at the path you chose. Open the file to review the commonly used parameters and their defaults for the installed release. To include parameters marked as advanced, check the options supported by your installed version with dscreate create-template --help and generate an advanced template when required.

dscreate create-template --advanced /root/ldap1-advanced.inf

The advanced template on 389 DS 3.2.0 in this lab is roughly twice the size of the default template. It exposes low-level installer options such as custom filesystem paths, service user and group settings, and systemd or SELinux integration. The normal template already includes commonly used database, replication, changelog, and index settings, so most deployments do not need --advanced.

Print the template to the terminal when you only want to inspect the format:

dscreate create-template

The output begins with a version header and commented [general] parameters:

;
; This is a version 2 ds setup inf file.
...
[general]
# full_machine_name (str)
...
[slapd]
# instance_name (str)

Redirect stdout to a file if you prefer to capture it yourself: dscreate create-template > /root/ldap1.inf.

Understand the INF file sections

The template splits instance-wide settings, server parameters, and backend definitions. You normally uncomment or add only the keys you need rather than filling every commented line.

[general]

General installer settings that control how this instance is created:

Set strict_host_checking = False in isolated labs where the configured hostname does not have working forward and reverse resolution. Leave hostname validation enabled when your environment provides consistent DNS resolution.

[slapd]

Instance identity, privileged account, listeners, TLS bootstrap, and database library:

mdb_max_size limits how large the LMDB database environment can grow. The generated template calculates a default for the current host, which is sufficient for this small lab. For a production deployment, uncomment the setting and choose a value based on expected directory growth and available storage rather than copying a fixed value from another server.

[backend-userroot]

Backend sections use the format [backend-BACKEND_NAME]. The generated template contains [backend-userroot], so the backend identifier becomes userroot in dsconf output. Additional backends can be defined with sections such as [backend-apps], each with its own suffix.

The generated template documents additional backend keys. Those include replication toggles, changelog limits, and index requirements that you can enable when a later chapter needs them. Duplicate the backend section with another unique name when one instance must hold multiple suffix backends.

Create a minimal INF file

Edit /root/ldap1.inf down to a minimal lab configuration. Change the hostname, instance name, suffix, ports, and password for your environment.

[general]
config_version = 2
full_machine_name = ldap1.example.com
start = True
strict_host_checking = False

[slapd]
instance_name = ldap1
root_dn = cn=Directory Manager
root_password = REPLACE_WITH_STRONG_PASSWORD
port = 389
secure_port = 636
self_sign_cert = True
db_lib = mdb

[backend-userroot]
suffix = dc=example,dc=com
create_suffix_entry = True
sample_entries = no

Replace full_machine_name, instance_name, suffix, listener ports, and root_password before you install. create_suffix_entry = True creates the base dc=example,dc=com entry so suffix-scoped searches succeed immediately. sample_entries = no keeps the directory free of demonstration accounts that later course chapters do not use.

Validate syntax and prerequisites without creating files:

dscreate from-file -n /root/ldap1.inf

Starting installation ...
Validate installation settings ...
NOOP: Dry run requested
Completed installation for instance: slapd-ldap1

The -n / --dryrun flag validates settings only and skips filesystem installation. The final Completed installation line means validation finished in dry-run mode. It does not register a new instance. Confirm with dsctl -l that no unexpected slapd-INSTANCE name appeared. On a host where the instance already exists, validation reports that conflict instead of altering the system.

An INF file is an installation input. Editing it after dscreate from-file succeeds does not change a running instance. Use dsconf for day-two configuration.

Protect the INF file

The INF file can store the Directory Manager password in plain text. When you pass a filename directly to dscreate create-template, current versions create the file with mode 600. Verify the mode before adding credentials, especially if you generated the file with shell redirection.

ls -l /root/ldap1.inf

-rw-------. 1 root root 6991 Jul 15 13:42 /root/ldap1.inf

Permissions are already owner-read/write only (600), which is what you want before storing the Directory Manager password.

I'll set mode 600 on the INF file with the chmod command before I store the Directory Manager password:

chmod 600 /root/ldap1.inf

Treat the file like any other credential-bearing configuration: do not commit it to Git, remove or archive it securely after the instance is created, and render it from a secret manager or ephemeral automation workspace in production rather than keeping long-lived copies on shared disks.

Create the Directory Server instance

Run dscreate from-file when the INF file is ready:

dscreate from-file /root/ldap1.inf

Starting installation ...
Validate installation settings ...
Create file system structures ...
Create self-signed certificate database ...
Perform SELinux labeling ...
Create database backend: dc=example,dc=com ...
Perform post-installation tasks ...
Completed installation for instance: slapd-ldap1

dscreate validates the INF, creates instance directories under /etc/dirsrv and /var/lib/dirsrv, initializes the backend and suffix, configures certificates when requested, and starts ns-slapd when start = True. It does not replace day-two administration. Use dsctl and dsconf for that (dsctl commands, dsconf commands).

Verify the new instance

Confirm the instance is registered locally:

dsctl -l

slapd-ldap1

Next, check whether the instance process is running. This status check does not prove that remote clients can reach the LDAP listener:

dsctl ldap1 status

Instance "ldap1" is running

Check the matching systemd unit with systemctl:

systemctl status dirsrv@ldap1 --no-pager

The Active: active (running) line and Status: "slapd started: Ready to process requests" message confirm ns-slapd started for this instance name.

List the configured suffix:

dsconf ldap1 backend suffix list

dc=example,dc=com (userroot)

The parenthesized userroot name is the backend identifier for further dsconf backend commands.

Confirm the database library selected in the INF file:

dsconf ldap1 backend config get | grep nsslapd-backend-implement

nsslapd-backend-implement: mdb

A value of mdb confirms LMDB. The db_lib option in [slapd] accepts mdb or bdb; new 3.x deployments should normally use mdb.

Search the suffix base entry over LDAP. A base-scope ldapsearch command against the suffix DN confirms the root entry exists:

ldapsearch -x -H ldap://localhost:389 -D "cn=Directory Manager" -W -b "dc=example,dc=com" -s base

This command uses an unencrypted LDAP connection only for local loopback verification. Do not send Directory Manager credentials over an unencrypted remote connection. For remote administration, use LDAPS or StartTLS after configuring client trust for the server certificate.

Enter the Directory Manager password when prompted. A successful base search returns the dc=example,dc=com entry with objectClass: domain.

dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

Reuse the INF file for another instance

You can copy an INF file to build another instance on the same host. Only some values must change:

full_machine_name is the system FQDN, not an instance identifier. Separate instances on one host can share the same hostname and suffix. That is common when building replicas or isolated test instances. Each instance still needs its own instance_name and listener ports.

Adjust those fields, run dscreate from-file again, and verify with dsctl -l. See Run multiple 389 Directory Server instances on one host for a complete second-instance example.

Troubleshoot dscreate INF file errors

Inspect CLI validation options:

dscreate from-file --help

usage: dscreate from-file [-h] [-n] file
  -n, --dryrun  Validate system and configurations only. Do not alter the
                system.

When creation fails after partial progress, check the service journal with journalctl and the instance error log:

journalctl -u dirsrv@ldap1 --no-pager -n 30

Error details also land under /var/log/dirsrv/slapd-ldap1/errors for the instance name you chose in the INF file.

Summary

1. Generate the template with dscreate create-template from the installed version.
2. Configure [general], [slapd], and [backend-userroot] for your instance, listeners, and suffix.
3. Protect the INF file with chmod 600 and keep passwords out of version control.
4. Run dscreate from-file /root/ldap1.inf (use -n first when you want a dry run).
5. Verify with dsctl, systemctl, dsconf ldap1 backend suffix list, nsslapd-backend-implement, and a base ldapsearch against the suffix.

What's Next

• Run multiple instances on one host — separate ports and suffixes per instance
• Non-root instance layout — run Directory Server without root privileges
• Suffixes and backends — manage directory trees after provisioning

References

• Install 389 Directory Server (Port389) — upstream dscreate create-template and dscreate from-file workflow
• Setting up an instance using the command line (Red Hat Directory Server 13) — INF parameters, db_lib, mdb_max_size, and instance creation
• Berkeley DB backend deprecation (Port389) — mdb versus bdb and default backend selection