Changes/389 Directory Server 3.1.3

389 Directory Server - read-only BDB support

Summary

Starting from 389-ds-base version 3.1.3, the 389 Directory Server no longer supports the deprecated BerkeleyDB, so the LDMB database must be used. Users still using BerkeleyDB will have to migrate their data. In Fedora this change is available starting from Fedora 43 (Version 3.2.0 that was also originally planned for Fedora 43 is delayed.)

Owner

• Name: 389 Directory Server Development Team

Primary contact:

• Name: Pierre Rogier
• Email: progier (at) redhat (dot) com

Current status

• Targeted release: Fedora Linux 43
• Last updated: 2025-09-15
• Announced
• Discussion thread
• FESCo issue: #3432
• Tracker bug: #2383281
• Release notes tracker: #249

Detailed Description

389-ds-base support of BerkeleyDB is deprecated since F40: Changes/389_Directory_Server_3.0.0. In F43 with 389-ds-base version 3.1.3:

• 389-ds-base dependency towards libdb is removed.
• A new 389-ds-base-robdb-libs package implements a BerkeleyDb reader that allows exporting databases into ldif and performing the migration toward lmdb. This package should be supported until at least F45

Feedback

No feedback yet.

Benefit to Fedora

Yet another step on the way to remove a deprecated piece of software no longer supported by the upstream community. (See https://fedoraproject.org/wiki/Changes/Libdb_deprecated) A final step is planned in Fedora 46 about removing the 389-ds-base-robdb-libs package and get fully rid of BerkeleyDB support in 389 Directory Server

Scope

• Proposal owners:

Limited change are needed (Proof of concept exists so what remains is mostly rebasing the pull request, reviewing the changes and testing them)

• Other developers: N/A (not needed for this Change)

• Release engineering: #Releng issue number

No coordination needed.

• Policies and guidelines: N/A (not needed for this Change)
• Trademark approval: N/A (not needed for this Change)

• Alignment with the Fedora Strategy:

Upgrade/compatibility impact

• The directory server no longer support the BerkeleyDB implementation that is obsolete since Fedora 40 [1].
• Directory server instances already using lmdb as database are not impacted. (typically those created with Fedora 40 and after)
• freeipa is not impacted because it already uses lmdb since Fedora 40
• The other applications that use the directory server through LDAP API are not impacted by the directory server database internal implementation.
• Data migration is required if the Directory Server instances are still configured with BerkeleyDB.
• In that case, the data migration should then be performed using dsctl dblib bdb2mdb command or manually following the 389ds Berkeley DB deprecation FAQ [2] instructions

Early Testing (Optional)

N/A

Do you require 'QA Blueprint' support? N

How To Test

Mainly the test will need to:

• 389-ds-base package should build successfully
• Check that starting instance configured with bdb is failing and logs an error message (both in dirsrv error log and in the system journal) telling that database should be upgraded
• Run dsctl dblib bdb2mdb command
• Check that instance can now be started

User Experience

Directory server instances created since Fedora 40 and using the default lmdb database are not impacted (that is typically the case for freeipa users).

But users still using BerkeleyDB (either because they have not yet migrated or because they explicitly choose to use BerkeleyDB) are required to migrate to lmdb.

If this step is not done, the instance will not be able to start after the upgrade and the following error message is displayed in the dirsrv error log and in the system journal: bdb implementation is no longer supported. Directory server cannot be started without migrating to lmdb first. To migrate, please run: dsctl instanceName dblib bdb2mdb

User then needs to migrate the data either using the dsctl command or manually by following the https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html#manual-method---export-to-ldif steps

Dependencies

None

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change)

Documentation

N/A (not a System Wide Change)