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@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

Reply via email to