subject:"\[Freeipa\-devel\] Re\: authconfig replacement design"

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 --no-sssd
>>> option
>>> for the server installation
>>> - upgrade server
>>>  bakup authselect configuration. apply authselect sssd profile
>>> overwriting what was there before.
>>
>> Why do you call authselect during server update? Shouldn't the
>> 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 further
> updates in case the authselect profile gets some fixes in. If it still
> 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
 there.
>>> 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
>>> installer...
>>
>> 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
>> changes.
> 
> 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
supported" (https://fedoraproject.org/wiki/Changes/Authselect) 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.

>> 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?
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-23 Thread Pavel Březina via FreeIPA-devel


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 --no-sssd
option
for the server installation
- upgrade server
 bakup authselect configuration. apply authselect sssd profile
overwriting what was there before.


Why do you call authselect during server update? Shouldn't the
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 further
updates in case the authselect profile gets some fixes in. If it still
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
there.

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
installer...


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 changes.


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



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.


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

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 --no-sssd
> option
> for the server installation
> - upgrade server
>  bakup authselect configuration. apply authselect sssd profile
> overwriting what was there before.

 Why do you call authselect during server update? Shouldn't the
 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 further
>>> updates in case the authselect profile gets some fixes in. If it still
>>> 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
>> there.
> 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
> installer...

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 changes.

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?
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-23 Thread Alexander Bokovoy via FreeIPA-devel


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 --no-sssd option
for the server installation
- upgrade server
 bakup authselect configuration. apply authselect sssd profile
overwriting what was there before.


Why do you call authselect during server update? Shouldn't the 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 further
updates in case the authselect profile gets some fixes in. If it still
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 
there.

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
installer...

--
/ Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-23 Thread Pavel Březina via FreeIPA-devel


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 --no-sssd option
for the server installation
- upgrade server
  bakup authselect configuration. apply authselect sssd profile
overwriting what was there before.


Why do you call authselect during server update? Shouldn't the 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 further
updates in case the authselect profile gets some fixes in. If it still
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 there.





- upgrade client
  not applicable. only new binaries are copied onto the system


I would think that we want the same as on the FreeIPA server. I.e. if we
detect that FreeIPA client is configured with SSSD, we switch to a
supported authselect PAM stack and thus receive further updates, without
being stuck with manual authconfig PAM stack.

Martin


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On 02/21/2018 03:39 PM, Rob Crittenden via FreeIPA-devel wrote:
>>> - install client
>>>   a) if we replace rpm dependancy on authconfig with aushselect we can
>>> go only this way: new installations done with authselect. if --no-sssd
>>> option is provided, then fail.
>> --no-sssd option is already deprecated and should not be used, you don't
>> have to think about that scenario. You can therefore go the a) way and
>> remove the option as a whole so that you can be sure it won't fiddle
>> with new installations.
> I can't seem to find anywhere that this deprecation was announced or
> discussed other than the ticket and commit,
> dfc271fdf4514481c11c342fabda135feeb44de6.
> 
> Did anyone ask users, or anyone, if they use this option?
> 
> In any case it isn't even clear that the option *is* deprecated. It just
> doesn't show as an option to ipa-client -install (hiding is not
> deprecating).
> 
> IMHO to properly deprecate something it should yell loudly whenever
> invoked with a dire warning that it will disappear in the future.

This mostly seems as a review feedback that could have come in
https://pagure.io/freeipa/issue/5860
but did not. But it does not change anything on the fact that the option
is deprecated.

> There is also no man page mention of deprecation, in fact the option is
> still there.
> 
> So even if the deprecation is fine and considered, removing the option
> completely has had no visible discussion.

Let's discuss it then. From Fedora/RHEL point of view, I do not see big
value in spending much time in maintaining, supporting or developing
non-SSSD scenarios. Fedora itself does not support these scenarios any
more, after the authselect Fedora change. These very corner cases are
left for manual administrator configuration.

The non-SSSD work and code should be left to FreeIPA platform code, for
platforms that do not use or want to use SSSD.
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-16 Thread Florence Blanc-Renaud via FreeIPA-devel

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 --no-sssd option
>> for the server installation
>> - upgrade server
>>   bakup authselect configuration. apply authselect sssd profile
>> overwriting what was there before.
> 
> Why do you call authselect during server update? Shouldn't the 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 further
updates in case the authselect profile gets some fixes in. If it still
has the manual PAM configuration via old authconfig, it would not
receive such updates. Is that true?

>> - upgrade client
>>   not applicable. only new binaries are copied onto the system

I would think that we want the same as on the FreeIPA server. I.e. if we
detect that FreeIPA client is configured with SSSD, we switch to a
supported authselect PAM stack and thus receive further updates, without
being stuck with manual authconfig PAM stack.

Martin
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-21 Thread Rob Crittenden via FreeIPA-devel

Standa Laznicka via FreeIPA-devel wrote:
> On 02/21/2018 10:17 AM, Alexander Koksharov via FreeIPA-devel wrote:
>> let me put
>>  
>> a
>>  
>> couple of scenarious here:
>> - install server
>>   install it and configure with authselect. there is no --no-sssd
>> option for the server installation
>> - upgrade server
>>   bakup authselect configuration. apply authselect sssd profile
>> overwriting what was there before.
>> - upgrade client
>>   not applicable. only new binaries are copied onto the system
>> - install client
>>   a) if we replace rpm dependancy on authconfig with aushselect we can
>> go only this way: new installations done with authselect. if --no-sssd
>> option is provided, then fail.
> 
> --no-sssd option is already deprecated and should not be used, you don't
> have to think about that scenario. You can therefore go the a) way and
> remove the option as a whole so that you can be sure it won't fiddle
> with new installations.

I can't seem to find anywhere that this deprecation was announced or
discussed other than the ticket and commit,
dfc271fdf4514481c11c342fabda135feeb44de6.

Did anyone ask users, or anyone, if they use this option?

In any case it isn't even clear that the option *is* deprecated. It just
doesn't show as an option to ipa-client -install (hiding is not
deprecating).

IMHO to properly deprecate something it should yell loudly whenever
invoked with a dire warning that it will disappear in the future.

There is also no man page mention of deprecation, in fact the option is
still there.

So even if the deprecation is fine and considered, removing the option
completely has had no visible discussion.

rob

> 
>>   b) if we add authselect as a new dependancy, then we can apply a
>> logic like authselect by default but if no-sssd then do authconfig.
>>
>> The people did talk to are kind of think that a) will bi implemented.
>> I want to finish this task this week. Can we finally agree on a or b ?
>>
>> Alexander
>>
>> On Mon, Feb 19, 2018 at 10:47 AM, Pavel Březina > > wrote:
>>
>> On 02/14/2018 09:15 AM, Alexander Koksharov via FreeIPA-devel wrote:
>>
>> Hello,
>>
>> Please take a look on a design page here:
>> https://www.freeipa.org/page/V4/Authselect_migration
>> 
>> I would like to
>>
>>
>> You will also need to write krb5.conf and ldap.conf. You can see
>> the following man page or compat tool for inspiration.
>>
>> 
>> https://github.com/pbrezina/authselect/blob/master/src/man/authselect-migration.7.txt.in.in
>> 
>> 
>> 
>> https://github.com/pbrezina/authselect/blob/master/src/compat/snippets/authconfig-krb.conf
>> 
>> 
>>
>>  
>> hear you critics and suggessions.
>>
>> Thank you
>>
>> --
>> Alexander
>>
>>
>> ___
>> FreeIPA-devel mailing list --
>> freeipa-devel@lists.fedorahosted.org
>> 
>> To unsubscribe send an email to
>> freeipa-devel-le...@lists.fedorahosted.org
>> 
>>
>>
>>
>>
>>
>> ___
>> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
> 
> 
> -- 
> Standa Láznička
> A Red Hat person
> PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
> 
> 
> 
> ___
> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
> 
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-21 Thread Standa Laznicka via FreeIPA-devel

On 02/21/2018 10:17 AM, Alexander Koksharov via FreeIPA-devel wrote:
> let me put
>  
> a
>  
> couple of scenarious here:
> - install server
>   install it and configure with authselect. there is no --no-sssd
> option for the server installation
> - upgrade server
>   bakup authselect configuration. apply authselect sssd profile
> overwriting what was there before.
> - upgrade client
>   not applicable. only new binaries are copied onto the system
> - install client
>   a) if we replace rpm dependancy on authconfig with aushselect we can
> go only this way: new installations done with authselect. if --no-sssd
> option is provided, then fail.

--no-sssd option is already deprecated and should not be used, you don't
have to think about that scenario. You can therefore go the a) way and
remove the option as a whole so that you can be sure it won't fiddle
with new installations.

