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