Hello Stephen, I've made changes according to your notes [1], please have a look. And thanks for the feedback! [1] https://fedoraproject.org/w/index.php?title=Changes%2FOpenLDAPwithBerkleyDBasModule&type=revision&diff=549672&oldid=549258 On Thu, Aug 1, 2019 at 1:49 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > On Thu, Aug 1, 2019 at 6:57 AM Matus Honek <mhonek@xxxxxxxxxx> wrote: > > > > On Wed, Jul 31, 2019 at 4:57 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > > > On Tue, Jul 23, 2019 at 8:45 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > > > > > > > https://fedoraproject.org/wiki/Changes/OpenLDAPwithBerkleyDBasModule > > > > > > > > == Summary == > > > > Change the ''openldap-servers'' package so that BDB and HDB backends > > > > are required to be dynamically loaded. > > > > > > > > == Owner == > > > > * Name: [[User:mhonek| Matus Honek]] > > > > * Email: mhonek (at) redhat (dot) com > > > > > > > > > > ... > > > > > > > == Upgrade/compatibility impact == > > > > Server using BDB or HDB backends without modified configuration would > > > > fail to start. See ''User Experience'' section for more information. > > > > > > > > > > Is this avoidable or do you consider it desirable? Is there any harm > > > in shipping a default configuration that does the loadmodule for both > > > deprecated backends? > > > > The default configuration is shipped only when the package is newly > > installed. Given the BDB/HDB should not be used there is no point in > > pre-loading these in new instalments. > > > > Understood. > > > > > > > My guess here is that you want this to be an explicit breakage to help > > > users learn that the backend is no longer supported. If that's the > > > case, I'd like to see that spelled out in the Change. > > > > Correct. I thought this was put clearly but I sure can improve this. > > Would be spelling this in Detailed Description section acceptable? > > Yes, please. > > > > > > > > > Do any tools exist to simplify the conversion to MDB? Can this be automated? > > > > I am not aware of any such tools. Numerous demands on upstream were > > always responded with more-or-less what I put in the section > > describing the conversion. If any errors are encountered during the > > process they need to be understood and then fixed manually. > > > > Automatic conversion would be far from trivial (and possibly > > load-intensive depending on sizes). There are two types of > > configuration (plaintext and "the more complicated one"). A server may > > have several instances of backends. Each backend type has its own > > configuration specifics (MDB being easier but still a "human guess" > > should be made to configure the expected size of it). Not rarely users > > put configuration into various locations which are not guessable > > automatically at all. Additionally, users should ideally see the > > possible errors during the process of conversion and verify the data > > has not broken. > > > > One relatively simple thing to provide would be a pre-run script that > > would disallow running the slapd's systemd service if the > > configuration contains BDB/HDB instances and the moduleload is not > > present, writing into journal clearly what happened and what needs to > > be done. > > > > This would be highly desirable. It would go a long way towards helping > users understand the transition. Including a web link in the journal > message to a detailed conversion HOWTO would be ideal. > > > This is not to give reasons not to automate the process, rather > > explain that understanding and thought needs to go into each > > instalment's conversion(s). > > Sure, makes sense. Thank you for clarifying. -- Matúš Honěk Software Engineer Red Hat Czech _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
