On Tue, 2017-12-05 at 07:18 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Dec 04, 2017 at 04:09:25PM +0100, Jan Kurik wrote: > > = System Wide Change: Reduce Initial Setup Redundancy = > > https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy > > > > Change owner(s): > > * Michael Catanzaro <mcatanzaro AT gnome DOT org> > > > > 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. > > > > > > > > == 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). > > Hi, > > apart from some more technical issues that people are raising, I find > this text generally hard to read. Not sure to what extent it's the > early hour or the lack of coffee or the text, so see some suggestions > below: > > > 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 > > Does it mean that just visiting a spoke will cause it to be written > to /etc/sysconfig/anaconda to suppress it in g-i-s? > Or does the user actually have to configure something there? > > > , 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. > > ... and to suppress some spokes in g-i-s, afaiu. So this part should > probably go after the next sentence, so that it's clearer that the > suppression will happen both in anaconda and in g-i-s. > > > 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 === > > > > 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.) > > Since that talks about something that will not happen yet, maybe move > it to some "discussion" section? > > Also, please consider reworking the text to have in each section > first a short summary of what the decision is, and then the justification > below. This text is long and it's hard to "scan". > > > 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.) > > > > === 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. > > Another possibility is to teach anaconda to use hostnamectl/hostnamed > to set the hostname. We already use hostnamectl[0] to set the hostname *for the installation environment*, but we just create a configuration file[1] *for the installed system*. Is there a way to tell hostnamectl/hostnamed to set the hosname for the installation chroot ? Then we would be able to use it for both. [0] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/network.py#L1287 [1] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/network.py#L1292 > This would make things more consistent... We could > expose the code to canonicalize the pretty name as an api or command > line interface so that anaconda could show the pretty and canonicalized > names interactively. > > > 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. > > > > === 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. > > > > === 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`. > > Zbyszek > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
