Hi, On Thu, Aug 31, 2023 at 6:50 PM Steve Grubb <sgr...@redhat.com> wrote:
> 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.) > Thank you for sharing this experience, I see that similar approaches have been used in the past. > > -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? > > > > > -- Iker Pedrosa Senior Software Engineer, Identity Management team Red Hat <https://www.redhat.com> Txapela (gorria) buruan eta ibili munduan (Red) hat on his head and walk the world Basque proverb <https://www.redhat.com>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue