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
