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

Reply via email to