Call for Bikeshedding: remote auth at install time

Simo Sorce simo at redhat.com
Wed Jun 5 15:38:22 UTC 2013


On Wed, 2013-06-05 at 16:55 +0200, Stef Walter wrote:
> On 04.06.2013 15:34, Simo Sorce wrote:
> > On Tue, 2013-06-04 at 09:02 -0400, Stephen Gallagher wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 06/03/2013 09:07 PM, Adam Williamson wrote:
> >>> We all know what devel@ does best, so let's fire up the power of
> >>> the bikeshedding machine :)
> >>>
> >>> We had https://bugzilla.redhat.com/show_bug.cgi?id=965883 on the
> >>> list of release blocker candidates that we evaluated at the blocker
> >>> review meeting this morning. Attendance at blocker reviews is
> >>> pretty spotty these days (please, people, come out and feel in a
> >>> position of ABSOLUTE POWER), and no-one present felt like they were
> >>> a huge expert on typical remote authentication use cases, so we
> >>> really didn't feel qualified to make a call on this one.
> >>>
> >>> As things stand, in Fedora 19, it's basically impossible to
> >>> configure remote authentication from the install/firstboot process.
> >>> If you want to use remote auth, you'd have to create a local user
> >>> first and then do it using whatever tools are available. anaconda /
> >>> initial-setup has a button for "Use network login..." on its 'user
> >>> creation' spoke which ought to be where you configure remote auth,
> >>> but right now it does precisely nothing at all.
> >>>
> >>> Whether this is a blocker or not comes down to a judgement call,
> >>> because it hinges on whether this is a significant inconvenience
> >>> for a large enough number of users. So we need to know from people
> >>> who use Fedora in remote auth environments whether it's a big
> >>> problem not to be able to set it up at install / firstboot time, or
> >>> whether you'd be okay with creating a local user to get through
> >>> initial-setup and then configuring remote auth from that local
> >>> account.
> >>>
> >>
> >> How did that happen? Last I had heard, Anaconda was supposed to be
> >> farming out to RealmD to do this. We should have no need to create a
> >> local user at all. CCing the RealmD maintainer for comment.
> > 
> > Realmd is a good tool, but works only with Windows Ad or FreeIPA.
> > It is useless to configure against a classic directory and/or Kerberos
> > server or NIS or things like that.
> 
> Agreed that is the case right now.
> 
> But it's a goal to make it grow into those relevant use cases in that
> area so that we can have a non-Red-Hat-specific tool and API for
> accomplishing these things.
> 
> On the other hand neither authconfig or realmd will ever provide all a
> GUI for the possible ways (many broken) ways you can possibly configure
> network authentication.
> 
> > Anaconda used to have authconfig integration, was it yanked on rewrite ?
> 
> Anaconda did not have the GTK dialog. firstboot was the one that had it.
> And it's really broken for most use cases. It doesn't install necessary
> software or anything like that. So one really needs to know ahead of
> time all the dependencies of the network authentication you plan to use,
> and choose those in the installer.
> 
> It was part of the plan to have a GUI for realmd be part of anaconda.
> But the merge of the basic anaconda kickstart patches, took so so long
> to merge (they've been ready since October) that the GUI bits were not
> done in time.
> 
> See 'Contingency Plan' here:
> 
> https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration#Contingency_Plan

So the endgame here is that there will be no remote authentication
option in anaconda *nor* in firstboot. Can we get a button to skip g-i-s
mandatory user creation then ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list