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