On Thu, Feb 15, 2018 at 5:52 PM, Alexander Bokovoy
<abokovoy(a)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(a)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=&a...
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