Changes/389 Directory Server 3.0.0

389_Directory_Server_30

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

389-ds-base upgrade from version 2.4.4 to the latest upstream version 3.0.0 in Fedora. Newly created instances now are using LDMB database by default instead of BerkeleyDB.

Owner

• Name: 389ds Group
• Email: 389-devel (at) lists (dot) fedoraproject (dot) org

Primary contact:

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

Current status

• Targeted release: Fedora Linux 40
• Last updated: 2023-11-08
• [<will be assigned by the Wrangler> devel thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Since Fedora 36 (389-ds-base 2.1.0) The 389 ldap directory server supports two kinds of underlying database:

- Berkeley Database (bdb)
- Lightning Memory-Mapped Database Manager (lmdb)

Newly created instances are still created with bdb by default while libdb is flagged as [deprecated since Fedora 33](Changes/Libdb deprecated - Fedora Project Wiki), this change is about to create lmdb instances by default

Feedback

No feedback yet.

Benefit to Fedora

A step on a way to remove a deprecated piece of software no more supported by upstream community. (See https://fedoraproject.org/wiki/Changes/Libdb_deprecated)

Scope

• Proposal owners:

The change is quite limited in term of code as it is mainly a change of a single default value. And a few changes on configuration tools to increase the visibility of the "db_lib" parameter whose value changed.

(i.e moving the parameter from "advanced" to "standard")

For 389ds people, with the help of freeipa teams the main work to do is:

 to determine is there are regressions while running freeipa test and fix them. 

There is also some documentation update about this parameter.

• Other developers:

The main impact is to determine if the change of database its impact 
 in term of dynamic will not cause trouble. 
( So mostly test for any product that use the ldap server)  
 As directly dependent of 389-ds-base package, freeipa is impacted
  The impact are about the LDAP database specific parameters

 one of the change is to try to get rid of the VLV control in free IPA (even if it is implemented 

• Release engineering: #Releng issue number

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

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

• Alignment with Community Initiatives:

Upgrade/compatibility impact

No impact on upgrade because existing instances still use the previously installed backend interface.

There should not have any compatibility issue (bug excepted) with the ldap requests but performances may be impacted.

There may be issue with application that explicitly:

- configures 389 directory server instances (like freeipa) because the set of configuration attribute for the backend depends of the underlying database implementation.

 The unused parameter are ignored so it should not impact the compatibility
 But there is a risk for the new parameters: The "20 Gb" default value for the lmdb database maximum size may not be large enough for the application need.

- monitor 389 directory server backends because the the set of attributes in the monitoring entries also depends of the underlying database implementation.

more details about these points are described in [389 Directory Server FAQ - BerkeleyDB backend deprecation](https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html)

How To Test

a COPR project https://copr.fedorainfracloud.org/coprs/g/389ds/389-ds-base-freeipa-tests/

contains the build that can be tested ( F37, F38, F39, rawhide on x86_64 and s390x ) So you can install them by using:

sudo dnf copr enable -y @389ds/389-ds-base-freeipa-tests
sudo dnf install 389-ds-base-3.0.0

Then you can create new directory server instances and use them.

User Experience

Prepare the removal of an obsolete piece of software which is no more supported by upstream community and provides more visibility to the replacement.

Dependencies

All the dependent packages are owned by 389ds and freeipa teams:

dnf repoquery --whatrequires 389-ds-base --recursive

Package	Owner	Tests
389-ds-base-snmp	389ds	Tested by 389ds CI test
389-ds-base-snmp	389ds	Tested by 389ds CI test
cockpit-389-ds	389ds	Tested by 389ds CI test
cockpit-389-ds	389ds	Tested by 389ds CI test
freeipa-fas	freeipa	Tested by freeipa CI test
freeipa-healthcheck	freeipa	Tested by freeipa CI test
freeipa-healthcheck	freeipa	Tested by freeipa CI test
freeipa-server	freeipa	Tested by freeipa CI test
freeipa-server	freeipa	Tested by freeipa CI test
freeipa-server-dns	freeipa	Tested by freeipa CI test
freeipa-server-dns	freeipa	Tested by freeipa CI test
freeipa-server-trust-ad	freeipa	Tested by freeipa CI test
freeipa-server-trust-ad	freeipa	Tested by freeipa CI test
migrationtools	389ds	Not impacted by the change
slapi-nis	freeipa	Tested by freeipa CI test

Contingency Plan

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

Contingency mechanism: - Revert the default backend implementation to Berkeley Database - if libdb-5.3/libdb-devel are no more delivered: build it locally and link it as a static libraries. (It will probably be done anyway to handle the db migration)

Contingency deadline: Fedora 40 branching from Rawhide Blocks release? No

• Contingency deadline: The beta freeze (2024-02-20)
• Blocks release? No

Documentation

389 Directory Server FAQ - BerkeleyDB backend deprecation: https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html

Release Notes

Need to add write release notes for 3.0.0 in https://www.port389.org/docs/389ds/releases/release-notes.html as usual for 389ds.