>   b) if we add authselect as a new dependancy, then we can apply a
> logic like authselect by default but if no-sssd then do authconfig.
>
> The people did talk to are kind of think that a) will bi implemented.
> I want to finish this task this week. Can we finally agree on a or b ?
>
> Alexander
>
> On Mon, Feb 19, 2018 at 10:47 AM, Pavel Březina  > wrote:
>
> On 02/14/2018 09:15 AM, Alexander Koksharov via FreeIPA-devel wrote:
>
> Hello,
>
> Please take a look on a design page here:
> https://www.freeipa.org/page/V4/Authselect_migration
> 
> I would like to
>
>
> You will also need to write krb5.conf and ldap.conf. You can see
> the following man page or compat tool for inspiration.
>
> 
> https://github.com/pbrezina/authselect/blob/master/src/man/authselect-migration.7.txt.in.in
> 
> 
> 
> https://github.com/pbrezina/authselect/blob/master/src/compat/snippets/authconfig-krb.conf
> 
> 
>
>  
> hear you critics and suggessions.
>
> Thank you
>
> --
> Alexander
>
>
> ___
> FreeIPA-devel mailing list --
> freeipa-devel@lists.fedorahosted.org
> 
> To unsubscribe send an email to
> freeipa-devel-le...@lists.fedorahosted.org
> 
>
>
>
>
>
> ___
> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org


-- 
Standa Láznička
A Red Hat person
PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3



signature.asc
Description: OpenPGP digital signature
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-21 Thread Alexander Koksharov via FreeIPA-devel

I would like to hear more from IPA people. It is not a problem to replace
authconfig related code with something else.
My questions are more about what we will get after the change and whether
this will be what we actually want.

Alexander

On Wed, Feb 21, 2018 at 10:25 AM, Pavel Březina  wrote:

> On 02/21/2018 10:17 AM, Alexander Koksharov wrote:
>
>> let me put
>>  
>> a
>>  
>> couple of scenarious here:
>> - install server
>>   install it and configure with authselect. there is no --no-sssd option
>> for the server installation
>> - upgrade server
>>   bakup authselect configuration. apply authselect sssd profile
>> overwriting what was there before.
>>
>
> Why do you call authselect during server update? Shouldn't the system be
> already configured?
>
> - upgrade client
>>   not applicable. only new binaries are copied onto the system
>> - install client
>>   a) if we replace rpm dependancy on authconfig with aushselect we can
>> go only this way: new installations done with authselect. if --no-sssd
>> option is provided, then fail.
>>   b) if we add authselect as a new dependancy, then we can apply a logic
>> like authselect by default but if no-sssd then do authconfig.
>>
>> The people did talk to are kind of think that a) will bi implemented. I
>> want to finish this task this week. Can we finally agree on a or b ?
>>
>
> A. Authconfig will not be available. Only though compat tool, but that
> provides only a minimum level of compatibility and translates calls to
> authselect.
>
>
>> Alexander
>>
>> On Mon, Feb 19, 2018 at 10:47 AM, Pavel Březina > > wrote:
>>
>> On 02/14/2018 09:15 AM, Alexander Koksharov via FreeIPA-devel wrote:
>>
>> Hello,
>>
>> Please take a look on a design page here:
>> https://www.freeipa.org/page/V4/Authselect_migration
>> 
>> I would like to
>>
>>
>> You will also need to write krb5.conf and ldap.conf. You can see the
>> following man page or compat tool for inspiration.
>>
>> https://github.com/pbrezina/authselect/blob/master/src/man/
>> authselect-migration.7.txt.in.in
>> > authselect-migration.7.txt.in.in>
>> https://github.com/pbrezina/authselect/blob/master/src/compa
>> t/snippets/authconfig-krb.conf
>> > at/snippets/authconfig-krb.conf>
>>
>>  
>> hear you critics and suggessions.
>>
>> Thank you
>>
>> --
>> Alexander
>>
>>
>> ___
>> FreeIPA-devel mailing list --
>> freeipa-devel@lists.fedorahosted.org
>> 
>> To unsubscribe send an email to
>> freeipa-devel-le...@lists.fedorahosted.org
>> 
>>
>>
>>
>>
>
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-21 Thread Pavel Březina via FreeIPA-devel

On 02/21/2018 10:17 AM, Alexander Koksharov wrote:

let me put

couple of scenarious here:
- install server
install it and configure with authselect. there is no --no-sssd option
for the server installation
- upgrade server
bakup authselect configuration. apply authselect sssd profile
overwriting what was there before.

Why do you call authselect during server update? Shouldn't the system be
already configured?

- upgrade client
not applicable. only new binaries are copied onto the system
- install client
a) if we replace rpm dependancy on authconfig with aushselect we can
go only this way: new installations done with authselect. if --no-sssd
option is provided, then fail.
b) if we add authselect as a new dependancy, then we can apply a logic
like authselect by default but if no-sssd then do authconfig.

The people did talk to are kind of think that a) will bi implemented. I
want to finish this task this week. Can we finally agree on a or b ?

A. Authconfig will not be available. Only though compat tool, but that
provides only a minimum level of compatibility and translates calls to
authselect.

Alexander

On Mon, Feb 19, 2018 at 10:47 AM, Pavel Březina > wrote:

On 02/14/2018 09:15 AM, Alexander Koksharov via FreeIPA-devel wrote:

Hello,

Please take a look on a design page here:
https://www.freeipa.org/page/V4/Authselect_migration

I would like to

You will also need to write krb5.conf and ldap.conf. You can see the
following man page or compat tool for inspiration.

https://github.com/pbrezina/authselect/blob/master/src/man/authselect-migration.7.txt.in.in

https://github.com/pbrezina/authselect/blob/master/src/compat/snippets/authconfig-krb.conf

hear you critics and suggessions.

Thank you

--
Alexander

___
FreeIPA-devel mailing list --
freeipa-devel@lists.fedorahosted.org

To unsubscribe send an email to
freeipa-devel-le...@lists.fedorahosted.org

___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-19 Thread Pavel Březina via FreeIPA-devel


On 02/14/2018 09:15 AM, Alexander Koksharov via FreeIPA-devel wrote:

Hello,

Please take a look on a design page here:
https://www.freeipa.org/page/V4/Authselect_migration
I would like to


You will also need to write krb5.conf and ldap.conf. You can see the 
following man page or compat tool for inspiration.


https://github.com/pbrezina/authselect/blob/master/src/man/authselect-migration.7.txt.in.in
https://github.com/pbrezina/authselect/blob/master/src/compat/snippets/authconfig-krb.conf


 
hear you critics and suggessions.

Thank you

--
Alexander


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-19 Thread Pavel Březina via FreeIPA-devel


On 02/16/2018 07:34 PM, Florence Blanc-Renaud via FreeIPA-devel wrote:

On 02/14/2018 09:15 AM, Alexander Koksharov via FreeIPA-devel wrote:

Hello,

Please take a look on a design page here:
https://www.freeipa.org/page/V4/Authselect_migration
I would like to
 
hear you critics and suggessions.

Thank you

--
Alexander


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-devel-le...@lists.fedorahosted.org


Hi Lex,

Thank you for the document, it is a good thing to discuss features based
on written material :)

The design only mentions ipa-client-install, but we also rely on
authconfig in various ipa-advise scripts (ipa-advise command creates a
script that can be run by the sysadmin, for instance to configure smart
card authentication with ipa-advise config-client-for-smart-card-auth,
and the script calls authconfig).

freeipa.spec.in defines a dependency on authconfig, will it be turned
into a weak dependency? Will we add a dependency on authselect instead?

Backup and restore refer to the directory /var/lib/authconfig/last/ and
the file /etc/sysconfig/authconfig, does it need to be adapted for
authselect or does the tool use the same dir and files?


Authselect does not perform backup and restore. If system is configured 
with authselect you will get always exact configuration because it 
writes the whole file, it does not insert lines like authconfig. And if 
it is not configured with authselect, you have to provide --force 
parameter to the cli tool.




Any potential issues with upgrade? If the client was installed with
authconfig but the sysadmin later installs authselect, would
backup/restore be disturbed? (I really have no idea but your design
should show that you asked yourself the question and evaluated the risks).

I would also suggest adding a pointer to authselect document
https://fedoraproject.org/wiki/Changes/Authselect as this page explains
the rationale for migrating to authselect and the main differences. When
I read your design I didn't really understand that authselect would
provide only a limited set of profiles, hence ruling out the combination
authselect / --no-sssd. As this can be a hot topic (see the mail
thread...) I believe it's important to express this issue in the design
doc.

Flo
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-19 Thread Pavel Březina via FreeIPA-devel


On 02/15/2018 05:15 PM, Jakub Hrozek via FreeIPA-devel wrote:

On Thu, Feb 15, 2018 at 11:10:16AM -0500, Rob Crittenden via FreeIPA-devel 
wrote:

Petr Vobornik via FreeIPA-devel wrote:

On Thu, Feb 15, 2018 at 4:47 PM, Jakub Hrozek via FreeIPA-devel
 wrote:

On Thu, Feb 15, 2018 at 08:57:55AM -0500, Rob Crittenden via FreeIPA-devel 
wrote:

Alexander Koksharov via FreeIPA-devel wrote:

Hello,

Please take a look on a design page here:
https://www.freeipa.org/page/V4/Authselect_migration
I would like to

