Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Pierre-Yves Chibon]

On Tue, Jul 11, 2017 at 08:39:51PM +0200, Andreas Tunek wrote:
> 2017-07-11 20:33 GMT+02:00 Matthew Miller :
> > On Tue, Jul 11, 2017 at 08:10:30PM +0200, Andreas Tunek wrote:
> >> > I think that's fine. The GUI doesn't need to cover every possible use
> >> > case, and this particular use case does not seem to be in high-priority
> >> > scope for the Workstation target.
> >> Since I like that use case I would really want it to be in the scope
> >> of the Workstation. But I also know that those who do the work gets to
> >> decide.
> >
> > I mean, it's a fine thing to do, but I would expect that in this
> > situation you'd really be managing the system with Ansible or some
> > other config management, or else have some sort of directory service
> > providing identity, authentication, and authorization.
> >
> >
> 
> My setup is the default setup for Fedora since FC1! You have always
> have had to click a check box to make the first user a  user with sudo
> privileges. I always went with the default and I like that setup.

The support of admins users in Fedora is actually fairly recent, before that the
user created wasn't in the wheel group and had to be added there manually. Most
documentation for Fedora that pre-dates this change was referring people to
`su -` or `su -c "command"` as the way to get admin privileges.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-11 20:33 GMT+02:00 Matthew Miller :
> On Tue, Jul 11, 2017 at 08:10:30PM +0200, Andreas Tunek wrote:
>> > I think that's fine. The GUI doesn't need to cover every possible use
>> > case, and this particular use case does not seem to be in high-priority
>> > scope for the Workstation target.
>> Since I like that use case I would really want it to be in the scope
>> of the Workstation. But I also know that those who do the work gets to
>> decide.
>
> I mean, it's a fine thing to do, but I would expect that in this
> situation you'd really be managing the system with Ansible or some
> other config management, or else have some sort of directory service
> providing identity, authentication, and authorization.
>
>

My setup is the default setup for Fedora since FC1! You have always
have had to click a check box to make the first user a  user with sudo
privileges. I always went with the default and I like that setup.

/Andreas

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Matthew Miller]

On Tue, Jul 11, 2017 at 08:10:30PM +0200, Andreas Tunek wrote:
> > I think that's fine. The GUI doesn't need to cover every possible use
> > case, and this particular use case does not seem to be in high-priority
> > scope for the Workstation target.
> Since I like that use case I would really want it to be in the scope
> of the Workstation. But I also know that those who do the work gets to
> decide.

I mean, it's a fine thing to do, but I would expect that in this
situation you'd really be managing the system with Ansible or some
other config management, or else have some sort of directory service
providing identity, authentication, and authorization.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-11 19:50 GMT+02:00 Matthew Miller :
> On Tue, Jul 11, 2017 at 07:18:39PM +0200, Andreas Tunek wrote:
>> What I wanted to do in the GUI is to revert to the Fedora setup with
>> one root and several "regular" users. That does not seem to be
>> possible with the current GUI tools. This setup would not be possible
>> to create (using the GUI tools) with your suggested design.
>
> I think that's fine. The GUI doesn't need to cover every possible use
> case, and this particular use case does not seem to be in high-priority
> scope for the Workstation target.
>

Since I like that use case I would really want it to be in the scope
of the Workstation. But I also know that those who do the work gets to
decide.

/Andreas

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Matthew Miller]

On Tue, Jul 11, 2017 at 07:18:39PM +0200, Andreas Tunek wrote:
> What I wanted to do in the GUI is to revert to the Fedora setup with
> one root and several "regular" users. That does not seem to be
> possible with the current GUI tools. This setup would not be possible
> to create (using the GUI tools) with your suggested design.

I think that's fine. The GUI doesn't need to cover every possible use
case, and this particular use case does not seem to be in high-priority
scope for the Workstation target.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-11 16:25 GMT+02:00 Michael Catanzaro :
> On Tue, Jul 11, 2017 at 6:40 AM, Andreas Tunek 
> wrote:
>>
>> So you mean that bug 1270953
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1270953)  is
>> fixed/implemented?
>
>
> I'm not sure it was ever broken. Did you make sure there was an another
> administrator first before trying to remove the last one? :)
>
> I just tested it and it is *not* necessary to switch user accounts at all,
> thankfully. You can set or remove the administrator status of any user from
> control-center as long as another administrator exists.
>
> Michael
>

What I wanted to do in the GUI is to revert to the Fedora setup with
one root and several "regular" users. That does not seem to be
possible with the current GUI tools. This setup would not be possible
to create (using the GUI tools) with your suggested design.

/Andreas

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Michael Catanzaro]

On Tue, Jul 11, 2017 at 6:40 AM, Andreas Tunek 
 wrote:

