From Fedora Project Wiki
(Add the first draft)
 
(Obviated by OpenLDAP 2.6)
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= [DRAFT] Ship BerkleyDB backend as a module =
= Ship BerkleyDB backend as a module =


== Summary ==
== Summary ==
Change the *openldap-servers* package so that BDB and HDB backends are required to be dynamically loaded.
Change the ''openldap-servers'' package so that BDB and HDB backends are required to be dynamically loaded.


== Owner ==
== Owner ==
* Name: [[User:mhonek| Matus Honek]]
* Name: Simon Pichugin
* Email: mhonek (at) redhat (dot) com
* Email: spichugi (at) redhat (dot) com
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>


== Current status ==
== Current status ==
* Targeted release: [[Releases/31 | Fedora 31 ]]  
[[Category:ChangePageIncomplete]]
[[Category:SelfContainedChange]]
 
* Targeted release: [[Releases/36 | Fedora Linux 36 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 19: Line 21:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1740811 #1740811]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/377 #377]


== Detailed Description ==
== Detailed Description ==


So far the BDB and HDB were statically built with the *slapd* binary and merely declaring *database bdb* or *database hdb* would just work. Change introduces an additional requirement of explicitly declaring to load the backend's SO file according to the documentation of dynamic modules. The respective new modules will be shipped similarly to the rest of the already shipped modules.
So far the BDB and HDB were statically built with the ''slapd'' binary and merely declaring `database bdb` or `database hdb` would just work. Change introduces an additional requirement of explicitly declaring to load the backend's SO file according to the documentation of dynamic modules. The respective new modules will be shipped similarly to the rest of the already shipped modules.


This change is directed to conduct a smoother experience before the backends are removed in a next Fedora release.
This change is directed to conduct a smoother experience before the backends are removed in a next Fedora release. Current configurations using BDB or HDB backend would break, however are easily fixable by a single change; this is intentional as due to the upcoming removal of these backends users should be aware of the necessity to migrate to a different backend in a near future (see [[#User Experience]] for more).


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 53: Line 55:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
Server using BDB or HDB backends without modified configuration would fail to start. See ''User Experience'' section for more information.


== How To Test ==
== How To Test ==
Line 74: Line 76:


== User Experience ==
== User Experience ==
To remediate the impact of the change the systemd service file shipped with the package will contain a ''pre-start'' script which, in case the server is configured with BDB or HDB backend, will halt the startup and notify the user with a message describing what and why happened, and what steps to take to mitigate the issue.
If a user is using either BDB or HDB they have two options:
If a user is using either BDB or HDB they have two options:
*  migrate to the fully supported MDB backend (preferred)
*  migrate to the fully supported MDB backend (preferred)
*  add a *moduleload* configuration declaration (discouraged)
*  add a `moduleload` configuration declaration (discouraged)


=== Migrating to MDB ===
=== Migrating to MDB ===
The steps required to migrate a database are following:
The steps required to migrate a database are following:
*  Stop the slapd server
*  Stop the slapd server.
*  Export data to an LDIF file using *slapcat*
*  Export data to an LDIF file using ''slapcat''.
*  Change the server's configuration removing the BDB/HDB sections and add a new MDB section
*  Change the server's configuration replacing the BDB/HDB sections with its MDB counterparts.
*  Import data to a new database from the LDIF file using *slapadd*
*  Import data to a new database from the LDIF file using ''slapadd''.
*  Start the slapd server
*  Start the slapd server.


=== ModuleLoad the BDB/HDB backend ===
=== ModuleLoad the BDB/HDB backend ===
Depending on the configuration style and backend type, user should add a declaration in order to load the backend library: add option *moduleload* (slapd.conf(5), section _GLOBAL CONFIGURATION OPTIONS_) or attribute *olcModuleLoad* (slapd-config(5), section _DYNAMIC MODULE OPTIONS_) with value *back_bdb* and/or *back_hdb*.
Depending on the configuration style and backend type, user should add a declaration in order to load the backend library: add option `moduleload` (slapd.conf(5), section ''GLOBAL CONFIGURATION OPTIONS'') or attribute `olcModuleLoad` (slapd-config(5), section ''DYNAMIC MODULE OPTIONS'') with value `back_bdb` and/or `back_hdb`.


== Dependencies ==
== Dependencies ==
Line 93: Line 97:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
None.


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: Revert the change. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Anytime.
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No.
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? None.


== Documentation ==
== Documentation ==
Line 117: Line 121:
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.  
-->
-->
[[Category:ChangePageIncomplete]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
<!-- [[Category:SystemWideChange]] -->

Latest revision as of 00:00, 9 February 2022

Ship BerkleyDB backend as a module

Summary

Change the openldap-servers package so that BDB and HDB backends are required to be dynamically loaded.

Owner

  • Name: Simon Pichugin
  • Email: spichugi (at) redhat (dot) com

Current status

Detailed Description

So far the BDB and HDB were statically built with the slapd binary and merely declaring database bdb or database hdb would just work. Change introduces an additional requirement of explicitly declaring to load the backend's SO file according to the documentation of dynamic modules. The respective new modules will be shipped similarly to the rest of the already shipped modules.

This change is directed to conduct a smoother experience before the backends are removed in a next Fedora release. Current configurations using BDB or HDB backend would break, however are easily fixable by a single change; this is intentional as due to the upcoming removal of these backends users should be aware of the necessity to migrate to a different backend in a near future (see #User Experience for more).

Benefit to Fedora

A step on a way to remove unsupported (both by OpenLDAP and BerkleyDB upstream) piece of software.

Scope

  • Proposal owners:

Change the SPEC file accordingly.

  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Server using BDB or HDB backends without modified configuration would fail to start. See User Experience section for more information.

How To Test

N/A (not a System Wide Change)

User Experience

To remediate the impact of the change the systemd service file shipped with the package will contain a pre-start script which, in case the server is configured with BDB or HDB backend, will halt the startup and notify the user with a message describing what and why happened, and what steps to take to mitigate the issue.

If a user is using either BDB or HDB they have two options:

  • migrate to the fully supported MDB backend (preferred)
  • add a moduleload configuration declaration (discouraged)

Migrating to MDB

The steps required to migrate a database are following:

  • Stop the slapd server.
  • Export data to an LDIF file using slapcat.
  • Change the server's configuration replacing the BDB/HDB sections with its MDB counterparts.
  • Import data to a new database from the LDIF file using slapadd.
  • Start the slapd server.

ModuleLoad the BDB/HDB backend

Depending on the configuration style and backend type, user should add a declaration in order to load the backend library: add option moduleload (slapd.conf(5), section GLOBAL CONFIGURATION OPTIONS) or attribute olcModuleLoad (slapd-config(5), section DYNAMIC MODULE OPTIONS) with value back_bdb and/or back_hdb.

Dependencies

None.

Contingency Plan

  • Contingency mechanism: Revert the change.
  • Contingency deadline: Anytime.
  • Blocks release? No.
  • Blocks product? None.

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/OpenLDAPwithBerkleyDBasModule&oldid=636205"