Bug 965883 - "Use network login..." button in user creation spoke entirely broken
"Use network login..." button in user creation spoke entirely broken
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
x86_64 All
unspecified Severity urgent
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
RejectedBlocker AcceptedFreezeException
:
Depends On:
Blocks: F19-accepted/F19FinalFreezeException
  Show dependency treegraph
 
Reported: 2013-05-21 18:01 EDT by Adam Williamson
Modified: 2013-06-11 23:37 EDT (History)
10 users (show)

See Also:
Fixed In Version: anaconda-19.30.3-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-11 23:37:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
me: fedora_requires_release_note+


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2013-05-21 18:01:11 EDT
So far as I can tell, clicking "Use network login..." in the user creation spoke of anaconda or initial-setup in F19 Beta RC2 does precisely nothing at all. Well, the button click animation happens. That's about it. No window opens. Nothing is appended to any of the logs that I can see.

This is obviously a pretty significant issue as it'll prevent network auth configuration on non-GNOME installs entirely (GNOME uses gnome-initial-setup, which gives us another bite at the cherry, but I don't know if its network auth code actually works either, yet).
Comment 1 Adam Williamson 2013-05-29 15:46:24 EDT
Proposing as a final blocker:

https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

"A system installed with a graphical package set must boot to the 'firstboot' utility on the first boot after installation. The firstboot utility must be able to create a working user account."

OK, we (still) need to tweak that criterion, but basically, we require that account creation works at some point before you get to the login screen. This is effectively broken for the KDE path (GNOME path is complicated as g-i-s gives us a second bite at the cherry; KDE path is clearer since it uses anaconda then initial-setup) with any non-local user account at present. It's arguable whether that's a wide enough impact to block release for, but we should at least discuss it. And it should clearly be an FE bug, IMHO.
Comment 2 Adam Williamson 2013-06-03 12:39:59 EDT
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . This is definitely accepted as a freeze exception issue, but we did not feel that we had the necessary experience at the meeting to make a call as to whether remote auth config ought to be release critical or not - we just don't know how important it is to those who use remote auth that it be configurable interactively before first login (or whether they'd be fine with creating a local account first and then configuring remote auth from there). Please, if you have input on whether this should be a blocker issue, post a comment.
Comment 3 Adam Williamson 2013-06-05 12:57:58 EDT
Discussed at 2013-06-05 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-05/f19final-blocker-review-3.2013-06-05-16.05.log.txt .  Based on the feedback received on devel@ so far we're rejecting this as a blocker: overall the impression we're getting is that people who use remote auth already didn't find firstboot reliable for it and are already used to working around getting it set up outside of anaconda/'firstboot' stages.

We are accepted the bug as a freeze exception issue, though. Obviously if this can be 'fixed' - as in, useful remote auth code put in in time for Final - that would be good. The other option, if there's no chance of any usable remote auth setup code going in before Final, would be to suppress the button so it doesn't confuse/disappoint people.
Comment 4 Brian Lane 2013-06-05 18:23:19 EDT
May as well just remove it for now.
Comment 5 Fedora Update System 2013-06-06 14:37:06 EDT
anaconda-19.30.3-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/anaconda-19.30.3-1.fc19
Comment 6 Fedora Update System 2013-06-07 11:41:37 EDT
Package anaconda-19.30.3-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-19.30.3-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10283/anaconda-19.30.3-1.fc19
then log in and leave karma (feedback).
Comment 7 Adam Williamson 2013-06-07 20:16:56 EDT
For release notes: we should note that there's no remote auth configuration in the anaconda/i-s path and only FreeIPA and AD support in the anaconda/g-i-s path; all other cases require kickstart (in %post, I guess) or post-install configuration.
Comment 8 Pete Travis 2013-06-09 12:55:16 EDT
I've added a Release Note for this. Thanks for flagging, Adam!
Comment 9 Fedora Update System 2013-06-11 23:37:59 EDT
anaconda-19.30.3-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.