From Fedora Project Wiki
< Changes
(Add the first draft) |
(Changing to Wrangler.) |
||
| Line 1: | Line 1: | ||
= | = Ship BerkleyDB backend as a module = | ||
== Summary == | == Summary == | ||
Change the | Change the ''openldap-servers'' package so that BDB and HDB backends are required to be dynamically loaded. | ||
== Owner == | == Owner == | ||
| Line 24: | Line 24: | ||
== Detailed Description == | == Detailed Description == | ||
So far the BDB and HDB were statically built with the | 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. | ||
| Line 53: | Line 53: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
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 76: | Line 76: | ||
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 | * 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 | * Export data to an LDIF file using ''slapcat''. | ||
* Change the server's configuration | * 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 | * 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 | 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 93: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
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: | * 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: | * 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? | * Blocks release? No. | ||
* Blocks product? | * Blocks product? None. | ||
== Documentation == | == Documentation == | ||
| Line 118: | Line 118: | ||
--> | --> | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Revision as of 09:40, 23 July 2019
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: Matus Honek
- Email: mhonek (at) redhat (dot) com
- FESCo shepherd: Shehperd name <email address>
Current status
- Targeted release: Fedora 31
- Last updated: 2019-07-23
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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.
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)
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- 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
If a user is using either BDB or HDB they have two options:
- migrate to the fully supported MDB backend (preferred)
- add a
moduleloadconfiguration 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)