hear you critics and suggessions.



On a non-technical note there are a number of spelling and grammatical
errors.

You assert that non-SSSD is deprecated. Is that true? And is that
because authselect is choosing not to support it?


Yes.


I'm ok with it and it
simplifies options a lot but I don't recall a conversation about that
before now. This is particularly important for in-place upgrades.


What kind of a setup has non-SSSD clients? SSSD has been the default
since RHEL-6 and I even thought the IPA installer dropped support for
non-SSSD clients, but I haven't really checked.


--no-sssd option in  ipa-client-install was marked as deprecated in
https://github.com/freeipa/freeipa/pull/848 (summer 2017). As part of
https://pagure.io/freeipa/issue/5860 - spin of
https://pagure.io/freeipa/issue/5557. Origin was that IPA client
doesn't bring dependencies for --no-sssd.

I.e. the deprecation is quite new.

Installation without SSSD is AFAIK not tested upstream.



Bleh. Documenting ONLY in the command-line? Not even the man page?

The RHEL docs don't mention --no-sssd at all apparently so there's that.

There seems to be no consideration of someone who installed with
--no-sssd in a supported version and has since upgraded.

I'm not advocating for --no-sssd but there was a real use-case when it
was introduced. It is likely not the case now but there may still be
corner cases.


Pavel, can you remind me what the upgrade plan was for authselect? Was
it simply 'don't touch the system' ?


Upgraded systems will not be touched.

I need to bring up a discussion about how to package this change 
properly, but now there is authselect-compat (obsoletes authconfig) 
which provides /sbin/authconfig. If it is run after upgrade, authselect 
will be used. But otherwise the configuration will not be touched.




Does IPA call auth{select,config} during upgrades at all?
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design


On 02/14/2018 09:15 AM, Alexander Koksharov via FreeIPA-devel wrote:

Hello,

Please take a look on a design page here: 
https://www.freeipa.org/page/V4/Authselect_migration

I would like to
 
hear you critics and suggessions.

Thank you

--
Alexander


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org


Hi Lex,

Thank you for the document, it is a good thing to discuss features based 
on written material :)


The design only mentions ipa-client-install, but we also rely on 
authconfig in various ipa-advise scripts (ipa-advise command creates a 
script that can be run by the sysadmin, for instance to configure smart 
card authentication with ipa-advise config-client-for-smart-card-auth, 
and the script calls authconfig).


freeipa.spec.in defines a dependency on authconfig, will it be turned 
into a weak dependency? Will we add a dependency on authselect instead?


Backup and restore refer to the directory /var/lib/authconfig/last/ and 
the file /etc/sysconfig/authconfig, does it need to be adapted for 
authselect or does the tool use the same dir and files?


Any potential issues with upgrade? If the client was installed with 
authconfig but the sysadmin later installs authselect, would 
backup/restore be disturbed? (I really have no idea but your design 
should show that you asked yourself the question and evaluated the risks).


I would also suggest adding a pointer to authselect document 
https://fedoraproject.org/wiki/Changes/Authselect as this page explains 
the rationale for migrating to authselect and the main differences. When 
I read your design I didn't really understand that authselect would 
provide only a limited set of profiles, hence ruling out the combination 
authselect / --no-sssd. As this can be a hot topic (see the mail 
thread...) I believe it's important to express this issue in the design doc.


Flo
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-16 Thread Petr Vobornik via FreeIPA-devel

On Fri, Feb 16, 2018 at 12:27 PM, Alexander Bokovoy  wrote:
> On pe, 16 helmi 2018, Petr Vobornik wrote:
>>
>> On Fri, Feb 16, 2018 at 11:25 AM, Alexander Bokovoy via FreeIPA-devel
>>  wrote:
>>>
>>> On pe, 16 helmi 2018, Alexander Koksharov via FreeIPA-devel wrote:


 Would it be good to implement the change like this:

 if authconfig is available then
   use current flow
 else
  if authselect is available and not no-sssd then
 use authselect to activate sssd profile
  else
raise Error
  done
 done
>>>
>>>
>>> Sounds good to me.
>>>
>>> Petr, Jakub?
>>
>>
>> For default use case (with sssd), when both authselect and authconfig
>> are available it will use authconfing. Do we want that? Isn't the
>> purpose of authselect to provide better tested config.
>>
>> If I understood ab yesterday correctly it was more about changing
>> current algorithm not changing the algorithm to not disturb the flow.
>>
>> Current algo is:
>>
>> authconfig --nisdomain=
>> if (sssd) then
>>   authconfig --enablesssd
>>   authconfig --enablesssdauth
>> else
>>   authconfig --enableldap
>>   authconfig --enableforcelegacy
>>   authconfig --enablekrb5
>>   authconfig --nostart
>> done
>> if (mkhomedir) then
>>   authconfing --mkhomedir
>> done
>>
>> so the change is more like:
>>
>> set nisdomain in platform default way (directly or using authconfig)
>> if (sssd) then
>>   do platform default (authselect or authconfig)
>> else:
>>   raise if not authconfig
>>   authconfig --enableldap
>>   authconfig --enableforcelegacy
>>   authconfig --enablekrb5
>>   authconfig --nostart.
>> done
>> if (mkhomedir) then
>>platform default (authconfing | authselect)
>> done
>>
>> I.e. prefer authselect in individual steps, then try authconfig.
>
> Right, it is anyway a task for the platform implementation what to
> prefer.
>
> I want to note, though, we do not run these "separate" authconfig calls.
> Instead, we gather them into a single call. So the logic flow above is
> not reflecting the actual call flow.
>

Right.


-- 
Petr Vobornik
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-16 Thread Alexander Bokovoy via FreeIPA-devel


On pe, 16 helmi 2018, Petr Vobornik wrote:

On Fri, Feb 16, 2018 at 11:25 AM, Alexander Bokovoy via FreeIPA-devel
 wrote:

On pe, 16 helmi 2018, Alexander Koksharov via FreeIPA-devel wrote:


Would it be good to implement the change like this:

if authconfig is available then
  use current flow
else
 if authselect is available and not no-sssd then
use authselect to activate sssd profile
 else
   raise Error
 done
done


Sounds good to me.

Petr, Jakub?


For default use case (with sssd), when both authselect and authconfig
are available it will use authconfing. Do we want that? Isn't the
purpose of authselect to provide better tested config.

If I understood ab yesterday correctly it was more about changing
current algorithm not changing the algorithm to not disturb the flow.

Current algo is:

authconfig --nisdomain=
if (sssd) then
  authconfig --enablesssd
  authconfig --enablesssdauth
else
  authconfig --enableldap
  authconfig --enableforcelegacy
  authconfig --enablekrb5
  authconfig --nostart
done
if (mkhomedir) then
  authconfing --mkhomedir
done

so the change is more like:

set nisdomain in platform default way (directly or using authconfig)
if (sssd) then
  do platform default (authselect or authconfig)
else:
  raise if not authconfig
  authconfig --enableldap
  authconfig --enableforcelegacy
  authconfig --enablekrb5
  authconfig --nostart.
done
if (mkhomedir) then
   platform default (authconfing | authselect)
done

I.e. prefer authselect in individual steps, then try authconfig.

Right, it is anyway a task for the platform implementation what to
prefer.

I want to note, though, we do not run these "separate" authconfig calls.
Instead, we gather them into a single call. So the logic flow above is
not reflecting the actual call flow.

--
/ Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-16 Thread Petr Vobornik via FreeIPA-devel

On Fri, Feb 16, 2018 at 11:25 AM, Alexander Bokovoy via FreeIPA-devel
 wrote:
> On pe, 16 helmi 2018, Alexander Koksharov via FreeIPA-devel wrote:
>>
>> Would it be good to implement the change like this:
>>
>> if authconfig is available then
>>   use current flow
>> else
>>  if authselect is available and not no-sssd then
>> use authselect to activate sssd profile
>>  else
>>raise Error
>>  done
>> done
>
> Sounds good to me.
>
> Petr, Jakub?

For default use case (with sssd), when both authselect and authconfig
are available it will use authconfing. Do we want that? Isn't the
purpose of authselect to provide better tested config.

If I understood ab yesterday correctly it was more about changing
current algorithm not changing the algorithm to not disturb the flow.

Current algo is:

authconfig --nisdomain=
if (sssd) then
   authconfig --enablesssd
   authconfig --enablesssdauth
else
   authconfig --enableldap
   authconfig --enableforcelegacy
   authconfig --enablekrb5
   authconfig --nostart
done
if (mkhomedir) then
   authconfing --mkhomedir
done

so the change is more like:

set nisdomain in platform default way (directly or using authconfig)
if (sssd) then
   do platform default (authselect or authconfig)
else:
   raise if not authconfig
   authconfig --enableldap
   authconfig --enableforcelegacy
   authconfig --enablekrb5
   authconfig --nostart.
done
if (mkhomedir) then
platform default (authconfing | authselect)
done

I.e. prefer authselect in individual steps, then try authconfig.



