Florence Blanc-Renaud wrote: > On 04/04/2018 03:37 PM, Rob Crittenden 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. >> >> 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. >> > Hi Rob, > > thanks for your input. Just to clarify, which options do you mean > (non-SSSD options): --no-sssd, --noac, --no-sudo?
Just --no-sssd and --noac. --no-sudo doesn't go through authconfig, it is an sssd-configured service. rob > Flo >> So yes, drop non-SSSD from Fedora/RHEL with a nice message and an exit >> code of 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. >> >>> - 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. >> >> 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. >> >> 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 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 >> > _______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
