On 02/23/2018 01:53 PM, Martin Kosek wrote:
On 02/23/2018 01:45 PM, Pavel Březina wrote:
> On 02/23/2018 01:29 PM, Martin Kosek wrote:
>> On 02/23/2018 01:25 PM, Alexander Bokovoy wrote:
>>> On pe, 23 helmi 2018, Pavel Březina via FreeIPA-devel wrote:
>>>> On 02/23/2018 12:57 PM, Martin Kosek wrote:
>>>>> On 02/21/2018 10:25 AM, Pavel Březina via FreeIPA-devel wrote:
>>>>>>> couple of scenarious here:
>>>>>>> - install server
>>>>>>> install it and configure with authselect. there is no
>>>>>>> for the server installation
>>>>>>> - upgrade server
>>>>>>> bakup authselect configuration. apply authselect sssd
>>>>>>> overwriting what was there before.
>>>>>> Why do you call authselect during server update? Shouldn't
>>>>>> system be
>>>>>> already configured?
>>>>> In FreeIPA server, we want to make sure that authselect profile is
>>>>> activated, so that this FreeIPA server's PAM stack receives
>>>>> updates in case the authselect profile gets some fixes in. If it
>>>>> has the manual PAM configuration via old authconfig, it would not
>>>>> receive such updates. Is that true?
>>>> It is true. But the same applies currently with authconfig. So if
>>>> authconfig is run again during server update than sure, it should be
>>> We do not run authconfig on each server upgrade. An idea to re-write
>>> configuration every upgrade sounds interesting but I don't think we are
>>> close to get it properly implemented before we switch to Ansible
>> I think that here I was thinking more about one-off upgrade, as part of
>> authconfig->authselect migration. My assumption was that authselect
>> would then take care of updating the PAM configuration if template
> We explicitly said in F28 change page that existing configuration will
> not be changed if user is upgrading from lower fedora version, unless
> authconfig(compat)/authselect is run after the upgrade.
And this looks as a safe thing to do on a general Fedora workstation.
However, when that workstation is either a FreeIPA Client or FreeIPA
Server, I would think that we want to update to the latest, greatest,
maintained PAM stack - i.e. authselect.
> So we could do
> this when updating ipa server, however I don't think it is desirable to
> automatically change current configuration on an rpm update in F28 if
> this is not what would happen with authconfig.
I would not limit ourselves with what authconfig does. authselect works
a bit differently, it uses static, tested PAM stack, instead of manual
PAM stack changes.
In this case, switching to this tested PAM stack for FreeIPA Server and
Client in my mind links well to authselect goals - i.e. have these
"tested stacks (profiles) that solve a use-case and are well tested and
) on as
many Servers and Clients as possible and thus limiting Bugzillas about
misconfigured PAM stack.
Upgrade is the main concern here of course - how to detect a situation
when administrator went beyond "authconfig --enable sssd" and actually
did some manual PAM changes we would break during upgrade. That is what
needs to be evaluated, for Client and Server.
Yes, I agree that we want to switch to authselect. However changing
configuration that went beyond authconfig --enable sssd is what makes me
>> Pavel, did we work out the upgrade story of authselect, for the cases
>> when we need to fix something in SSSD/winbind template? Or would it be
>> admin's task to refresh the PAM stack when the template changes?
> There is no story written per say. But this should be handled by rpm
> during upgrade.
You mean authselect rpm?
Yes. If there are changes in shipped profiles, updating to newer version
should update select profile (if it is one of these shipped profiles) on