On Tue, Dec 05, 2017 at 01:35:03PM +0100, Martin Kolman wrote: > 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 Unfortunately no. But it shouldn't be hard to add a --root option to hostnamectl, similarly to systemctl, systemd-sysuser, systemd-tmpfiles and so on. Please open a bug upstream if that'd be useful. Zbyszek > > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
