On Wednesday, August 30, 2023 5:59:18 AM EDT Iker Pedrosa wrote: > Hi, > > I intend to switch pam_userdb's database provider from BerkeleyDB to GDBM > and I'm writing a Fedora System-Wide Change > <https://fedoraproject.org/wiki/Changes/PamBerkeleyDBtoGdbm> for Fedora 40. > The upgrade process would involve a manual procedure where the user needs > to run a conversion tool for the database. Is this acceptable? In the past, we had new requirements for bad password lockouts that did not fit into pam_tally neatly. So, we created pam_tally2 to let people migrate to the version that met requirements back in the day. Then the requirements changed again, so we created pam_faillock. This was all to allow people to migrate to the new requirements, which had radically different file formats. We didn't see a reliable way to move people and just left it to the admin. Not that you have to do it this way. But I thought I'd mention how we navigated changes in the past. The main thing is we didn't want people getting locked out by an incompatible change in the pam stack. (Especially for remote logins.) -Steve > An automation process could be created, but the location of the database is > configurable, which increases its complexity and effort. Especially for a > PAM module that is not widely used. Another option I can think of is to > automate the conversion process for the default location, and leave the > manual conversion for those using a tuned location. Would that be > acceptable? _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