So you mean that bug 1270953
(https://bugzilla.redhat.com/show_bug.cgi?id=1270953)  is
fixed/implemented?


I'm not sure it was ever broken. Did you make sure there was an another 
administrator first before trying to remove the last one? :)


I just tested it and it is *not* necessary to switch user accounts at 
all, thankfully. You can set or remove the administrator status of any 
user from control-center as long as another administrator exists.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-10 21:37 GMT+02:00 Michael Catanzaro :
> On Mon, Jul 10, 2017 at 12:04 PM, Andreas Tunek 
> wrote:
>>
>> Will there be any GUI method to remove the sudo rights from the first
>> created user?
>
>
> I believe you can do this from gnome-control-center if and only if you first
> (a) create another admin (wheel) user and log in as that user, or (b) set a
> root password, create a new non-admin user, and log in as that user.
>
> It's designed to not allow removing the only admin account, and I'm not sure
> if it allows you to remove your own admin status.
>
> Michael
>

So you mean that bug 1270953
(https://bugzilla.redhat.com/show_bug.cgi?id=1270953)  is
fixed/implemented?

/Andreas

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Chris Adams]

Once upon a time, Michael Catanzaro  said:
> On Mon, Jul 10, 2017 at 12:12 PM, Reindl Harald
>  wrote:
> >and how do you imagine systemd to "get fixed"?
> >by allow the rescue target without authentication?
> >
> >at this point you are mostly in the dracut stuff
> >
> >that "popular pattern" needs to be fixed
> 
> One option would be to prompt for username, and allow logins for any
> user in the admin group.
> 
> I don't see much point to having a rescue mode if it's never worked
> for the vast majority of its users (Ubuntu users).

IIRC, the old initscripts used sushell (which just directly starts a
shell), and systemd switched to using sulogin (which requires a
password).

There are arguments for/against each, with "sulogin --force" in between
(my personal preference would be "sulogin --foce", but I recognize
that's just my preference).

What I would like to see with the current systemd setup is for what
shell is called to be more consistently configurable than grepping for
all the service files that call sulogin, copying them to
/etc/systemd/system, and doing a search/replace.  Right now, that means
that if there's a change to one of those service files, or if additional
service files are created that call sulogin/sushell, you'll miss on that
just because you wanted to change local policy for a portion of it.

IMHO it would be much better if there was a single place to set this
policy by default (and admins could still override it on a per-case
basis by replacing the service file).  Either use a file in
/etc/sysconfig or follow a symlink (although the "sulogin --force" can't
currently be achieved directly that way).

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Michael Catanzaro]

On Mon, Jul 10, 2017 at 12:12 PM, Reindl Harald 
 wrote:

and how do you imagine systemd to "get fixed"?
by allow the rescue target without authentication?

at this point you are mostly in the dracut stuff

that "popular pattern" needs to be fixed


One option would be to prompt for username, and allow logins for any 
user in the admin group.


I don't see much point to having a rescue mode if it's never worked for 
the vast majority of its users (Ubuntu users).


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Michael Catanzaro]

On Mon, Jul 10, 2017 at 12:04 PM, Andreas Tunek 
 wrote:

Will there be any GUI method to remove the sudo rights from the first
created user?


I believe you can do this from gnome-control-center if and only if you 
first (a) create another admin (wheel) user and log in as that user, or 
(b) set a root password, create a new non-admin user, and log in as 
that user.


It's designed to not allow removing the only admin account, and I'm not 
sure if it allows you to remove your own admin status.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Neal Gompa]

On Fri, Jul 7, 2017 at 10:24 AM, Jaroslav Reznik  wrote:
> = System Wide Change: Reduce Initial Setup Redundancy =
> https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
>
> Change owner(s):
> * Michael Catanzaro 
>
> 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).
>
> 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.
>
> 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.)
>
> 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.
>
> 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 

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Andreas Tunek]

2017-07-07 16:24 GMT+02:00 Jaroslav Reznik :
> = System Wide Change: Reduce Initial Setup Redundancy =
> https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy
>
> Change owner(s):
> * Michael Catanzaro 
>
> 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).
>
> 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.
>
> 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.)
>
> 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.
>
> 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 

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Adam Williamson]

On Mon, 2017-07-10 at 10:53 -0500, Michael Catanzaro wrote:
> My suggestion is some sort of debug option for Anaconda that would 
> allow QA to set a root password when needed to investigate something 
> going wrong, or for OpenQA. It could even allow visiting arbitrary 
> Anaconda spokes.

