RFE: Support per OS variant (os_id & variant_id) configuration profiles

[travier]

See:

• Initial discussion in data/profile.d: Add profiles for KDE & Kinoite Spins anaconda#3577
• Current configuration: https://github.com/rhinstaller/initial-setup/blob/master/data/10-initial-setup.conf
• Code:

  initial-setup/initial_setup/__init__.py

  Lines 110 to 112 in 1ba27b4

  	conf.set_from_detected_profile(
  	get_os_release_value("ID")
  	)

[poncovka]

Hi, the current solution is sufficient for use cases we know about. We cannot use Anaconda's profiles for variants, because they can be too installer-specific and not suitable for Initial Setup. Initial Setup would have to use it's own profiles to make the change safe.

I am not sure what is your use case. Which configuration changes in Initial Setup do you plan for Fedora Kinoite?

[travier]

From rhinstaller/anaconda#3577 (comment), I understood that I could work on Initial Setup to have a per variant set of spokes configuration. Those profiles would be specific to initial setup and not the ones used for Anaconda. Did I misunderstood something?

[M4rtinK]

Initial Setup has a "reconfiguration" mode, that looks like this:

Is this spoke selection sufficient for your usacese ? It's pretty much all the spokes we can safely run on a freshly booted system (eq. no storage spoke, etc.).

If this was sufficient for your usecase, just make sure there is /root/anaconda-ks.cfg on the system when it boots, that contains firstboot --reconfig.

(This is the Anaconda output kickstart file, so it can contain also other stuff, but the firstboot command is what activates the reconfiguration mode in Initial Setup when it parses the file.)

[travier]

This looks like what we need. So I should just add firstboot --reconfig to the KDE kickstarts?

[travier]

https://pagure.io/fedora-kickstarts/pull-request/840

[M4rtinK]

This looks like what we need. So I should just add firstboot --reconfig to the KDE kickstarts?

Yep, that should be it - just make sure the command is in /root/anaconda-ks.cfg when the installed system boots and that should be it. :)

EDIT: That's the kickstart that generates the live image, right ? That would not propagate to the target system.

Rather, I would suggest using one of the drop files Initial Setup supports to trigger the reconfig mode. Initial Setup look for these files at startup and enables the reconfig mode if at least one of these files exists.

The %post in the KDE live kickstart would then look like this:

%post
touch /etc/reconfigSys
%end

[travier]

Thanks for the review. Indeed, this will only enable Initial Setup for the LiveISO which is not what we want.

Would the %post be run during Anaconda setup and not the LiveISO setup? It seems to me that changing this file will only impact the LiveISO. I don't know yet how I could impact the kickstart used for the actual installation.

[M4rtinK]

Would the %post be run during Anaconda setup and not the LiveISO setup? It seems to me that changing this file will only impact the LiveISO. I don't know yet how I could impact the kickstart used for the actual installation.

Live installations use the same rootfs to both boot from (so that users can try the distro) as well as to install on the target system. Anaconda basically creates a storage layout on the target system and then uses rsync to copy content of the live image rootfs to the newly created storage.

And, if I understand the Fedora live image creation process correctly, the kickstarts in the fedora-kickstarts repository are used to create the live image and its rootfs. So if you add a %post script that creates /etc/reconfigSys on the live image rootfs, the /etc/reconfigSys file will then be rsynced to the target system by Anaconda during the installation process and Initial setup will then find it after reboot.

CCing @AdamWill @bcl to possibly confirm I'm not totally wrong about the Fedora live image creation process. ;-)

[travier]

Thanks for the interesting answer! So this would work for the KDE Live.

However, AFAIK, this is not how the Silverblue / Kinoite installation process work (but I might definitely be wrong there) so we might some other tweaks.

[AdamWill]

Martin is basically right, but indeed exactly because the live %post stuff only applies to live images - not to other install paths, including install from netinst or a spin like Kinoite - we don't generally do this kind of customization there. Customization in there is usually things we only need to do for live installs.

If the goal is to have initial-setup always run in the reconfiguration mode on first boot of a freshly-installed KDE/Kinoite system - as opposed to only running if no root password or admin user was configured during install, as I believe is the current configuration - I would look at how we can modify the logic for deciding how and whether to start initial-setup; it ought to be possible to work this in there in some way which could apply to all KDE-ish installs, I think?

[M4rtinK]

If the goal is to have initial-setup always run in the reconfiguration mode on first boot of a freshly-installed KDE/Kinoite system - as opposed to only running if no root password or admin user was configured during install, as I believe is the current configuration - I would look at how we can modify the logic for deciding how and whether to start initial-setup; it ought to be possible to work this in there in some way which could apply to all KDE-ish installs, I think?

That's a good point! Yeah, it might make sense to have this logic handled at the same time when we decide if we start the Initial Setup Systemd service. Might as well also turn on the reconfiguration mode if requested.

Implementation wise I think this could be an option in the Anaconda profile file, that KDE/Kinoite or any other Fedora spin/flavor could set as part of their profile. And there is going to be a KDE/Kinoite profile if I understand things correctly.

Maybe an option called reconfigure_system in the [Installation Target] section ? @poncovka what do you think ?

[travier]

OK, will try to look at this on the Anaconda side as our previous tries are unsuccessful: https://pagure.io/fedora-kickstarts/pull-request/845

[M4rtinK]

