Hi,

On Thu, Aug 31, 2023 at 6:50 PM Steve Grubb <sgrubb@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

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb