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 > >> So did it mean would make it harder to port it there? > > Yes, it will. See my other response to Jakub for details. > -- 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
