On Fri, Feb 16, 2018 at 11:25 AM, Alexander Bokovoy via FreeIPA-devel
<freeipa-devel@lists.fedorahosted.org> 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=<domain>
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 <aboko...@redhat.com>
>>> wrote:
>>> > On Thu, 15 Feb 2018, Petr Vobornik wrote:
>>> >>
>>> >> On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy
>>> >> <aboko...@redhat.com
>>> >
>>> >> wrote:
>>> >>>
>>> >>> On Thu, 15 Feb 2018, Petr Vobornik wrote:
>>> >>>>
>>> >>>>
>>> >>>> On Thu, Feb 15, 2018 at 5:23 PM, Jakub Hrozek via FreeIPA-devel
>>> >>>> <freeipa-devel@lists.fedorahosted.org> 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=&q=freeipa&;
>>> maintainer=&flagged=
>>> >>
>>> >> 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) because the thing which
>>> I care here about is not to increase the number of combinations of
>>> options or cases to test and support. Keeping it will slightly
>>> increate the number of combinations. Making the number smaller would
>>> be a nice bonus.
>>>
>>>
>>> > 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.
>>>
>>> There is no other platform atm which would require `not options.sssd`
>>> kind of flow. But I actually agree that we should not kill the flow.
>>> Is not worth the risk and time related to it. It can be a task for
>>> later time when we have better test coverage.
>>>
>>>
>>> Reasons why to remove(or just ignore) --no-sssd when possible:
>>>
>>> I'd say that introduction of this option was not a good thing. looking
>>> at https://github.com/freeipa/freeipa/commit/
>>> 3ff06c498b5f918bec65cbe20b40aedb37f475b6
>>> There is no exact reasoning. I'd guess that idea was to make the old
>>> method possible, e.g. because SSSD was relatively new. This might have
>>> been very ok at that time. From today's perspective, the option is not
>>> giving any value. It provides a different mean to achieve the same
>>> goal (central authentication) but in a worse way (assuming SSSD is
>>> better).
>>>
>>> I expect that admin care that ipa-client-install prepares the host for
>>> some functionality(what). How it is achieved is an implementation
>>> detail. --no-sssd is "how" not "what".
>>>
>>> Even if the option is removed, ipa-client-install should work on
>>> platforms without SSSD. It would just configure something else via
>>> some method specified in platform code, e.g. authconfig.
>>>
>>> Similar issue is with ipa-client-automount which also has --no-sssd to
>>> choose between technology stacks (but here it might be more valid,
>>> though the option name is not the best)
>>>
>>> https://access.redhat.com/documentation/en-us/red_hat_
>>> enterprise_linux/7/html-single/linux_domain_identity_
>>> authentication_and_policy_guide/#autofs-tool
>>> """
>>> There may be some instances, such as highly secure environments, where
>>> it is not appropriate for a client to cache automount maps. In that
>>> case, the ipa-client-automount command can be run with the --no-sssd
>>> option, which changes all of the required NFS configuration files, but
>>> does not change the SSSD configuration.
>>> """
>>>
>>> TL;DR;:
>>> - agree to not kill the flow
>>> - agree to keep RedHatAuthConfig class (ie.. authconfig support) in
>>> code base for other platforms
>>> - to not depend on authonfig on Fedora and RHEL
>>> - fail gracefully when when --no-sssd is provided and authconfig is
>>> not installed
>>> - proposal, to ignore and hide --no-sssd option on Fedora and RHEL
>>>
>>> --
>>> 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 mailing list -- freeipa-devel@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
>
>
>
> --
> / Alexander Bokovoy
>
> _______________________________________________
> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
--
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