>
>
>>
>>
>>
>> Alexander
>>
>> On Thu, Feb 15, 2018 at 8:49 PM, Petr Vobornik via FreeIPA-devel <
>> freeipa-devel@lists.fedorahosted.org> wrote:
>>
>>> On Thu, Feb 15, 2018 at 6:22 PM, Alexander Bokovoy 
>>> wrote:
>>> > On Thu, 15 Feb 2018, Petr Vobornik wrote:
>>> >>
>>> >> On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy
>>> >> >> >
>>> >> wrote:
>>> >>>
>>> >>> On Thu, 15 Feb 2018, Petr Vobornik wrote:
>>> 
>>> 
>>>  On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
>>>   wrote:
>>> >
>>> >
>>> > On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:
>>> >>
>>> >>
>>> >> On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
>>> >> > On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via
>>> >> > FreeIPA-devel wrote:
>>> >> > > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
>>> >> > > > Hello,
>>> >> > > >
>>> >> > > > I would like to confirm whether we do want to completelly
>>> >> > > > drop
>>> >> > > > --no-sssd
>>> >> > > > option.
>>> >> > > > "no-sssd" configuration is not supported by authselect -
>>> >> > > > there
>>> >> > > > is
>>> >> > > > not such
>>> >> > > > profile available.
>>> >> > > > If we drop dependency on authconfig there will be a need to
>>> >> > > > do
>>> >> > > > code cleanup
>>> >> > > > and also to rewrite related parts. And if we agreed on
>>> rewriting
>>> >> > > > some parts
>>> >> > > > there wont be any problems replacing multiple calls to
>>> >> > > > authconfig
>>> >> > > > with a
>>> >> > > > single one to outhselect.
>>> >> > > I think we should make sure authselect does support non-sssd
>>> >> > > profile.
>>> >> >
>>> >> > authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5
>>> >> > etc
>>> >> > are
>>> >> > considered legacy and not supported. Nothing prevents you from
>>> >> > creating
>>> >> > your own authselect profile for these, though, but authselect
>>> >> > upstream
>>> >> > doesn't provide these.
>>> >> >
>>> >> > What kind of non-sssd profile? What is the use-case for this?
>>> >> We are mapping existing authconfig support to newer authselect
>>> >> support.
>>> >> I think the question is not really what authselect is or isn't but
>>> >> rather what non-sssd authconfig configuration IPA used and
>>> >> continues
>>> >> to
>>> >> support.
>>> 
>>> 
>>> 
>>> >> We definitely have to support ipa-client-install --no-sssd
>>> >> variant because it is valid for any platform (including Fedora)
>>> 
>>> 
>>> 
>>>  Why? Having some legacy packages doesn't mean that IPA needs to
>>>  support it forever. I Don't see any reasons for cases where FreeIPA
>>>  is
>>>  not present and nobody is doing or planning any effort to port it
>>>  there. And if something was planned then it makes sense to port SSSD
>>>  first.
>>> >>>
>>> >>>
>>> >>> Sure. It does not mean we have to break what exist already too just
>>> >>> for
>>> >>> the sake of breaking.
>>> >>>
>>> >> and
>>> >> removing it would make ipa-client-install non-working on something
>>> >> like
>>> >> FreeBSD or ArchLinux.
>>> 
>>> 
>>> 
>>>

[Freeipa-devel] Re: authconfig replacement design

2018-02-16 Thread Alexander Bokovoy via FreeIPA-devel


On pe, 16 helmi 2018, Alexander Koksharov via FreeIPA-devel wrote:

Would it be good to implement the change like this:

if authconfig is available then
  use current flow
else
 if authselect is available and not no-sssd then
use authselect to activate sssd profile
 else
   raise Error
 done
done

Sounds good to me.

Petr, Jakub?





Alexander

On Thu, Feb 15, 2018 at 8:49 PM, Petr Vobornik via FreeIPA-devel <
freeipa-devel@lists.fedorahosted.org> wrote:


On Thu, Feb 15, 2018 at 6:22 PM, Alexander Bokovoy 
wrote:
> On Thu, 15 Feb 2018, Petr Vobornik wrote:
>>
>> On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy 
>> wrote:
>>>
>>> On Thu, 15 Feb 2018, Petr Vobornik wrote:


 On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
  wrote:
>
>
> On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:
>>
>>
>> On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
>> > On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via
>> > FreeIPA-devel wrote:
>> > > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
>> > > > Hello,
>> > > >
>> > > > I would like to confirm whether we do want to completelly drop
>> > > > --no-sssd
>> > > > option.
>> > > > "no-sssd" configuration is not supported by authselect - there
>> > > > is
>> > > > not such
>> > > > profile available.
>> > > > If we drop dependency on authconfig there will be a need to do
>> > > > code cleanup
>> > > > and also to rewrite related parts. And if we agreed on
rewriting
>> > > > some parts
>> > > > there wont be any problems replacing multiple calls to
>> > > > authconfig
>> > > > with a
>> > > > single one to outhselect.
>> > > I think we should make sure authselect does support non-sssd
>> > > profile.
>> >
>> > authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc
>> > are
>> > considered legacy and not supported. Nothing prevents you from
>> > creating
>> > your own authselect profile for these, though, but authselect
>> > upstream
>> > doesn't provide these.
>> >
>> > What kind of non-sssd profile? What is the use-case for this?
>> We are mapping existing authconfig support to newer authselect
>> support.
>> I think the question is not really what authselect is or isn't but
>> rather what non-sssd authconfig configuration IPA used and continues
>> to
>> support.



>> We definitely have to support ipa-client-install --no-sssd
>> variant because it is valid for any platform (including Fedora)



 Why? Having some legacy packages doesn't mean that IPA needs to
 support it forever. I Don't see any reasons for cases where FreeIPA is
 not present and nobody is doing or planning any effort to port it
 there. And if something was planned then it makes sense to port SSSD
 first.
>>>
>>>
>>> Sure. It does not mean we have to break what exist already too just for
>>> the sake of breaking.
>>>
>> and
>> removing it would make ipa-client-install non-working on something
>> like
>> FreeBSD or ArchLinux.



 We don't have ipa-client packages on these platforms at all. On the
 other hand, some version of SSSD is packaged for both. Question is
 whether itehy work though.
>>>
>>>
>>> We do have freeipa-client in ArchLinux. Their support is not upstreamed
>>> but I don't see why it couldn't. It is a fairly small piece on top of
>>> existing ipaplatform/redhat, so it could and should be upstream.
>>
>>
>> I remember that Jan Cholasta tried to package it and probably
>> succeeded only with client. But now I don't see it:
>>  https://www.archlinux.org/packages/?sort==freeipa;
maintainer==
>>
>> On the other hand there is an official wiki with manual config which
>> suggests to use SSSD:
>>   https://wiki.archlinux.org/index.php/FreeIPA
>>
> I think you misunderstood me here.

yes I did.

> ArchLinux patch I pointed to is using
> authconfig interface we developed. It uses SSSD configuration but it
> does so via authconfig indirectly by inheriting from the redhat platform
> code.
>
> As result, removing authconfig support from IPA upstream will render
> this code non-working for no obvious reason. This is what I want to
> avoid here.

I was not discussing the RedHatAuthConfig class. If Arch uses it then
it can be kept in platform code. Maybe better in base platform and not
redhat and Arch could be adjusted, but that is a different topic.

>
> I think we should be able to support any platform with or without sssd

I agree.

> as recent review of ipaplatform/debian/tasks.py shows (it simply does
> NOTHING when called, thus happily pretending that any configuration
> succeeded).

Also OK.

> However, removing --no-sssd option because of authselect
> switch is

[Freeipa-devel] Re: authconfig replacement design

2018-02-16 Thread Alexander Koksharov via FreeIPA-devel

Would it be good to implement the change like this:

if authconfig is available then
   use current flow
else
  if authselect is available and not no-sssd then
 use authselect to activate sssd profile
  else
raise Error
  done
done



Alexander

On Thu, Feb 15, 2018 at 8:49 PM, Petr Vobornik via FreeIPA-devel <
freeipa-devel@lists.fedorahosted.org> wrote:

