From Fedora Project Wiki
No edit summary
 
(21 intermediate revisions by 3 users not shown)
Line 9: Line 9:
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <mcatanzaro@gnome.org>
* Email: <mcatanzaro@gnome.org>
* Release notes owner:  
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/81 #81]
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 17: Line 17:


== Current status ==
== Current status ==
* Targeted release: [[Releases/27 | Fedora 27 ]]  
* Targeted release: [[Releases/28 | Fedora 28 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1474787 #1474787]
Bugzilla states meaning as usual:
NEW -> change proposal is submitted and announced
ASSIGNED -> accepted by FESCo with on going development
MODIFIED -> change is substantially done and testable
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
* Tracker bug: <will be assigned by the Wrangler>


== Detailed Description ==
== Detailed Description ==


Firstly, please note that the effects of this change will be restricted to Fedora Workstation. We do not propose any changes that affect alternative Fedora installers (e.g. Calamares) or initial setup tools (e.g. the initial-setup package, not to be confused with gnome-initial-setup).
Firstly, please note that the effects of this change will be restricted to live installs of Fedora Workstation. We do not propose any changes that affect alternative Fedora products or spins, or netinstall mode.


A few years ago, Fedora Workstation developers discussed with Anaconda developers the redundancy between many Anaconda settings and gnome-initial-setup. The Anaconda developers responded by added a configuration file mechanism, /etc/sysconfig/anaconda, which can be used to suppress Anaconda spokes if written before Anaconda runs. This file is also written by Anaconda to tell the initial-setup tool which Anaconda spokes the user has visited, so that the initial-setup tool can suppress specific spokes. Although this functionality has existed for some time now, the Workstation developers until now failed to follow up and begin using it. We now intend to make use of this functionality to suppress Anaconda spokes that are redundant with gnome-initial-setup. Meanwhile, our friends at Endless OS have added a similar configuration file for gnome-initial-setup that allows us to suppress some configuration that is best handled in Anaconda. Below, we discuss what we plan to do with specific settings.
A few years ago, Fedora Workstation developers discussed with Anaconda developers the redundancy between many Anaconda settings and gnome-initial-setup. The Anaconda developers responded by added a configuration file mechanism, /etc/sysconfig/anaconda, which can be used to suppress Anaconda spokes if written before Anaconda runs. Although this functionality has existed for some time now, the Workstation developers until now failed to follow up and begin using it. We now intend to make use of this functionality to suppress Anaconda spokes that are redundant with gnome-initial-setup. Meanwhile, our friends at Endless OS have added a similar configuration file for gnome-initial-setup that allows us to suppress some configuration that is best handled in Anaconda. Below, we discuss what we plan to do with specific settings.


=== Language and Keyboard Layout ===
=== Language and Keyboard Layout ===


Although we do not propose it at this time, language and keyboard layout selection should be presented to the user *before* entering the live session, as it is currently too difficult for users to change these settings unless they are already familiar with Fedora, and -- unless you speak English and use a US keyboard -- these settings must be changed for the live session to be usable. Both Anaconda and gnome-initial-setup are too late for configuring these settings. (An exception would be for netinstalls of Fedora Workstation, where Anaconda is the best place for this configuration.) In the meantime, until we have a way to prompt users for these settings earlier than Anaconda, these panels should be removed from gnome-initial-setup, because Anaconda is clearly a better place than gnome-initial-setup for this configuration. (This would affect gnome-initial-setup when creating the first user account. Additional user accounts created later would still receive these panels in gnome-initial-setup.)
These panels will be removed from gnome-initial-setup. They must already be configured in Anaconda for the installer to be usable, so there is no point in displaying them again in gnome-initial-setup. (This would affect gnome-initial-setup when creating the first user account. Additional user accounts created later would still receive these panels in gnome-initial-setup.)


=== Time and Date ===
=== Time and Date ===
Line 45: Line 37:
=== Network ===
=== Network ===


We will remove the network configuration spoke from Anaconda. Currently this spoke only allows configuring the system hostname, but it places restrictions on the possible characters in the hostname that do not match the restrictions used by Fedora Workstation. Fedora Workstation uses systemd-hostnamed to allow "pretty" hostnames with Unicode characters and spaces, which we expect to be displayed properly and consistently in the user interface, but the Anaconda configuration does not follow this pattern. Additionally, exposing the hostname as network configuration is confusing. We may consider adding a simpler "Computer Name" setting that allows "pretty" characters and is not presented as a networking setting in the future, but it does not seem necessary to prompt the user to set a hostname at all.
We will remove the network configuration spoke from Anaconda.


Note: this applies only to USB install, obviously not to netinstall. We will need some way to differentiate between the two when writing the Anaconda configuration file.
Currently this spoke only allows configuring the system hostname, but it places restrictions on the possible characters in the hostname that do not match the restrictions used by Fedora Workstation. Fedora Workstation uses systemd-hostnamed to allow "pretty" hostnames with Unicode characters and spaces, which we expect to be displayed properly and consistently in the user interface, but the Anaconda configuration does not follow this pattern. Additionally, exposing the hostname as network configuration is confusing. We may consider adding a simpler "Computer Name" setting that allows "pretty" characters and is not presented as a networking setting in the future, but it does not seem necessary to prompt the user to set a hostname at all.


=== User Account ===
=== User Account ===


Currently, users have the option of creating the initial user account in Anaconda, or not. Anaconda does not require this if the user sets a root password. Users who do not create a user account in Anaconda are required to create a user account later, by gnome-initial-setup. This means we currently have two different ways of creating the first user account in Workstation, with (potentially) two different sets of bugs. Since Anaconda allows configuring whether the initial user is added to the wheel group, it also means some initial users will be in wheel and others will not. We will remove the user account creation spoke in Anaconda. All users will create the first user account using gnome-initial-setup, and all initial users will be added to the wheel group. Of course, this can be easily changed after installation if desired.
We will remove the user account creation spoke in Anaconda. The first user account will be created using gnome-initial-setup, and the initial user will be added to the wheel group. (Of course, this can be easily changed after installation if desired.)
 
Currently, users have the option of creating the initial user account in Anaconda, or not. Anaconda does not require this if the user sets a root password. Users who do not create a user account in Anaconda are required to create a user account later, by gnome-initial-setup. This means we currently have two different ways of creating the first user account in Workstation, with (potentially) two different sets of bugs. Since Anaconda allows configuring whether the initial user is added to the wheel group, it also means some initial users will be in wheel and others will not.


=== Root Account ===
=== Root Account ===


Currently, users have the option of setting a root password in Anaconda, or not. Anaconda does not require this if the user creates an initial user account and selects the option to add it to the wheel group. We will remove the root password creation spoke. All Workstation installs will have no root password set by default, as in Ubuntu. Having a root password is not useful for nontechnical users, and it is confusing to ask users to create multiple passwords. Because the initial user created by gnome-initial-setup will be added to the wheel group, all administrative functions will continue to be available within the desktop environment via Polkit. Additionally, the initial user will have sudo access to run commands as root. Of course, a root password can be set after installation using `sudo passwd`.
We will remove the root password creation spoke. All Workstation installs will have no root password set by default, as in Ubuntu.
 
Currently, users have the option of setting a root password in Anaconda, or not. Anaconda does not require this if the user creates an initial user account and selects the option to add it to the wheel group. Having a root password is not useful for nontechnical users, and it is confusing to ask users to create multiple passwords. Because the initial user created by gnome-initial-setup will be added to the wheel group, all administrative functions will continue to be available within the desktop environment via Polkit. Additionally, the initial user will have sudo access to run commands as root. Of course, a root password can be set after installation using `sudo passwd`.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 63: Line 59:
== Scope ==
== Scope ==
* Proposal owners: Provide a default /etc/config/anaconda file for Fedora Workstation. This could be e.g. shipped in the gnome-initial-setup package or written by the firstboot tool before Anaconda runs.
* Proposal owners: Provide a default /etc/config/anaconda file for Fedora Workstation. This could be e.g. shipped in the gnome-initial-setup package or written by the firstboot tool before Anaconda runs.
* Other developers: Anaconda developers to review UI. QA team to review installation tests.
* Other developers: Anaconda developers to review UI. QA team to review installation tests.


* Release engineering: [https://pagure.io/releng/issue/6878]
* Release engineering: [https://pagure.io/releng/issue/6878]
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: No changes needed
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: No changes needed


Line 94: Line 89:
== Contingency Plan ==
== Contingency Plan ==


* Contingency mechanism: If the contingency plan is activated, the Workstation WG will ensure our /etc/sysconfig/anaconda file does not get written or installed. Our planned Anaconda behavior changes are triggered by this file, so this will have the effect of reverting the change. If we decide to hide spokes in gnome-initial-setup using a vendor configuration file, then we would additionally remove that file to revert our changes to gnome-initial-setup.
* Contingency mechanism: If the contingency plan is activated, the Workstation WG will ensure our /etc/sysconfig/anaconda file does not get written or installed. Our planned Anaconda behavior changes are triggered by this file, so this will have the effect of reverting the change. We would further ensure our gnome-initial-setup vendor configuration file is not installed, to revert our changes to gnome-initial-setup.
* Contingency deadline: Beta freeze. This needs to be testable for beta.
* Contingency deadline: Beta freeze. This needs to be testable for beta.
* Blocks release? No. The change should be reverted if there are problems.
* Blocks release? No. The change should be reverted if there are problems.
Line 101: Line 96:
== Documentation ==
== Documentation ==


Anaconda user interaction configuration file specification: https://github.com/rhinstaller/anaconda/find/master
Anaconda user interaction configuration file specification: https://github.com/rhinstaller/anaconda/blob/master/docs/user-interaction-config-file-spec.rst


== Release Notes ==
== Release Notes ==
Line 112: Line 107:
TODO
TODO


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF28]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
 
[[Category:SystemWideChange]]
[[Category:SystemWideChange]]

Latest revision as of 14:44, 2 March 2018

Reduce Initial Setup Redundancy

Summary

Currently there is a high level of redundancy between the Anaconda installer and gnome-initial-setup. This change aims to eliminate these redundancies and streamline the initial user experience in Fedora Workstation.

Owner

  • Name: Michael Catanzaro
  • Email: <mcatanzaro@gnome.org>
  • Release notes ticket: #81
  • Product: Fedora Workstation
  • Responsible WG: Workstation WG

Current status

Detailed Description

Firstly, please note that the effects of this change will be restricted to live installs of Fedora Workstation. We do not propose any changes that affect alternative Fedora products or spins, or netinstall mode.

A few years ago, Fedora Workstation developers discussed with Anaconda developers the redundancy between many Anaconda settings and gnome-initial-setup. The Anaconda developers responded by added a configuration file mechanism, /etc/sysconfig/anaconda, which can be used to suppress Anaconda spokes if written before Anaconda runs. Although this functionality has existed for some time now, the Workstation developers until now failed to follow up and begin using it. We now intend to make use of this functionality to suppress Anaconda spokes that are redundant with gnome-initial-setup. Meanwhile, our friends at Endless OS have added a similar configuration file for gnome-initial-setup that allows us to suppress some configuration that is best handled in Anaconda. Below, we discuss what we plan to do with specific settings.

Language and Keyboard Layout

These panels will be removed from gnome-initial-setup. They must already be configured in Anaconda for the installer to be usable, so there is no point in displaying them again in gnome-initial-setup. (This would affect gnome-initial-setup when creating the first user account. Additional user accounts created later would still receive these panels in gnome-initial-setup.)

Time and Date

We want to remove the time and date spoke from Anaconda, since it is largely redundant with the timezone page in gnome-initial-setup. However, it might be necessary to remove this page from gnome-initial-setup instead, as previously there have been technical concerns raised regarding the necessity of configuring the system clock before running the installer. This choice will be based on technical feedback from the Fedora developer community.

Network

We will remove the network configuration spoke from Anaconda.

Currently this spoke only allows configuring the system hostname, but it places restrictions on the possible characters in the hostname that do not match the restrictions used by Fedora Workstation. Fedora Workstation uses systemd-hostnamed to allow "pretty" hostnames with Unicode characters and spaces, which we expect to be displayed properly and consistently in the user interface, but the Anaconda configuration does not follow this pattern. Additionally, exposing the hostname as network configuration is confusing. We may consider adding a simpler "Computer Name" setting that allows "pretty" characters and is not presented as a networking setting in the future, but it does not seem necessary to prompt the user to set a hostname at all.

User Account

We will remove the user account creation spoke in Anaconda. The first user account will be created using gnome-initial-setup, and the initial user will be added to the wheel group. (Of course, this can be easily changed after installation if desired.)

Currently, users have the option of creating the initial user account in Anaconda, or not. Anaconda does not require this if the user sets a root password. Users who do not create a user account in Anaconda are required to create a user account later, by gnome-initial-setup. This means we currently have two different ways of creating the first user account in Workstation, with (potentially) two different sets of bugs. Since Anaconda allows configuring whether the initial user is added to the wheel group, it also means some initial users will be in wheel and others will not.

Root Account

We will remove the root password creation spoke. All Workstation installs will have no root password set by default, as in Ubuntu.

Currently, users have the option of setting a root password in Anaconda, or not. Anaconda does not require this if the user creates an initial user account and selects the option to add it to the wheel group. Having a root password is not useful for nontechnical users, and it is confusing to ask users to create multiple passwords. Because the initial user created by gnome-initial-setup will be added to the wheel group, all administrative functions will continue to be available within the desktop environment via Polkit. Additionally, the initial user will have sudo access to run commands as root. Of course, a root password can be set after installation using sudo passwd.

Benefit to Fedora

Improve the initial user experience in Fedora Workstation. First impressions are important! We must not underestimate the difficulty that nontechnical users may have in answering even the most simple questions during the installation and first boot experience, so reducing the number of questions is very important.

Scope

  • Proposal owners: Provide a default /etc/config/anaconda file for Fedora Workstation. This could be e.g. shipped in the gnome-initial-setup package or written by the firstboot tool before Anaconda runs.
  • Other developers: Anaconda developers to review UI. QA team to review installation tests.
  • Policies and guidelines: No changes needed
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

There is no upgrade or compatibility impact, because this change only affects new installs. There is no effect on installed systems (after the first boot experience has been completed).

How To Test

This change should be tested by simply installing Fedora Workstation. Both the standard live USB installation method as well as the alternative netinstall installation method should be tested.

User Experience

The user should not encounter any redundant configuration prompts when installing Fedora Workstation. All users should create the initial user account in gnome-initial-setup.

Dependencies

The Anaconda user experience with most spokes removed is not currently very great. In particular, the installation progress screen looks weird. The heading "Configuration" appears at the very top of the page, underneath which there is a blank page with no configuration, except for the installation progress bar at the very bottom of the page. This is not a desirable user experience. We will rely on the Anaconda developers to have availability to improve this hub page. We should also consider hiding the main hub page as well, since the benefit of having hubs will be greatly reduced and the user experience is odd with very few hubs present. Coordination with the Anaconda developers will be required. The change may need to be delayed according to the needs of the Anaconda team.

The quality assurance team will need to update OpenQA installation tests and possibly other tests to account for the new installer workflow. Coordination with the QA team will be required. The change may need to be delayed if required by the QA team.

Contingency Plan

  • Contingency mechanism: If the contingency plan is activated, the Workstation WG will ensure our /etc/sysconfig/anaconda file does not get written or installed. Our planned Anaconda behavior changes are triggered by this file, so this will have the effect of reverting the change. We would further ensure our gnome-initial-setup vendor configuration file is not installed, to revert our changes to gnome-initial-setup.
  • Contingency deadline: Beta freeze. This needs to be testable for beta.
  • Blocks release? No. The change should be reverted if there are problems.
  • Blocks product? No. The change should be reverted if there are problems.

Documentation

Anaconda user interaction configuration file specification: https://github.com/rhinstaller/anaconda/blob/master/docs/user-interaction-config-file-spec.rst

Release Notes

TODO