OK, will try to look at this on the Anaconda side as our previous tries are unsuccessful: https://pagure.io/fedora-kickstarts/pull-request/845

Do you have some more information about that not working ?

[poncovka]

Hi, I suggest to support in Anaconda the following configuration section:

[Services]
# Should we enable the post-installation tools?
post_install_tools_enabled = True

# The mode of the post-installation tool.
# Valid values:
#
#   DEFAULT          The default mode.
#   RECONFIGURATION  The reconfiguration mode.
#
post_install_tools_mode = DEFAULT

This section would control default values for /etc/sysconfig/anaconda file (https://anaconda-installer.readthedocs.io/en/latest/sysconfig-file.html). This file is created during the installations and read by the GNOME Initial Setup and the Initial Setup. We can extend the file to support the post_install_tools_mode attribute and implement support for it in the Initial Setup. Then Kinoite could set the reconfiguration mode in it's profile configuration file.

In the future, we could deprecate the /etc/reconfigSys file and support only the /etc/sysconfig/anaconda file.

If that sounds acceptable, I can handle the changes in Anaconda and @M4rtinK can handle the changes in the Initial Setup.

[travier]

OK, will try to look at this on the Anaconda side as our previous tries are unsuccessful: https://pagure.io/fedora-kickstarts/pull-request/845

Do you have some more information about that not working ?

The links to the OpenQA screenshots are there: https://pagure.io/fedora-kickstarts/pull-request/844#comment-157799

In short, this seems to enables initial setup for the Live environment too and not only for the final root.

[travier]

Hi, I suggest to support in Anaconda the following configuration section:
...
This section would control default values for /etc/sysconfig/anaconda file (https://anaconda-installer.readthedocs.io/en/latest/sysconfig-file.html). This file is created during the installations and read by the GNOME Initial Setup and the Initial Setup. We can extend the file to support the post_install_tools_mode attribute and implement support for it in the Initial Setup. Then Kinoite could set the reconfiguration mode in it's profile configuration file.

In the future, we could deprecate the /etc/reconfigSys file and support only the /etc/sysconfig/anaconda file.

If that sounds acceptable, I can handle the changes in Anaconda and @M4rtinK can handle the changes in the Initial Setup.

This sounds like a good idea to me. We would enable that for both KDE Spin & Kinoite.

Maybe we should specify a profile name for the Initial Setup so that we can ship per spin profiles and have that propagated from the installer without having to specify all configuration in Anaconda profiles? Or we can do the reverse and prefer having all config in Anaconda profiles and have that written out as config for Initial Setup?

[AdamWill]

OK, will try to look at this on the Anaconda side as our previous tries are unsuccessful: https://pagure.io/fedora-kickstarts/pull-request/845

Do you have some more information about that not working ?

The links to the OpenQA screenshots are there: https://pagure.io/fedora-kickstarts/pull-request/844#comment-157799

In short, this seems to enables initial setup for the Live environment too and not only for the final root.

The screenshots you linked don't show a live environment. The problem in those tests was that i-s ran on first boot after an install where a root password was set and an admin user created. i-s should only run on boot if no admin access has yet been configured (so neither a root password has been set nor an admin user created).

[travier]

The links to the OpenQA screenshots are there: https://pagure.io/fedora-kickstarts/pull-request/844#comment-157799
In short, this seems to enables initial setup for the Live environment too and not only for the final root.

The screenshots you linked don't show a live environment. The problem in those tests was that i-s ran on first boot after an install where a root password was set and an admin user created. i-s should only run on boot if no admin access has yet been configured (so neither a root password has been set nor an admin user created).

Oh, my bad, I did not look closely enough. This indeed worked! And I would thus have to remote the user spoke from the initial installer and update the OpenQA tests. I'll try to take a look at that as I'll have to make tests for Fedora Kinoite too.

[travier]

We might still the improvements we're discussing as the current change does not work for Fedora Kinoite.

[poncovka]

Maybe we should specify a profile name for the Initial Setup so that we can ship per spin profiles and have that propagated from the installer without having to specify all configuration in Anaconda profiles? Or we can do the reverse and prefer having all config in Anaconda profiles and have that written out as config for Initial Setup?

That's definitely something we should explore if we reach the limits of the current solution. At this moment, we have no use cases that would require these changes. The solution suggested in #136 (comment) will be used by Anaconda to configure post-installation tools in general.

[travier]

What would the difference be between the DEFAULT and RECONFIGURATION modes?

[travier]

So, if I summarize:

• Add support in Anaconda to read a parameter in the profile config to decide if it needs to write in the installed system Anaconda config that we need reconfiguration on first boot.
• Add support in Initial setup to read Anaconda config and start on first boot if enabled.
• Keep Initial Setup config as a static file, keeping all spokes enabled by default.

[M4rtinK]

What would the difference be between the DEFAULT and RECONFIGURATION modes?

DEFAULT is basically the (admin) user creation mode @AdamWill mentioned while RECONFIGURATION means "run all spokes that can run on target system" which is as far as I understand what Kinoite wants in this case.

[travier]

DEFAULT is basically the (admin) user creation mode @AdamWill mentioned while RECONFIGURATION means "run all spokes that can run on target system" which is as far as I understand what Kinoite wants in this case.

Yes, we want the RECONFIGURATION for both KDE & Kinoite to enable EOM-like installations.