|Summary:||Warn on skip of user creation|
|Product:||[Fedora] Fedora||Reporter:||Adam Williamson <awilliam>|
|Component:||initial-setup||Assignee:||Vratislav Podzimek <vpodzime>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||20||CC:||anaconda-maint-list, dmaziuk, dshea, edgar.hoch, g.kaviyarasu, jonathan, lsatenstein, Marcin.Dulak, mkolman, msivak, robatino, sbueno, vanmeeuwen+fedora, vpodzime|
|Target Milestone:||---||Keywords:||CommonBugs, Reopened|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-06-30 01:18:30 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Adam Williamson 2013-05-21 18:19:09 UTC
Currently, initial-setup happily lets you quit without creating a user account, there is no warning. This is, I think, incorrect behaviour. Fedora has generally followed the policy that graphical desktop login as root should be discouraged; on our default spin it is in fact disallowed by default. firstboot allowed you to skip user creation, but popped up a warning dialog if you did so. initial-setup should at least do the same. (Just as a side note, gnome-initial-setup currently does not allow you to skip user creation). I tested Beta RC2. The GNOME spin/group uses g-i-s so this issue is irrelevant there. KDE uses kdm as its login manager, which allows you to log in as any account; I tested that you can log in as root successfully. Xfce and MATE use lightdm, which also successfully allows root login. LXDE uses LXDM, which uses a free text field for username so it should also be possible to log in as root, but attempting to do so silently fails. So as of right now this bug can only get you into serious trouble on the LXDE spin, but we really ought to shore it up; graphical login as root is discouraged and we can't really rely on it to work.
Comment 1 Adam Williamson 2013-05-21 19:06:33 UTC
You know what? Why don't we just do this in anaconda? as I explained in this mail: https://lists.fedoraproject.org/pipermail/devel/2013-May/183114.html Now I've spent a couple of days examining all the possible scenarios here, I'm about 99% sure there's no good reason to run initial-setup at all for anything but OEM installs. In F18 and earlier, we had a simple split: anaconda set the root password, firstboot did user creation. firstboot would let you skip user creation, though, after you clicked through a warning. In F19 anaconda can now do user creation. So far as I can figure, if we simply have anaconda try and encourage user creation but allow it to be skipped by a determined user, we have covered all the use cases from earlier releases with no need to run initial-setup at all. To me, that seems much better than the unnecessary complexity of having anaconda let you skip user creation without a warning, then popping up initial-setup and having *it* encourage you to create a user. That just seems unwieldy. And as the initial incarnation of this bug report said, initial-setup doesn't even _do_ that at present. It's basically doing nothing useful whatsoever. So instead of 'fixing' initial-setup - but still having an overly complex flow - why not just get rid of it? So I think anaconda should do this: On the 'during install' hub, the 'user creation' spoke should be mandatory. You should be required to visit it before leaving the installer. But once you are in it, it should allow you to exit again without creating a user, but warn you using the standard anaconda mechanism if you try to do so: pop up the orange warning bar, with a message similar to the old firstboot one, and require you to click again to confirm. If you do that, it would let you out without creating a user. If anaconda does that, I don't see that we need initial-setup at all, except for what we've been referring to as the "OEM case" (some kind of pre-deployed Fedora, so we need something to run to let the final user of the system set up a root password and user account and time zone). We could have it only run in that case, and never show in a 'normal' install.
Comment 2 Adam Williamson 2013-05-21 20:05:10 UTC
*** Bug 949779 has been marked as a duplicate of this bug. ***
Comment 3 Brian Lane 2013-05-22 00:44:08 UTC
Forcing the user to enter the spoke just so they can exit it is silly. The initial experience apps simple need to check for an existing user and let people continue with booting their system.
Comment 4 Adam Williamson 2013-05-22 01:05:17 UTC
I don't think you quite got the idea. Yes, we can fix initial-setup. That's what this bug started out as: a request to fix initial-setup. But look, run both scenarios through your head. Imagine a world where we fix initial-setup. What does it look like? 1. You run anaconda. You create a user account. You boot your installed system; because you created a user, it boots straight to the login prompt, no need for i-s. 2. You run anaconda. You don't create a user account. initial-setup runs, and offers you solely the option to create a user account (because the other stuff it has at present is pointless and should be killed). But it lets you quit without creating one, if you want. Now imagine a world where we make this change to anaconda, and dump initial-setup entirely. What does it look like? 1. You run anaconda. You create a user account. You boot your installed system, it boots straight to the login prompt. 2. You run anaconda. You don't create a user account. Anaconda alerts you that you shouldn't do that unless you really know what you're doing. You tell it "it's fine, I know what I'm doing". You boot your installed system, and it boots to the login prompt. How is World 1 better than World 2, exactly? They are both eons better than the world we have right now, but the point I'm driving at here is that once you think through all the scenarios, a "fixed" initial-setup is just pointless complexity and we might as well just do it in anaconda.
Comment 5 Adam Williamson 2013-05-22 01:10:58 UTC
Note that the "no user account" case is the minority case, and the amount of inconvenience to the minority case is identical in both scenarios. Whether we kill i-s or not, we really should add some hoops you have to jump through to proceed without creating a user *somewhere*. (In F18, it was in firstboot, obviously; you had to click through a warning to proceed without creating a user account). It's just a question of whether we add them to initial-setup or to anaconda.
Comment 6 Adam Williamson 2013-05-22 16:35:08 UTC
viteslav, could we have your opinion on this?
Comment 7 Vratislav Podzimek 2013-05-23 11:45:06 UTC
I think we need Initial Setup not only for OEM installations but also for addons and other screens that may appear there in future (I myself am working on one such addon). On the other hand I believe i-s should warn if no user is created in the installation nor in the i-s itself as this was the behaviour of the Firstboot. In the same time the i-s shouldn't show up if everything was set in the installation. But these are just bugs that should be fixed, not by killing the i-s nor by enforcing user creation in the installation or anything like that.
Comment 8 Adam Williamson 2013-05-23 12:50:22 UTC
Sure, after we chatted about it, I can see your point. So let's just make this into the bug for 'i-s should warn if user creation is not done'. When I get a minute, I'll file a new bug to track the work of not displaying spokes (or i-s at all) unless it's necessary. Thanks.
Comment 9 Vratislav Podzimek 2013-06-12 14:02:35 UTC
Patches posted to anaconda-patches.
Comment 10 Leslie Satenstein 2013-06-16 14:25:55 UTC
Somehow we must assume that people installing Fedora have common senses. If it is a kid on a desktop at home, he will figure something out. Have no fear about that. For an admin, he would probably do what I do. When installing and not creating a user during anaconda execution this is what I do. I create the root password as simple as possible and force it to be so. Example 1234567890 is forced, because I can remember it. When the system reboots after anaconda has done its thing, I log to root I create an administrator, I set his password, and I put him in the wheeel group. I also create a guest account and password. I then set root password to a confidential one, easy to verify from within the installed operating system. I this way, I am certain of the root password. And just before I exit root, I do two actions from the console, yum update -y and reboot. Just document the method in the release notes and thats it. No need to go further
Comment 11 Adam Williamson 2013-06-19 00:57:14 UTC
I was kind of expecting this to be resolved long before final crunch, but the patches got held up in review. Proposing as a final freeze exception: this looks pretty dumb, when we run i-s after you already did all the useful stuff it can do during installation.
Comment 12 Adam Williamson 2013-06-19 17:58:57 UTC
Discussed at 2013-06-19 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . Accepted as a freeze exception issue: firstboot used to do this, and it's a bad idea to make it too easy to get to a login screen with no user account. Can't be fixed post-release.
Comment 13 Adam Williamson 2013-06-25 19:04:05 UTC
Unfortunately this hasn't made RC1 or RC2 because a new i-s build with the fix hasn't been done since it was acked on June 19 :( Be great if we could get a new build just in case we wind up doing an RC3.
Comment 14 Vratislav Podzimek 2013-06-26 09:52:31 UTC
(In reply to Adam Williamson from comment #13) > Unfortunately this hasn't made RC1 or RC2 because a new i-s build with the > fix hasn't been done since it was acked on June 19 :( Be great if we could > get a new build just in case we wind up doing an RC3. It is not about a new build of the I-S. The patch for the I-S has been ACKed, but the patch for the Anaconda that is needed as well was NACKed.
Comment 15 marcindulak 2013-07-08 11:42:42 UTC
How this will work during unattended installations with kickstart, with "no user account", like in comment #10 ? Currently with kickstart's: firstboot --disable i'm left with a confirmation dialog waiting to be closed.
Comment 16 Adam Williamson 2013-07-09 22:47:02 UTC
My practical advice for such an install would just be to remove the initial-setup package from the deployed package set: %packages -initial-setup %end
Comment 17 marcindulak 2013-07-10 07:46:40 UTC
(In reply to Adam Williamson from comment #16) > My practical advice for such an install would just be to remove the > initial-setup package from the deployed package set: > > %packages > -initial-setup > %end I confirm this workaround works for me - no more "no user account" confirmation button to click.
Comment 18 Adam Williamson 2013-12-20 04:52:32 UTC
This is still broken in F20 :( We really need to fix it. May need to be cloned for RHEL 7 as well.
Comment 19 Vratislav Podzimek 2014-01-06 11:49:35 UTC
Will try to revive the discussion about the potential solution.
Comment 20 Edgar Hoch 2014-01-09 16:56:11 UTC
For the discussion: I want to note that having no "local user" created may be what the administrator wants to have! Regard a scenario where you have many hosts (desktops, servers) in a network (for example at university or company) which uses ldap or nis to distribute users to the hosts. Then it is ok to have only root as a local user (which will be used only for administration, mostly remote using ssh). I think, if the administrator uses kickstart and sets "firstboot --disable", then no question about the configuration should be asked at all, neither by initial-setup nor by gnome-initial-setup.
Comment 21 Adam Williamson 2014-01-09 18:25:22 UTC
This bug would not affect that path. If initial-setup is disabled it is, of course, not going to print any warnings.
Comment 22 marcindulak 2014-07-12 12:29:55 UTC
(In reply to Edgar Hoch from comment #20) > For the discussion: > > I want to note that having no "local user" created may be what the > administrator wants to have! > > Regard a scenario where you have many hosts (desktops, servers) in a network > (for example at university or company) which uses ldap or nis to distribute > users to the hosts. Then it is ok to have only root as a local user (which > will be used only for administration, mostly remote using ssh). > > I think, if the administrator uses kickstart and sets "firstboot --disable", > then no question about the configuration should be asked at all, neither by > initial-setup nor by gnome-initial-setup. The subject of this bug is something different but it's useful to state that on CentOS 7.0.1406 x86_64 in order to get the desired behaviour (fully unattended installation) one needs: 1. firstboot --disable 2. -initial-setup 3. -gnome-initial-setup This is consistent with https://ask.fedoraproject.org/en/question/33672/fedora-19-and-nis-issues-on-a-fresh-install/
Comment 23 Adam Williamson 2014-07-12 14:59:39 UTC
marcin: for the record - I noticed that during RHEL 7 testing and am told it will be less silly in 7.1 :)
Comment 24 Dimitri Maziuk 2015-05-02 15:41:13 UTC
I can confirm that in centos 7.1 (1503) it is "less silly", but gnome-inital-setup is still alive and well unfortunately. (#1144623; Insult to injury: it creates a homedir in /home that automounter doesn't like later on when you get a chance to configure it.)
Comment 25 Fedora End Of Life 2015-05-29 09:04:33 UTC
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 26 Leslie Satenstein 2015-06-07 03:55:25 UTC
If the user is allowed to enroll himself on loggin into the system on first boot, what is the guarantee that this first user must be an administrator and not a normal user? I believe that both root and administrator logons must be filled within anaconda as a safety measure. If this solution is accepted, the installation guide will have a small correction to one paragraph to remove the text about first boot.
Comment 27 Fedora End Of Life 2015-06-30 01:18:30 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.