We really want to keep the delta between what openQA does and what real
people do as small as possible. The entire point of openQA testing is
to test the bits we('re going to) ship, exactly as they will really be
used by real people. The danger is obvious: what if there's a bug in
anaconda which doesn't show up when it's run in debug mode? The tests
won't catch it...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Kamil Paral]

On Mon, Jul 10, 2017 at 5:53 PM, Michael Catanzaro  wrote:

> OK, I see the problem.
>
> On the one hand, systemd needs fixed, as disabled root account is already
> a popular pattern on the largest Linux distro out there. This is an issue
> for rescue prompts too.


That would be great.


> But it's true that doesn't help the case where there is no user account at
> all.
>
> One can reboot into Live environment and mount the disks, but that's
>> tedious, and most importantly, it requires a reboot, so we lose the
>> information about the running system (e.g. which process is stuck in a
>> loop). Also, I believe OpenQA uses pre-created root account in anaconda to
>> switch to tty2 and upload any error logs in case of any troubles, in a
>> fully automated way. So it's not just manual testing affected.
>>
>> Thoughts on how to resolve that? It seems we need at least the root
>> password option kept.
>>
>
> My suggestion is some sort of debug option for Anaconda that would allow
> QA to set a root password when needed to investigate something going wrong,
> or for OpenQA. It could even allow visiting arbitrary Anaconda spokes.
> That's already possible if you edit /etc/sysconfig/anaconda before running
> anaconda, which is admittedly one more annoying step that you'd have to
> follow before starting Anaconda in order to debug the problem, but it
> works. OpenQA could also do that, though that's not superb as then OpenQA
> is testing its own special configuration.
>

That's the problem. We want to test *the very same code* the user runs. If
we edit a config file or provide a cmdline argument, we deviate from that
and test a different codepath. It might be a minor change, but the purpose
here is still test exactly the same as experienced by the user. Only that
way we can be sure the composes really work as expected. That's also one of
the reasons we use OpenQA (simulating real user input via keyboard and
mouse) instead of e.g. modifying the anaconda environment and using e.g.
dogtail to control the GUI.

If you're completely convinced that those options need to go away, we'll
have to rethink our goals. But we'd definitely prefer to continue testing
the unaltered environment.

Thinking more about it, specifically for OpenQA, I guess we could do
something like switch to tty2 once we detect "quit" button is active, and
run a command to set root password in the mounted new filesystem. Then
switch back and reboot the machine. That doesn't really modify the
installer codepath and ensures root is reachable. It's a bit annoying for
manually installs, but those are not that important (and for those, we
could use the debug option to show the spokes, when we know we're trying to
reproduce a specific problem).

Adam, wdyt?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Michael Catanzaro]

On Mon, Jul 10, 2017 at 9:27 AM, Kamil Paral  wrote:
So if I read correctly, on the first boot the installed system will 
have no user account and no root password.


Yup.

That might be very inconvenient for QA. If anything goes wrong during 
the first boot (and it often does during development), we need to be 
able to log in on TTY2+. Without the ability to create an account 
beforehand, that's not possible. Rebooting into runlevel 1 is also 
not possible without root password (it's required by systemd).


OK, I see the problem.

On the one hand, systemd needs fixed, as disabled root account is 
already a popular pattern on the largest Linux distro out there. This 
is an issue for rescue prompts too. But it's true that doesn't help the 
case where there is no user account at all.


One can reboot into Live environment and mount the disks, but that's 
tedious, and most importantly, it requires a reboot, so we lose the 
information about the running system (e.g. which process is stuck in 
a loop). Also, I believe OpenQA uses pre-created root account in 
anaconda to switch to tty2 and upload any error logs in case of any 
troubles, in a fully automated way. So it's not just manual testing 
affected.


Thoughts on how to resolve that? It seems we need at least the root 
password option kept.


My suggestion is some sort of debug option for Anaconda that would 
allow QA to set a root password when needed to investigate something 
going wrong, or for OpenQA. It could even allow visiting arbitrary 
Anaconda spokes. That's already possible if you edit 
/etc/sysconfig/anaconda before running anaconda, which is admittedly 
one more annoying step that you'd have to follow before starting 
Anaconda in order to debug the problem, but it works. OpenQA could also 
do that, though that's not superb as then OpenQA is testing its own 
special configuration.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Reduce Initial Setup Redundancy

[Kamil Paral]

On Fri, Jul 7, 2017 at 4:24 PM, Jaroslav Reznik  wrote:

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



So if I read correctly, on the first boot the installed system will have no
user account and no root password. That might be very inconvenient for QA.
If anything goes wrong during the first boot (and it often does during
development), we need to be able to log in on TTY2+. Without the ability to
create an account beforehand, that's not possible. Rebooting into runlevel
1 is also not possible without root password (it's required by systemd).
One can reboot into Live environment and mount the disks, but that's
tedious, and most importantly, it requires a reboot, so we lose the
information about the running system (e.g. which process is stuck in a
loop). Also, I believe OpenQA uses pre-created root account in anaconda to
switch to tty2 and upload any error logs in case of any troubles, in a
fully automated way. So it's not just manual testing affected.

Thoughts on how to resolve that? It seems we need at least the root
password option kept.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org