On Wed, Apr 4, 2018 at 3:37 PM, Rob Crittenden via FreeIPA-devel
<freeipa-devel@lists.fedorahosted.org> wrote:
> Florence Blanc-Renaud via FreeIPA-devel wrote:
>> Hi all,
>>
>> I am currently reviewing the PR for authconfig replacement with
>> authselect (see [1]) but I am not 100% sure of the direction we should
>> aim for (many items were discussed in the mailing list but it's not
>> clear on which an agreement was reached).
>>
>> 1/ Deprecation of --no-sssd option:
>> - on non-fedora/non-rhel platforms, my understanding is that we should
>> keep this option and let the distros implement their specific code in
>> ipaplatform/<distro>/tasks.py
>
> I like this.

I'm OK with it. But still, I think that distros can solve the task
(configure pam stack) by their specific code even without --no-sssd
option.

>
> Note that I don't like the current deprecation method in IPA which
> simply hides operations that are "deprecated" from the cli help. IMHO
> they should complain loudly, in blink if possible.
>
>> - what does it mean for fedora/rhel platform? we could add a check in
>> tasks.py called during install_check, refusing this option on
>> fedora/rhel (with a clean exit from ipa-client-install) and allowing
>> this on other distributions. Other proposals?
>
> I think practically speaking we don't do any upstream testing without
> SSSD. I'd be ok dropping all non-SSSD options. They were allowed because
> at the time SSSD was still very new and we wanted to be able to more
> easily integrate with existing systems. I think at this point SSSD is
> sufficient for the vast majority (if not all) use cases.
>
> So yes, drop non-SSSD from Fedora/RHEL with a nice message and an exit
> code of 1.

+1

>
>>
>> 2/ How do we handle backup/restore:
>> -the server may have been installed with authconfig then upgraded, or
>> directly installed with authselect.
>> If authselect was used, we can leverage 'authselect current' to save the
>> current state.
>> If authconfig was used, we have an issue as ipa-backup is currently
>> calling authconfig --savebackup but this option (--savebackup) is not
>> supported anymore when authselect is installed. Does it mean that we
>> should migrate the configuration to authselect during
>> ipa-server-upgrade? Is it ok to migrate only servers or should we also
>> migrate clients?
>
> I'm not sure how clients are involved for the backup/restore case as we
> don't backup clients outside of masters.
Right, migrating only servers and their client part is fine. I'd
migrate so that we don't need to maintain procedures for
no-longer-used components. Keep the state machine as minimal as
possible.

>
>> - ipa-restore can be forced to restore a backup made on a different
>> version. This means we could end up in a situation where the backup was
>> done with authselect, but restored with authconfig. This should not be a
>> problem because backup/restore is done on a server and servers cannot be
>> installed with --no-sssd, but it means that there will be a migration to
>> the authselect sssd profile.
>
> If someone does a restore despite the different version warning then
> they have to acknowledge that there be dragons.

Using backup from a higher version with packages from lower is asking
for troubles. I'd not focus on it. IPA does not support downgrades. It
would be too complex support long-term. At the same time, I'd not
disallow it. E.g. the version difference could be minor - e.g. one
little bug fix and there, such restore might make sense.

>
> We can also add a string to the header to include some hints on how
> client side was configured. If there is no mention of it in the header
> then it would be safe to assume it was authconfig. Then we can print
> some message, allow user override or whatever to either let the restore
> continue, force them to do data-only or roll the dice and see what
> happens (probably fail).
>
>> 3/ How do we handle uninstall:
>> the client may have been installed with authconfig then upgraded. When
>> the pre-install config does not correspond to a supported authselect
>> profile, how should we react (because we won't be able to restore
>> exactly the same conf)? Simply log a warning, exit on error?
>
> I think similarly we may need to store state on what config tool was
> used and warn if we can somehow detect if that tool is no longer
> available (if possible) or if it fails to restore.
>
> I think we should work in coordination with the authselect folks to be
> able to restore to at least some type of working state, even if that
> state would be the OS default.

+1

FreeIPA mostly assumes that it will start with a configuration which
is close to the system default. Going back to new system default would
be, IMO, preferred then trying some non-working config.

>
> Two ideas on what we could do if we can't properly restore the state:
> 1. print the previous config and restore default state
> 2. print the previous config and fail and let the user sort it out
>
> By previous config I think we could just show what the authconfig
> restore command-line would look like.

I'm not sure if anything related to authconfig should be printed if
system is using authselect. If the admin is not experienced then it
might be confusing, e.g. the admin could try to configure auth via
authconfig instead of using preferred authselect profile.

>
> I'm a bit torn on the return value in this case but I think returning
> non-zero would catch someone's attention to check into things. Hopefully
> they'd see CLI or logging output and the cause would be clear enough
> that they won't have to raise questions to figure out what happened.
>
> rob
-- 
Petr
_______________________________________________
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

Reply via email to