Re: Manual step in upgrade process for a FSWC

2023-09-04 Thread Iker Pedrosa 
Hi,

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

___
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

Re: Manual step in upgrade process for a FSWC

2023-08-31 Thread Fabio Valentini 
On Thu, Aug 31, 2023 at 11:24 AM Iker Pedrosa  wrote:
>
> Hi,
>
> On Wed, Aug 30, 2023 at 8:46 PM Kevin Fenzi  wrote:
>>
>> On Wed, Aug 30, 2023 at 11:59:18AM +0200, 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
>> >  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?
>> >
>> > 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?
>>
>> Will the new version emit some kind of error telling users what needs to
>> happen?
>
>
> It'll log an error but it will be generic, like "user_lookup: could not open 
> database `PATH': %m"
>
>>
>>
>> Will that 'fail closed'? ie, no access granted until the db is
>> converted?
>
>
> I don't understand this question.
>
>>
>>
>> I don't suppose it would be possible to just run the convert at runtime?
>> ie, if old db is found at the configured location convert it to the new
>> version?
>
>
> There are several packages relying in BerkeleyDB and the database team is 
> working in a tool to convert them. So I'd like to avoid replicating the code 
> for each and every package, and instead rely on their tool.

When RPM switched from BerkeleyDB to sqlite, the migration happened
upon first boot after upgrade to the new release, and I thought that
was a nice solution for a tricky problem. Maybe you could you do
something similar?

Fabio
___
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

Re: Manual step in upgrade process for a FSWC

2023-08-31 Thread Steve Grubb 
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
>  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

Re: Manual step in upgrade process for a FSWC

2023-08-31 Thread Iker Pedrosa 
Hi,

On Wed, Aug 30, 2023 at 8:46 PM Kevin Fenzi  wrote:

> On Wed, Aug 30, 2023 at 11:59:18AM +0200, 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
> >  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?
> >
> > 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?
>
> Will the new version emit some kind of error telling users what needs to
> happen?
>

It'll log an error but it will be generic, like "user_lookup: could not
open database `PATH': %m"


>
> Will that 'fail closed'? ie, no access granted until the db is
> converted?
>

I don't understand this question.


>
> I don't suppose it would be possible to just run the convert at runtime?
> ie, if old db is found at the configured location convert it to the new
> version?
>

There are several packages relying in BerkeleyDB and the database team is
working in a tool to convert them. So I'd like to avoid replicating the
code for each and every package, and instead rely on their tool.


>
> kevin
> ___
> 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
>


-- 

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

___
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

Re: Manual step in upgrade process for a FSWC

2023-08-30 Thread Kevin Fenzi 
On Wed, Aug 30, 2023 at 11:59:18AM +0200, 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
>  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?
> 
> 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?

Will the new version emit some kind of error telling users what needs to
happen?

Will that 'fail closed'? ie, no access granted until the db is
converted?

I don't suppose it would be possible to just run the convert at runtime?
ie, if old db is found at the configured location convert it to the new
version?

kevin


signature.asc
Description: PGP signature
___
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

Manual step in upgrade process for a FSWC

2023-08-30 Thread Iker Pedrosa 
Hi,

I intend to switch pam_userdb's database provider from BerkeleyDB to GDBM
and I'm writing a Fedora System-Wide Change
 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?

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

___
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