From Fedora Project Wiki
(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.)
 
(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.)
Line 15: Line 15:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:389ds| 389 Directory Server Group]]
* Name: [[User:389ds| 389ds Group]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
* Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
Primary contact:
* Name: [[User:progier| Pierre Rogier]]
* Name: [[User:progier| Pierre Rogier]]
* Email: progier AT redhat DOT com
* Email: progier AT redhat DOT com
Line 50: Line 51:
== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
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 ==
== Feedback ==
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
No feedback yet.


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
A step on a way to remove a deprecated piece of software.
 
      Be sure to include the following areas if relevant:
      If this is a major capability update, what has changed?
          For example: This change introduces Python 5 that runs without the Global Interpreter Lock and is fully multithreaded.
      If this is a new functionality, what capabilities does it bring?
          For example: This change allows package upgrades to be performed automatically and rolled-back at will.
      Does this improve some specific package or set of packages?
          For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies.
      Does this improve specific Spins or Editions?
          For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server.
      Does this make the distribution more efficient?
          For example: This change replaces thousands of individual %post scriptlets in packages with one script that runs at the end.
      Is this an improvement to maintainer processes?
          For example: Gating Fedora packages on automatic QA tests will make rawhide more stable and allow changes to be implemented more smoothly.
      Is this an improvement targeted as specific contributors?
          For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors.  


    When a Change has multiple benefits, it's better to list them all.
    Consider these Change pages from previous editions as inspiration:
    https://fedoraproject.org/wiki/Changes/Annobin (low-level and technical, invisible to users)
    https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo (low-level, but visible to advanced users)
    https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration (primarily a UX change)
    https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an improvement to distro processes)
    https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->


== Scope ==
== Scope ==
Line 105: Line 89:
== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
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)


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 123: Line 121:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
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.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 143: Line 153:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Mainly freeipa packages:
`dnf repoquery --whatrequires 389-ds-base  --recursive`
| Package                | Risk mitigation                                                                                                        |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| 389-ds-base-snmp        | Tested by 389ds CI test                                                                                                |
| 389-ds-base-snmp        | Tested by 389ds CI test                                                                                                |
| cockpit-389-ds          | Tested by 389ds CI test                                                                                                |
| cockpit-389-ds          | Tested by 389ds CI test                                                                                                |
| freeipa-fas            | Tested by freeipa CI test                                                                                              |
| freeipa-healthcheck    | Tested by freeipa CI test                                                                                              |
| freeipa-healthcheck    | Tested by freeipa CI test                                                                                              |
| freeipa-server          | Tested by freeipa CI test                                                                                              |
| freeipa-server          | Tested by freeipa CI test                                                                                              |
| freeipa-server-dns      | Tested by freeipa CI test                                                                                              |
| freeipa-server-dns      | Tested by freeipa CI test                                                                                              |
| freeipa-server-trust-ad | Tested by freeipa CI test                                                                                              |
| freeipa-server-trust-ad | Tested by freeipa CI test                                                                                              |
| migrationtools          | Not impacted by the change (these script working on ldap entries using ldap protocol which is tested by 389ds CI test) |
| slapi-nis              | Tested by freeipa CI test                                                                                              |




Line 159: Line 190:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
 
389 Directory Server FAQ - BerkeleyDB backend deprecation: https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html


== Release Notes ==
== Release Notes ==
Line 167: Line 199:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
Need add write release notes for 3.0.0 in https://www.port389.org/docs/389ds/releases/release-notes.html

Revision as of 17:03, 7 November 2023

389_Directory_Server_30

Important.png
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: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>

Primary contact:


Current status

  • Targeted release: Fedora Linux 40
  • Last updated: 2023-11-07
  • [<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.


Scope

  • Proposal owners:
  • Other developers:
  • 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

Dependencies

Mainly freeipa packages:

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

| Package | Risk mitigation | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------- | | 389-ds-base-snmp | Tested by 389ds CI test | | 389-ds-base-snmp | Tested by 389ds CI test | | cockpit-389-ds | Tested by 389ds CI test | | cockpit-389-ds | Tested by 389ds CI test | | freeipa-fas | Tested by freeipa CI test | | freeipa-healthcheck | Tested by freeipa CI test | | freeipa-healthcheck | Tested by freeipa CI test | | freeipa-server | Tested by freeipa CI test | | freeipa-server | Tested by freeipa CI test | | freeipa-server-dns | Tested by freeipa CI test | | freeipa-server-dns | Tested by freeipa CI test | | freeipa-server-trust-ad | Tested by freeipa CI test | | freeipa-server-trust-ad | Tested by freeipa CI test | | migrationtools | Not impacted by the change (these script working on ldap entries using ldap protocol which is tested by 389ds CI test) | | slapi-nis | Tested by freeipa CI test |


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), Yes/No


Documentation

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

Release Notes

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/389_Directory_Server_3.0.0&oldid=693850"