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