Why dsconf Is Missing on Your RHEL Server and What to Use for OpenLDAP LDIF Imports Instead

If you installed openldap-servers on your Red Hat server and then discovered that dsconf does not exist, that is expected: dsconf is not an OpenLDAP tool at all. It belongs to the 389 Directory Server product family (which includes Red Hat Directory Server). If your goal is simply to import an LDIF file into an OpenLDAP server, you do not need dsconf — the OpenLDAP equivalent is slapadd.

Why the Command Is Missing

Two completely separate LDAP server products ship with similar-looking administration tools, and mixing their instructions is a very common source of confusion:

• OpenLDAP — the slapd daemon plus tools like slapadd, slapcat, slapindex, ldapadd, and ldapsearch.
• 389 Directory Server — a different server, historically derived from Netscape/Sun Directory Server, administered with dsconf, dsctl, and dsidm. These come from the python3-lib389 package, which is installed as part of 389-ds-base.

Because you installed openldap-servers, your system runs slapd and has no use for dsconf. Its configuration format, backend layout, and command-line tooling are all different.

On RHEL 8 the OpenLDAP server packages live in the CodeReady Builder repository — note that Red Hat does not provide formal support for running openldap-servers from that repo on RHEL 8, which is worth factoring into your migration plan.

How to Find Out What Provides a Command

Before installing anything, ask the package manager which package owns a missing file. On RHEL 8 or 9:

dnf provides dsconf

On a RHEL 9 system this reports something like python3-lib389 from the AppStream repository, matching /usr/sbin/dsconf. On RHEL 8, 389 Directory Server packages are available through subscription channels if you intended to migrate to that product instead.

Keep in mind that installing python3-lib389 pulls in the full 389-ds-base stack and many dependencies (Perl modules, SASL plugins, NSS tools, and more). Installing it just to run one command against an OpenLDAP server makes no sense — the command would fail anyway, because dsconf speaks 389 DS configuration, not OpenLDAP's cn=config.

Importing an LDIF File into OpenLDAP

For an offline import into a running-but-stopped OpenLDAP server, use slapadd:

systemctl stop slapd
sudo -u ldap slapadd -F /etc/openldap/slapd.d -b "dc=example,dc=com" -l /etc/openldap/export/export.ldif
systemctl start slapd

Key points:

• Substitute your own directory suffix for dc=example,dc=com. The -b option selects the database whose olcSuffix matches, so that database must already be defined in the new server's configuration.
• Run the command as the ldap user. If you run it as root, the newly created database files will be owned by root and slapd will fail to start. If that happens, fix it with chown -R ldap:ldap /var/lib/ldap.
• The import must happen while slapd is stopped, because the database files cannot be modified safely by two processes at once.

The Most Common Import Failure: Missing Schema

If slapadd rejects entries, the usual culprit is schema. Every objectClass and attribute used in your LDIF must be defined on the new server. Load any additional schemas before importing, for example:

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif

The -Y EXTERNAL mechanism authenticates through the local UNIX socket, so it works without a password for the root user.

A Cleaner Alternative: Copy the Whole Configuration

If the old server is also OpenLDAP using the cn=config configuration style, the most faithful migration is to move the configuration itself, not just the data:

1. On the old server, export the configuration database: slapcat -n 0 -l config.ldif.
2. On the new server, with an empty /etc/openldap/slapd.d, load it: slapadd -n 0 -F /etc/openldap/slapd.d -l config.ldif.
3. Then perform the data import with slapadd as shown above.

This brings over your schemas, indexes, suffix definitions, and overlays exactly as they were, eliminating most schema-mismatch problems in one step.

If You Actually Wanted 389 Directory Server

Sometimes a migration guide written for Red Hat Directory Server or 389 DS gets followed on an OpenLDAP server by mistake. If your destination really is 389 DS, install that product's packages instead of openldap-servers; dsconf arrives with them. At that point the two servers are different products with incompatible on-disk formats, so the migration plan (rather than just the import command) needs to change too.

Frequently Asked Questions

Can I install dsconf and use it against OpenLDAP?

No. dsconf only understands 389 Directory Server instances and their configuration. Pointing it at an OpenLDAP server will not work, and installing it drags in the entire 389-ds-base package set unnecessarily.

What package provides dsconf on RHEL?

python3-lib389, which is part of the 389 Directory Server suite. Confirm with dnf provides dsconf on your specific release.

Why does slapd fail to start after my import?

Almost always a file ownership problem. If you ran slapadd as root, the database files under /var/lib/ldap belong to root, and the ldap service account cannot open them. Fix with chown -R ldap:ldap /var/lib/ldap.

Does slapadd require the server to be stopped?

Yes. slapadd writes directly to the database files and is meant for offline use. Use ldapadd over the network if you need to load entries into a running server.

Is openldap-servers from CodeReady Builder supported?

Red Hat does not offer production support for the OpenLDAP server packages on RHEL 8; they are provided in that repository for build and compatibility purposes. If support matters, consider Red Hat Directory Server (389 DS) as your target platform.

How do I verify the import succeeded?

Start slapd and run a search against the suffix, e.g. ldapsearch -x -b "dc=example,dc=com" -s base, then spot-check entry counts against the source server with a subtree-scoped search.