> On Thu, Feb 15, 2018 at 6:22 PM, Alexander Bokovoy 
> wrote:
> > On Thu, 15 Feb 2018, Petr Vobornik wrote:
> >>
> >> On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy  >
> >> wrote:
> >>>
> >>> On Thu, 15 Feb 2018, Petr Vobornik wrote:
> 
> 
>  On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
>   wrote:
> >
> >
> > On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:
> >>
> >>
> >> On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
> >> > On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via
> >> > FreeIPA-devel wrote:
> >> > > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
> >> > > > Hello,
> >> > > >
> >> > > > I would like to confirm whether we do want to completelly drop
> >> > > > --no-sssd
> >> > > > option.
> >> > > > "no-sssd" configuration is not supported by authselect - there
> >> > > > is
> >> > > > not such
> >> > > > profile available.
> >> > > > If we drop dependency on authconfig there will be a need to do
> >> > > > code cleanup
> >> > > > and also to rewrite related parts. And if we agreed on
> rewriting
> >> > > > some parts
> >> > > > there wont be any problems replacing multiple calls to
> >> > > > authconfig
> >> > > > with a
> >> > > > single one to outhselect.
> >> > > I think we should make sure authselect does support non-sssd
> >> > > profile.
> >> >
> >> > authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc
> >> > are
> >> > considered legacy and not supported. Nothing prevents you from
> >> > creating
> >> > your own authselect profile for these, though, but authselect
> >> > upstream
> >> > doesn't provide these.
> >> >
> >> > What kind of non-sssd profile? What is the use-case for this?
> >> We are mapping existing authconfig support to newer authselect
> >> support.
> >> I think the question is not really what authselect is or isn't but
> >> rather what non-sssd authconfig configuration IPA used and continues
> >> to
> >> support.
> 
> 
> 
> >> We definitely have to support ipa-client-install --no-sssd
> >> variant because it is valid for any platform (including Fedora)
> 
> 
> 
>  Why? Having some legacy packages doesn't mean that IPA needs to
>  support it forever. I Don't see any reasons for cases where FreeIPA is
>  not present and nobody is doing or planning any effort to port it
>  there. And if something was planned then it makes sense to port SSSD
>  first.
> >>>
> >>>
> >>> Sure. It does not mean we have to break what exist already too just for
> >>> the sake of breaking.
> >>>
> >> and
> >> removing it would make ipa-client-install non-working on something
> >> like
> >> FreeBSD or ArchLinux.
> 
> 
> 
>  We don't have ipa-client packages on these platforms at all. On the
>  other hand, some version of SSSD is packaged for both. Question is
>  whether itehy work though.
> >>>
> >>>
> >>> We do have freeipa-client in ArchLinux. Their support is not upstreamed
> >>> but I don't see why it couldn't. It is a fairly small piece on top of
> >>> existing ipaplatform/redhat, so it could and should be upstream.
> >>
> >>
> >> I remember that Jan Cholasta tried to package it and probably
> >> succeeded only with client. But now I don't see it:
> >>  https://www.archlinux.org/packages/?sort==freeipa;
> maintainer==
> >>
> >> On the other hand there is an official wiki with manual config which
> >> suggests to use SSSD:
> >>   https://wiki.archlinux.org/index.php/FreeIPA
> >>
> > I think you misunderstood me here.
>
> yes I did.
>
> > ArchLinux patch I pointed to is using
> > authconfig interface we developed. It uses SSSD configuration but it
> > does so via authconfig indirectly by inheriting from the redhat platform
> > code.
> >
> > As result, removing authconfig support from IPA upstream will render
> > this code non-working for no obvious reason. This is what I want to
> > avoid here.
>
> I was not discussing the RedHatAuthConfig class. If Arch uses it then
> it can be kept in platform code. Maybe better in base platform and not
> redhat and Arch could be adjusted, but that is a different topic.
>
> >
> > I think we should be able to support any platform with or without sssd
>
> I agree.
>
> > as recent review of ipaplatform/debian/tasks.py shows (it simply does
> > NOTHING when called,

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 6:22 PM, Alexander Bokovoy  wrote:
> On Thu, 15 Feb 2018, Petr Vobornik wrote:
>>
>> On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy 
>> wrote:
>>>
>>> On Thu, 15 Feb 2018, Petr Vobornik wrote:


 On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
  wrote:
>
>
> On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:
>>
>>
>> On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
>> > On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via
>> > FreeIPA-devel wrote:
>> > > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
>> > > > Hello,
>> > > >
>> > > > I would like to confirm whether we do want to completelly drop
>> > > > --no-sssd
>> > > > option.
>> > > > "no-sssd" configuration is not supported by authselect - there
>> > > > is
>> > > > not such
>> > > > profile available.
>> > > > If we drop dependency on authconfig there will be a need to do
>> > > > code cleanup
>> > > > and also to rewrite related parts. And if we agreed on rewriting
>> > > > some parts
>> > > > there wont be any problems replacing multiple calls to
>> > > > authconfig
>> > > > with a
>> > > > single one to outhselect.
>> > > I think we should make sure authselect does support non-sssd
>> > > profile.
>> >
>> > authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc
>> > are
>> > considered legacy and not supported. Nothing prevents you from
>> > creating
>> > your own authselect profile for these, though, but authselect
>> > upstream
>> > doesn't provide these.
>> >
>> > What kind of non-sssd profile? What is the use-case for this?
>> We are mapping existing authconfig support to newer authselect
>> support.
>> I think the question is not really what authselect is or isn't but
>> rather what non-sssd authconfig configuration IPA used and continues
>> to
>> support.



>> We definitely have to support ipa-client-install --no-sssd
>> variant because it is valid for any platform (including Fedora)



 Why? Having some legacy packages doesn't mean that IPA needs to
 support it forever. I Don't see any reasons for cases where FreeIPA is
 not present and nobody is doing or planning any effort to port it
 there. And if something was planned then it makes sense to port SSSD
 first.
>>>
>>>
>>> Sure. It does not mean we have to break what exist already too just for
>>> the sake of breaking.
>>>
>> and
>> removing it would make ipa-client-install non-working on something
>> like
>> FreeBSD or ArchLinux.



 We don't have ipa-client packages on these platforms at all. On the
 other hand, some version of SSSD is packaged for both. Question is
 whether itehy work though.
>>>
>>>
>>> We do have freeipa-client in ArchLinux. Their support is not upstreamed
>>> but I don't see why it couldn't. It is a fairly small piece on top of
>>> existing ipaplatform/redhat, so it could and should be upstream.
>>
>>
>> I remember that Jan Cholasta tried to package it and probably
>> succeeded only with client. But now I don't see it:
>>  https://www.archlinux.org/packages/?sort==freeipa==
>>
>> On the other hand there is an official wiki with manual config which
>> suggests to use SSSD:
>>   https://wiki.archlinux.org/index.php/FreeIPA
>>
> I think you misunderstood me here.

yes I did.

> ArchLinux patch I pointed to is using
> authconfig interface we developed. It uses SSSD configuration but it
> does so via authconfig indirectly by inheriting from the redhat platform
> code.
>
> As result, removing authconfig support from IPA upstream will render
> this code non-working for no obvious reason. This is what I want to
> avoid here.

I was not discussing the RedHatAuthConfig class. If Arch uses it then
it can be kept in platform code. Maybe better in base platform and not
redhat and Arch could be adjusted, but that is a different topic.

>
> I think we should be able to support any platform with or without sssd

I agree.

> as recent review of ipaplatform/debian/tasks.py shows (it simply does
> NOTHING when called, thus happily pretending that any configuration
> succeeded).

Also OK.

> However, removing --no-sssd option because of authselect
> switch is wrong.

I guess if on Fedora and RHEL:
- freeipa won't no longer depend on authconfig
- new check (similar to pam_krb5 check) to bail out if authconfig is
not present will be added

Then we can avoid removal of the option as a part of this change.

Though, I'd argue that removal of the option sooner the better is
welcome. Mostly time to do it will be our enemy.

But I would still consider ignoring this option on Fedora and RHEL for
ipa-client-install (not ipa-client-automount)

[Freeipa-devel] Re: authconfig replacement design

2018-02-15 Thread Alexander Bokovoy via FreeIPA-devel

On Thu, 15 Feb 2018, Petr Vobornik wrote:

On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy  wrote:

On Thu, 15 Feb 2018, Petr Vobornik wrote:

On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
 wrote:

On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:

On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
> On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via
> FreeIPA-devel wrote:
> > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
> > > Hello,
> > >
> > > I would like to confirm whether we do want to completelly drop
> > > --no-sssd
> > > option.
> > > "no-sssd" configuration is not supported by authselect - there is
> > > not such
> > > profile available.
> > > If we drop dependency on authconfig there will be a need to do
> > > code cleanup
> > > and also to rewrite related parts. And if we agreed on rewriting
> > > some parts
> > > there wont be any problems replacing multiple calls to authconfig
> > > with a
> > > single one to outhselect.
> > I think we should make sure authselect does support non-sssd
> > profile.
>
> authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
> considered legacy and not supported. Nothing prevents you from
> creating
> your own authselect profile for these, though, but authselect upstream
> doesn't provide these.
>
> What kind of non-sssd profile? What is the use-case for this?
We are mapping existing authconfig support to newer authselect support.
I think the question is not really what authselect is or isn't but
rather what non-sssd authconfig configuration IPA used and continues to
support.

We definitely have to support ipa-client-install --no-sssd
variant because it is valid for any platform (including Fedora)

Why? Having some legacy packages doesn't mean that IPA needs to
support it forever. I Don't see any reasons for cases where FreeIPA is
not present and nobody is doing or planning any effort to port it
there. And if something was planned then it makes sense to port SSSD
first.

Sure. It does not mean we have to break what exist already too just for
the sake of breaking.

and
removing it would make ipa-client-install non-working on something like
FreeBSD or ArchLinux.

We don't have ipa-client packages on these platforms at all. On the
other hand, some version of SSSD is packaged for both. Question is
whether itehy work though.

We do have freeipa-client in ArchLinux. Their support is not upstreamed
but I don't see why it couldn't. It is a fairly small piece on top of
existing ipaplatform/redhat, so it could and should be upstream.

I remember that Jan Cholasta tried to package it and probably
succeeded only with client. But now I don't see it:
 https://www.archlinux.org/packages/?sort==freeipa==

On the other hand there is an official wiki with manual config which
suggests to use SSSD:
  https://wiki.archlinux.org/index.php/FreeIPA

I think you misunderstood me here. ArchLinux patch I pointed to is using
authconfig interface we developed. It uses SSSD configuration but it
does so via authconfig indirectly by inheriting from the redhat platform
code.

As result, removing authconfig support from IPA upstream will render
this code non-working for no obvious reason. This is what I want to
avoid here.

I think we should be able to support any platform with or without sssd
as recent review of ipaplatform/debian/tasks.py shows (it simply does
NOTHING when called, thus happily pretending that any configuration
succeeded). However, removing --no-sssd option because of authselect
switch is wrong. Just make sure authselect is chosen by default by a new
fedora/rhel platform tasks and don't support it there but don't kill the
whole flow.
--
/ Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy  wrote:
> On Thu, 15 Feb 2018, Petr Vobornik wrote:
>>
>> On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
>>  wrote:
>>>
>>> On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:

 On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
 > On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via
 > FreeIPA-devel wrote:
 > > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
 > > > Hello,
 > > >
 > > > I would like to confirm whether we do want to completelly drop
 > > > --no-sssd
 > > > option.
 > > > "no-sssd" configuration is not supported by authselect - there is
 > > > not such
 > > > profile available.
 > > > If we drop dependency on authconfig there will be a need to do
 > > > code cleanup
 > > > and also to rewrite related parts. And if we agreed on rewriting
 > > > some parts
 > > > there wont be any problems replacing multiple calls to authconfig
 > > > with a
 > > > single one to outhselect.
 > > I think we should make sure authselect does support non-sssd
 > > profile.
 >
 > authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
 > considered legacy and not supported. Nothing prevents you from
 > creating
 > your own authselect profile for these, though, but authselect upstream
 > doesn't provide these.
 >
 > What kind of non-sssd profile? What is the use-case for this?
 We are mapping existing authconfig support to newer authselect support.
 I think the question is not really what authselect is or isn't but
 rather what non-sssd authconfig configuration IPA used and continues to
 support.
>>
>>
 We definitely have to support ipa-client-install --no-sssd
 variant because it is valid for any platform (including Fedora)
>>
>>
>> Why? Having some legacy packages doesn't mean that IPA needs to
>> support it forever. I Don't see any reasons for cases where FreeIPA is
>> not present and nobody is doing or planning any effort to port it
>> there. And if something was planned then it makes sense to port SSSD
>> first.
>
> Sure. It does not mean we have to break what exist already too just for
> the sake of breaking.
>
 and
 removing it would make ipa-client-install non-working on something like
 FreeBSD or ArchLinux.
>>
>>
>> We don't have ipa-client packages on these platforms at all. On the
>> other hand, some version of SSSD is packaged for both. Question is
>> whether itehy work though.
>
> We do have freeipa-client in ArchLinux. Their support is not upstreamed
> but I don't see why it couldn't. It is a fairly small piece on top of
> existing ipaplatform/redhat, so it could and should be upstream.

I remember that Jan Cholasta tried to package it and probably
succeeded only with client. But now I don't see it:
  https://www.archlinux.org/packages/?sort==freeipa==

On the other hand there is an official wiki with manual config which
suggests to use SSSD:
   https://wiki.archlinux.org/index.php/FreeIPA

>
>> So did it mean would make it harder to port it there?
>
> Yes, it will. See my other response to Jakub for details.
>

-- 
Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-15 Thread Alexander Bokovoy via FreeIPA-devel

On Thu, 15 Feb 2018, Petr Vobornik wrote:

On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
 wrote:

On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:

On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
> On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via FreeIPA-devel 
wrote:
> > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
> > > Hello,
> > >
> > > I would like to confirm whether we do want to completelly drop --no-sssd
> > > option.
> > > "no-sssd" configuration is not supported by authselect - there is not such
> > > profile available.
> > > If we drop dependency on authconfig there will be a need to do code 
cleanup
> > > and also to rewrite related parts. And if we agreed on rewriting some 
parts
> > > there wont be any problems replacing multiple calls to authconfig with a
> > > single one to outhselect.
> > I think we should make sure authselect does support non-sssd profile.
>
> authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
> considered legacy and not supported. Nothing prevents you from creating
> your own authselect profile for these, though, but authselect upstream
> doesn't provide these.
>
> What kind of non-sssd profile? What is the use-case for this?
We are mapping existing authconfig support to newer authselect support.
I think the question is not really what authselect is or isn't but
rather what non-sssd authconfig configuration IPA used and continues to
support.

We definitely have to support ipa-client-install --no-sssd
variant because it is valid for any platform (including Fedora)

Why? Having some legacy packages doesn't mean that IPA needs to
support it forever. I Don't see any reasons for cases where FreeIPA is
not present and nobody is doing or planning any effort to port it
there. And if something was planned then it makes sense to port SSSD
first.

Sure. It does not mean we have to break what exist already too just for
the sake of breaking.

and
removing it would make ipa-client-install non-working on something like
FreeBSD or ArchLinux.

We don't have ipa-client packages on these platforms at all. On the
other hand, some version of SSSD is packaged for both. Question is
whether itehy work though.

We do have freeipa-client in ArchLinux. Their support is not upstreamed
but I don't see why it couldn't. It is a fairly small piece on top of
existing ipaplatform/redhat, so it could and should be upstream.

So did it mean would make it harder to port it there?

Yes, it will. See my other response to Jakub for details.

--
/ Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
 wrote:
> On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:
>> On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
>> > On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via 
>> > FreeIPA-devel wrote:
>> > > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
>> > > > Hello,
>> > > >
>> > > > I would like to confirm whether we do want to completelly drop 
>> > > > --no-sssd
>> > > > option.
>> > > > "no-sssd" configuration is not supported by authselect - there is not 
>> > > > such
>> > > > profile available.
>> > > > If we drop dependency on authconfig there will be a need to do code 
>> > > > cleanup
>> > > > and also to rewrite related parts. And if we agreed on rewriting some 
>> > > > parts
>> > > > there wont be any problems replacing multiple calls to authconfig with 
>> > > > a
>> > > > single one to outhselect.
>> > > I think we should make sure authselect does support non-sssd profile.
>> >
>> > authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
>> > considered legacy and not supported. Nothing prevents you from creating
>> > your own authselect profile for these, though, but authselect upstream
>> > doesn't provide these.
>> >
>> > What kind of non-sssd profile? What is the use-case for this?
>> We are mapping existing authconfig support to newer authselect support.
>> I think the question is not really what authselect is or isn't but
>> rather what non-sssd authconfig configuration IPA used and continues to
>> support.

>> We definitely have to support ipa-client-install --no-sssd
>> variant because it is valid for any platform (including Fedora)

Why? Having some legacy packages doesn't mean that IPA needs to
support it forever. I Don't see any reasons for cases where FreeIPA is
not present and nobody is doing or planning any effort to port it
there. And if something was planned then it makes sense to port SSSD
first.

Note: pam_krb5 is deprecated on RHEL:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.4_release_notes/chap-red_hat_enterprise_linux-7.4_release_notes-deprecated_functionalit

>
> I disagree it's valid for Fedora. I would contest that using --no-sssd
> doesn't really buy you anything and just needlessly doubles the test
> matrix.
>
> Speaking of test matrix, are there any tests for --no-sssd?

No

>
>> and
>> removing it would make ipa-client-install non-working on something like
>> FreeBSD or ArchLinux.

We don't have ipa-client packages on these platforms at all. On the
other hand, some version of SSSD is packaged for both. Question is
whether itehy work though.

So did it mean would make it harder to port it there?

>
> Right, but these platforms use authconfig at the moment? If yes, then
> presumably there is a mechanism to detect if authconfig is present on
> the platform, right?
>
>>
>> Right now the client installer logic when --no-sssd option is passed is
>> following:
>>  - check whether either nss_ldap or nss-pam-ldapd exist, configure them
>>  - otherwise fail with a client installer error
>>
>> Thus, either with authselect we are limiting ourselves to only sssd
>> configuration or not, we have to keep supporting nss_ldap/nss-pam-ldapd
>> variants through some other platform options. Perhaps, this means we
>> would need to make a generic ipaplatform backend that utilizes a recipe
>> from ipa-advise that gives us nss_ldap/nss-pam-ldapd support? Then we
>> can fall back to that backend in case authselect is not supporting
>> non-sssd path.
>
> This sounds reasonable to me.
>
> IPA can also ship its own authselect profile in Fedora, but again..why?
>
>>
>> > > Otherwise it is not a real replacement for authconfig in Fedora.
>> >
>> > Again, what reason is there to use anything else than SSSD or winbind?
>> See above. It is about compatibility to other platforms and older IPA
>> behavior.

I'm not sure to what degree we should care about client update.
Usually, nothing changes on client update as all functionality is in
intial configuration. We don't have ipa-client-updater. Only few
snippets were in rpm scriplets.


-- 
Petr Vobornik
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-15 Thread Alexander Bokovoy via FreeIPA-devel

On Thu, 15 Feb 2018, Jakub Hrozek wrote:

On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:

On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
> On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via FreeIPA-devel 
wrote:
> > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
> > > Hello,
> > >
> > > I would like to confirm whether we do want to completelly drop --no-sssd
> > > option.
> > > "no-sssd" configuration is not supported by authselect - there is not such
> > > profile available.
> > > If we drop dependency on authconfig there will be a need to do code 
cleanup
> > > and also to rewrite related parts. And if we agreed on rewriting some 
parts
> > > there wont be any problems replacing multiple calls to authconfig with a
> > > single one to outhselect.
> > I think we should make sure authselect does support non-sssd profile.
>
> authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
> considered legacy and not supported. Nothing prevents you from creating
> your own authselect profile for these, though, but authselect upstream
> doesn't provide these.
>
> What kind of non-sssd profile? What is the use-case for this?
We are mapping existing authconfig support to newer authselect support.
I think the question is not really what authselect is or isn't but
rather what non-sssd authconfig configuration IPA used and continues to
support. We definitely have to support ipa-client-install --no-sssd
variant because it is valid for any platform (including Fedora)

I disagree it's valid for Fedora. I would contest that using --no-sssd
doesn't really buy you anything and just needlessly doubles the test
matrix.

Speaking of test matrix, are there any tests for --no-sssd?

No tests for that. The way how installer is done, it boils down to a
specific platform's (ipaplatform/*/tasks.py) implementation of a
configuration task related to pam/nsswitch configuration.

and
removing it would make ipa-client-install non-working on something like
FreeBSD or ArchLinux.

Right, but these platforms use authconfig at the moment? If yes, then
presumably there is a mechanism to detect if authconfig is present on
the platform, right?

ArchLinux supports authconfig, as well as others. They all depend
on the functionality provided by ipaplatform, not always upstreamed:
https://aur.archlinux.org/cgit/aur.git/tree/0002-platform-add-Arch-Linux-platform.patch?h=freeipa
This functionality is based on deriving from redhat platform which
provides authconfig setup.

Removing it means breaking all those platforms, so I would say that
adding authselect support should not break authconfig support. This is
not mentioned in a design spec yet.

Right now the client installer logic when --no-sssd option is passed is
following:
 - check whether either nss_ldap or nss-pam-ldapd exist, configure them
 - otherwise fail with a client installer error

Thus, either with authselect we are limiting ourselves to only sssd
configuration or not, we have to keep supporting nss_ldap/nss-pam-ldapd
variants through some other platform options. Perhaps, this means we
would need to make a generic ipaplatform backend that utilizes a recipe
from ipa-advise that gives us nss_ldap/nss-pam-ldapd support? Then we
can fall back to that backend in case authselect is not supporting
non-sssd path.

This sounds reasonable to me.

IPA can also ship its own authselect profile in Fedora, but again..why?

I don't think we need that in Fedora but we might need to do that to
support some other distros at some point.

--
/ Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 06:17:50PM +0200, Alexander Bokovoy wrote:
> On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:
> > On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via 
> > FreeIPA-devel wrote:
> > > On Thu, 15 Feb 2018, Alexander Koksharov wrote:
> > > > Hello,
> > > >
> > > > I would like to confirm whether we do want to completelly drop --no-sssd
> > > > option.
> > > > "no-sssd" configuration is not supported by authselect - there is not 
> > > > such
> > > > profile available.
> > > > If we drop dependency on authconfig there will be a need to do code 
> > > > cleanup
> > > > and also to rewrite related parts. And if we agreed on rewriting some 
> > > > parts
> > > > there wont be any problems replacing multiple calls to authconfig with a
> > > > single one to outhselect.
> > > I think we should make sure authselect does support non-sssd profile.
> > 
> > authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
> > considered legacy and not supported. Nothing prevents you from creating
> > your own authselect profile for these, though, but authselect upstream
> > doesn't provide these.
> > 
> > What kind of non-sssd profile? What is the use-case for this?
> We are mapping existing authconfig support to newer authselect support.
> I think the question is not really what authselect is or isn't but
> rather what non-sssd authconfig configuration IPA used and continues to
> support. We definitely have to support ipa-client-install --no-sssd
> variant because it is valid for any platform (including Fedora)

I disagree it's valid for Fedora. I would contest that using --no-sssd
doesn't really buy you anything and just needlessly doubles the test
matrix.

Speaking of test matrix, are there any tests for --no-sssd?

> and
> removing it would make ipa-client-install non-working on something like
> FreeBSD or ArchLinux.

Right, but these platforms use authconfig at the moment? If yes, then
presumably there is a mechanism to detect if authconfig is present on
the platform, right?

> 
> Right now the client installer logic when --no-sssd option is passed is
> following:
>  - check whether either nss_ldap or nss-pam-ldapd exist, configure them
>  - otherwise fail with a client installer error
> 
> Thus, either with authselect we are limiting ourselves to only sssd
> configuration or not, we have to keep supporting nss_ldap/nss-pam-ldapd
> variants through some other platform options. Perhaps, this means we
> would need to make a generic ipaplatform backend that utilizes a recipe
> from ipa-advise that gives us nss_ldap/nss-pam-ldapd support? Then we
> can fall back to that backend in case authselect is not supporting
> non-sssd path.

This sounds reasonable to me.

IPA can also ship its own authselect profile in Fedora, but again..why?

> 
> > > Otherwise it is not a real replacement for authconfig in Fedora.
> > 
> > Again, what reason is there to use anything else than SSSD or winbind?
> See above. It is about compatibility to other platforms and older IPA
> behavior.
> -- 
> / Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-15 Thread Alexander Bokovoy via FreeIPA-devel

On Thu, 15 Feb 2018, Jakub Hrozek via FreeIPA-devel wrote:

On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via FreeIPA-devel 
wrote:

On Thu, 15 Feb 2018, Alexander Koksharov wrote:
> Hello,
>
> I would like to confirm whether we do want to completelly drop --no-sssd
> option.
> "no-sssd" configuration is not supported by authselect - there is not such
> profile available.
> If we drop dependency on authconfig there will be a need to do code cleanup
> and also to rewrite related parts. And if we agreed on rewriting some parts
> there wont be any problems replacing multiple calls to authconfig with a
> single one to outhselect.
I think we should make sure authselect does support non-sssd profile.

authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
considered legacy and not supported. Nothing prevents you from creating
your own authselect profile for these, though, but authselect upstream
doesn't provide these.

What kind of non-sssd profile? What is the use-case for this?

We are mapping existing authconfig support to newer authselect support.
I think the question is not really what authselect is or isn't but
rather what non-sssd authconfig configuration IPA used and continues to
support. We definitely have to support ipa-client-install --no-sssd
variant because it is valid for any platform (including Fedora) and
removing it would make ipa-client-install non-working on something like
FreeBSD or ArchLinux.

Right now the client installer logic when --no-sssd option is passed is
following:
 - check whether either nss_ldap or nss-pam-ldapd exist, configure them
 - otherwise fail with a client installer error

Thus, either with authselect we are limiting ourselves to only sssd
configuration or not, we have to keep supporting nss_ldap/nss-pam-ldapd
variants through some other platform options. Perhaps, this means we
would need to make a generic ipaplatform backend that utilizes a recipe
from ipa-advise that gives us nss_ldap/nss-pam-ldapd support? Then we
can fall back to that backend in case authselect is not supporting
non-sssd path.

Otherwise it is not a real replacement for authconfig in Fedora.

Again, what reason is there to use anything else than SSSD or winbind?

See above. It is about compatibility to other platforms and older IPA
behavior.
--
/ Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 11:10:16AM -0500, Rob Crittenden via FreeIPA-devel 
wrote:
> Petr Vobornik via FreeIPA-devel wrote:
> > On Thu, Feb 15, 2018 at 4:47 PM, Jakub Hrozek via FreeIPA-devel
> >  wrote:
> >> On Thu, Feb 15, 2018 at 08:57:55AM -0500, Rob Crittenden via FreeIPA-devel 
> >> wrote:
> >>> Alexander Koksharov via FreeIPA-devel wrote:
>  Hello,
> 
>  Please take a look on a design page here:
>  https://www.freeipa.org/page/V4/Authselect_migration
>  I would like to
> 
>  hear you critics and suggessions.
> >>>
> >>>
> >>> On a non-technical note there are a number of spelling and grammatical
> >>> errors.
> >>>
> >>> You assert that non-SSSD is deprecated. Is that true? And is that
> >>> because authselect is choosing not to support it?
> >>
> >> Yes.
> >>
> >>> I'm ok with it and it
> >>> simplifies options a lot but I don't recall a conversation about that
> >>> before now. This is particularly important for in-place upgrades.
> >>
> >> What kind of a setup has non-SSSD clients? SSSD has been the default
> >> since RHEL-6 and I even thought the IPA installer dropped support for
> >> non-SSSD clients, but I haven't really checked.
> > 
> > --no-sssd option in  ipa-client-install was marked as deprecated in
> > https://github.com/freeipa/freeipa/pull/848 (summer 2017). As part of
> > https://pagure.io/freeipa/issue/5860 - spin of
> > https://pagure.io/freeipa/issue/5557. Origin was that IPA client
> > doesn't bring dependencies for --no-sssd.
> > 
> > I.e. the deprecation is quite new.
> > 
> > Installation without SSSD is AFAIK not tested upstream.
> > 
> 
> Bleh. Documenting ONLY in the command-line? Not even the man page?
> 
> The RHEL docs don't mention --no-sssd at all apparently so there's that.
> 
> There seems to be no consideration of someone who installed with
> --no-sssd in a supported version and has since upgraded.
> 
> I'm not advocating for --no-sssd but there was a real use-case when it
> was introduced. It is likely not the case now but there may still be
> corner cases.

Pavel, can you remind me what the upgrade plan was for authselect? Was
it simply 'don't touch the system' ?

Does IPA call auth{select,config} during upgrades at all?
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-15 Thread Rob Crittenden via FreeIPA-devel

Petr Vobornik via FreeIPA-devel wrote:
> On Thu, Feb 15, 2018 at 4:47 PM, Jakub Hrozek via FreeIPA-devel
>  wrote:
>> On Thu, Feb 15, 2018 at 08:57:55AM -0500, Rob Crittenden via FreeIPA-devel 
>> wrote:
>>> Alexander Koksharov via FreeIPA-devel wrote:
 Hello,

 Please take a look on a design page here:
 https://www.freeipa.org/page/V4/Authselect_migration
 I would like to

 hear you critics and suggessions.
>>>
>>>
>>> On a non-technical note there are a number of spelling and grammatical
>>> errors.
>>>
>>> You assert that non-SSSD is deprecated. Is that true? And is that
>>> because authselect is choosing not to support it?
>>
>> Yes.
>>
>>> I'm ok with it and it
>>> simplifies options a lot but I don't recall a conversation about that
>>> before now. This is particularly important for in-place upgrades.
>>
>> What kind of a setup has non-SSSD clients? SSSD has been the default
>> since RHEL-6 and I even thought the IPA installer dropped support for
>> non-SSSD clients, but I haven't really checked.
> 
> --no-sssd option in  ipa-client-install was marked as deprecated in
> https://github.com/freeipa/freeipa/pull/848 (summer 2017). As part of
> https://pagure.io/freeipa/issue/5860 - spin of
> https://pagure.io/freeipa/issue/5557. Origin was that IPA client
> doesn't bring dependencies for --no-sssd.
> 
> I.e. the deprecation is quite new.
> 
> Installation without SSSD is AFAIK not tested upstream.
> 

Bleh. Documenting ONLY in the command-line? Not even the man page?

The RHEL docs don't mention --no-sssd at all apparently so there's that.

There seems to be no consideration of someone who installed with
--no-sssd in a supported version and has since upgraded.

I'm not advocating for --no-sssd but there was a real use-case when it
was introduced. It is likely not the case now but there may still be
corner cases.

rob
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 4:47 PM, Jakub Hrozek via FreeIPA-devel
 wrote:
> On Thu, Feb 15, 2018 at 08:57:55AM -0500, Rob Crittenden via FreeIPA-devel 
> wrote:
>> Alexander Koksharov via FreeIPA-devel wrote:
>> > Hello,
>> >
>> > Please take a look on a design page here:
>> > https://www.freeipa.org/page/V4/Authselect_migration
>> > I would like to
>> >
>> > hear you critics and suggessions.
>>
>>
>> On a non-technical note there are a number of spelling and grammatical
>> errors.
>>
>> You assert that non-SSSD is deprecated. Is that true? And is that
>> because authselect is choosing not to support it?
>
> Yes.
>
>> I'm ok with it and it
>> simplifies options a lot but I don't recall a conversation about that
>> before now. This is particularly important for in-place upgrades.
>
> What kind of a setup has non-SSSD clients? SSSD has been the default
> since RHEL-6 and I even thought the IPA installer dropped support for
> non-SSSD clients, but I haven't really checked.

--no-sssd option in  ipa-client-install was marked as deprecated in
https://github.com/freeipa/freeipa/pull/848 (summer 2017). As part of
https://pagure.io/freeipa/issue/5860 - spin of
https://pagure.io/freeipa/issue/5557. Origin was that IPA client
doesn't bring dependencies for --no-sssd.

I.e. the deprecation is quite new.

Installation without SSSD is AFAIK not tested upstream.

-- 
Petr Vobornik
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 08:57:55AM -0500, Rob Crittenden via FreeIPA-devel 
wrote:
> Alexander Koksharov via FreeIPA-devel wrote:
> > Hello,
> > 
> > Please take a look on a design page here:
> > https://www.freeipa.org/page/V4/Authselect_migration
> > I would like to
> >  
> > hear you critics and suggessions.
> 
> 
> On a non-technical note there are a number of spelling and grammatical
> errors.
> 
> You assert that non-SSSD is deprecated. Is that true? And is that
> because authselect is choosing not to support it? 

Yes.

> I'm ok with it and it
> simplifies options a lot but I don't recall a conversation about that
> before now. This is particularly important for in-place upgrades.

What kind of a setup has non-SSSD clients? SSSD has been the default
since RHEL-6 and I even thought the IPA installer dropped support for
non-SSSD clients, but I haven't really checked.
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

On Thu, Feb 15, 2018 at 04:49:23PM +0200, Alexander Bokovoy via FreeIPA-devel 
wrote:
> On Thu, 15 Feb 2018, Alexander Koksharov wrote:
> > Hello,
> > 
> > I would like to confirm whether we do want to completelly drop --no-sssd
> > option.
> > "no-sssd" configuration is not supported by authselect - there is not such
> > profile available.
> > If we drop dependency on authconfig there will be a need to do code cleanup
> > and also to rewrite related parts. And if we agreed on rewriting some parts
> > there wont be any problems replacing multiple calls to authconfig with a
> > single one to outhselect.
> I think we should make sure authselect does support non-sssd profile.

authselect supports sssd and winbind. nss-pam-ldapd, pam_krb5 etc are
considered legacy and not supported. Nothing prevents you from creating
your own authselect profile for these, though, but authselect upstream
doesn't provide these.

What kind of non-sssd profile? What is the use-case for this?

> Otherwise it is not a real replacement for authconfig in Fedora.

Again, what reason is there to use anything else than SSSD or winbind?
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-15 Thread Alexander Bokovoy via FreeIPA-devel


On Thu, 15 Feb 2018, Alexander Koksharov wrote:

Hello,

I would like to confirm whether we do want to completelly drop --no-sssd
option.
"no-sssd" configuration is not supported by authselect - there is not such
profile available.
If we drop dependency on authconfig there will be a need to do code cleanup
and also to rewrite related parts. And if we agreed on rewriting some parts
there wont be any problems replacing multiple calls to authconfig with a
single one to outhselect.

I think we should make sure authselect does support non-sssd profile.
Otherwise it is not a real replacement for authconfig in Fedora.






Alexander

On Wed, Feb 14, 2018 at 10:00 AM, Alexander Bokovoy 
wrote:


On ke, 14 helmi 2018, Alexander Koksharov via FreeIPA-devel wrote:


Hello,

Please take a look on a design page here:
https://www.freeipa.org/page/V4/Authselect_migration
I would like to
??? ???
hear you critics and suggessions.


Thanks!

One note I have is about authconfig arguments. We gather them together
and launch only one authconfig command. There is, I believe, a
conceptual difference when you run authconfig with all options in a
single line and as separate executions so you'd get different
configurations.

This may be subtle on a first view but we need to ensure that an
authselect replacement would continue to provide the same configuration
in the end.


I assume you are going to add actual authselect part later.
--
/ Alexander Bokovoy



--
/ Alexander Bokovoy
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design

2018-02-15 Thread Rob Crittenden via FreeIPA-devel

Alexander Koksharov via FreeIPA-devel wrote:
> Hello,
> 
> Please take a look on a design page here:
> https://www.freeipa.org/page/V4/Authselect_migration
> I would like to
>  
> hear you critics and suggessions.

On a non-technical note there are a number of spelling and grammatical
errors.

You assert that non-SSSD is deprecated. Is that true? And is that
because authselect is choosing not to support it? I'm ok with it and it
simplifies options a lot but I don't recall a conversation about that
before now. This is particularly important for in-place upgrades.

I'm not convinced that the KCS you point to to set NISDOMAIN is relevant
here because that refers to running YP. In this case we have client
machines. I think you'd need to see what authconfig is changing.

rob
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: authconfig replacement design