Description of problem: Unlike Firstboot which it replaces and initial-setup which runs for non-gnome DEs Gnome-Initial-Setup fails to offer the ability to add non-root user to wheel group. Version-Release number of selected component (if applicable): 19-alpha-tc5 How reproducible: every time Steps to Reproduce: 1. 2. 3. Actual results: cannot make non-root user admin Expected results: Check Box to make non-root user an admin {wheel} group Additional info:
Actually it seems the user created by gnome-initial-setup is automatically in wheel (ie an admin user). Arguably there could be a optional to allow creating a non-admin user, but dunno if that is really useful.
Yeah, we discussed this and came across the conclusion that creating a non-admin user is not for the gnome-initial-setup case. These should probably be created by kickstart files or added manually by the administrator in gnome-control-center or similar.
Discussed at 2013-04-08 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-08/f19alpha-blocker-review-5.2013-04-08-16.01.log.txt . Regardless the actual status of this function, we don't think it's safe to twiddle with this late in freeze, so rejected as a freeze exception issue. If g-i-s is held to be working as intended, this should probably be closed, but one thing to check - is the created user not only in the 'wheel' group but also an admin so far as PolicyKit is concerned? I don't recall if PK considers users in 'wheel' to be admins or not.
We use the accountsservice API to create an "administrator" account, the same API as the control-center, so if that doesn't create a PolKit-compatible user, then that's really bad, and we have an upstream place to fix it. But see: http://cgit.freedesktop.org/polkit/tree/src/polkitbackend/50-default.rules
Oh, I don't have any indication that it doesn't work, it just occurred to me as something to check before closing the bug. Sounds like we can assume it's okay. I don't see a reason to leave this open.
Do I follow the discussion correctly. Gnome Initial Setup leads the admin to believe he has created a non-root account {based on the fact there is no indication on the gui that account being created is an admin account} and then creates an admin account and gives you no other choice.
"Gnome Initial Setup leads the admin to believe he has created a non-root account {based on the fact there is no indication on the gui that account being created is an admin account}" That seems disingenuous and unsupported. It does not lead the admin to believe anything in particular because it does not state either way. Perhaps it could state that the user created will be an admin user, but I don't see any support for the suggestion that it leads one to believe otherwise.
I am basing the statement on my experience with Fedora. When firstboot ran in older versions of fedora it created a non-root user and you had to manipulate the setup to manually add the user to group wheel manually. Then if memory serves around f16 or f17 we had the option to add the user to group wheel at creation during firstboot. Making it plain the user was or was not an admin. F19-Gnome-Initial-Setup definitely leaves the state of the user created in doubt if all you have to go by is the visual feedback provided. This is not what one would expect from a first class piece of software. And is probably best addressed by the upstream as gnome is responsible for g-i-s not fedora if I am not mistaken.
g-i-s is not about an administrator creating an account for somebody else. It is about you setting up your own (first, and only) account on your freshly-installed system.
Or the third user on my freshly installed system since g-i-s ignores the user anaconda created. realistically g-i-s needs to handle both the fresh system install and the existing system adding gnome cases in my humble old school opinion.
(In reply to comment #10) > Or the third user on my freshly installed system since g-i-s ignores the > user anaconda created. See bug 929289#c13 - that will be fixed in gnome 3.8.1 which should be in F19 Beta. How about changing this bug to: "g-i-s should mention that the created account will be an admin account"?
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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.
Still valid for Rawhide, though it might make more sense to file upstream.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.
I don't think we have any plans to indicate specially that the first user is an administrator. It just is. This might have been surprising six years ago, but nowadays it's to be expected.