Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)

[Simo Sorce]

On Tue, 2013-05-21 at 12:30 -0700, Adam Williamson wrote:
> On Tue, 2013-05-21 at 15:03 -0400, Matthew Miller wrote:
> 
> > > gnome-initial-setup would still be a different case, as GNOME apparently
> > > really wants to force the creation of a non-root account. So g-i-s will
> > 
> > That seems fine to me; systems where you don't want a user account shouldn't
> > be desktop systems, and it seems compatible with what I suggest above: if
> > they have a root password don't pop up anything about the user account, and
> > if they're in the common desktop case we know they'll get the lecture later.
> 
> So, as I said, branching this out, because it's a complex question I
> wanted to avoid in the primary thread.
> 
> At this point you're getting into actually *changing* the desired
> behaviour from what it was historically, which is a much more complex
> question.
> 
> To re-iterate, the behaviour of the "install and first boot" stages of
> F18 and earlier was this:
> 
> * On non-graphical installs, require the creation of a root password,
> don't do anything about user account creation
> 
> * On graphical installs, require the creation of a root password,
> encourage the creation of a user account but allow it to be skipped by a
> determined user
> 
> My proposed behaviour for F19's anaconda and initial-setup - see other
> thread - boils down to:
> 
> * On both graphical and non-graphical installs, require the creation of
> a root password *or* an admin user account. If a root password is set,
> encourage the creation of a user account but allow it to be skipped by a
> determined user
> 
> This seems to be to be effectively very close to F18 and earlier
> behaviour, while adding the flexibility of having an admin user account
> with an inaccessible root account, which is something the anaconda devs
> really wanted to add.
> 
> Now we're considering the behaviour of the anaconda / g-i-s combination
> in F19, which is significantly *different* from pre-F19 behaviour.
> Instead of encouraging user creation, it *requires* user creation.
> 
> In my original mail I intentionally kinda handwaved this and said 'GNOME
> can carry on doing whatever it wants', in the interests of keeping the
> thread simple. But we can broaden out in this thread and consider all
> the possible behaviours.
> 
> If we start going down the 'mandate user creation' path, there's a few
> ways of doing it. We _could_ go with your approach (and the current
> g-i-s approach) of mandating user creation only for graphical installs.
> The main drawback of this approach is it requires either bigger change
> to anaconda, or the complexity of a 'firstboot' stage, because you have
> to distinguish between graphical and non-graphical installs: either
> anaconda has to be able to do that (which at present it doesn't) or we
> have to do it at the 'firstboot' point. We _can_ - and indeed do - do it
> at the firstboot point, but it's a level of complexity that isn't needed
> in other possible approaches.
> 
> The other 'mandate user creation' option would be simply to do it in
> (interactive) anaconda, and tell people who want to do installs without
> a user account to use a kickstart or lump it. This has the advantage of
> being one of the simplest possible approaches: all we'd have to do is
> make user creation mandatory in anaconda and we could ditch
> initial-setup and the pre-GDM bit of gnome-initial-setup. The
> disadvantage of this approach, obviously, is it makes it harder for
> those who have some kind of valid reason for doing an install with no
> user account. Frankly, I quite like this option, the advantage of
> simplicity is attractive. But I think it might be harder to get people
> behind, cos people sure do love their choice!

I have a FreeIPA server at home, I have no reason to create a user
account. Why should you force me ?

> The other possible alternative behaviour, of course, is to go precisely
> the other way, and not try and force the user into doing anything at
> all. Again in this case it would make sense to ditch the 'firstboot'
> stage. We'd simply leave anaconda alone, and kill initial-setup (and the
> pre-GDM bit of gnome-initial-setup). This is again a nice and simple
> approach. Its disadvantage is that it makes it nice and simple for a
> 'regular' user to shoot herself in the foot. Experienced users can be
> assumed to know the consequences of not creating a user account, sure.
> But for the newbie who didn't do it and then pitched up at a GDM prompt
> with no users, things would kind of suck. I am not a fan of this option.

What's wrong with giving an option in anaconda and letting the user skip
it ?

> Anyhow, that's how I see all the possible paths here - like I said, I
> really did think through all of them :)
> 
> On balance I think my current proposal is the best. It combines a good
> degree of simplicity, safety for people who don't know what they're
> doing, and flexibility for those who really want to not have a user
> account. And it is sufficiently close to the behaviour of F18 and
> earlier not to surprise or confuse people. The 'simply mandate user
> creation in anaconda and tell those who don't want a user account to use
> a kickstart or delete it after install' option would be my second
> choice, but as I said, I think it would be more controversial.

I never use kickstarts at home, it would be a pretty hostile option.
Sure I can simply create a user and then delete it as the first thing,
but why should that be mandated ?

> It's very likely that the behaviour will differ somewhat between GNOME
> and all the other desktops for F19. This kind of inconsistency could be
> viewed as a bit of a pity, but I don't think it's a huge practical
> problem, and it may be that we can't get GNOME and the distro as a whole
> to agree on whether user creation should be mandatory.

It's unclear to me why Gnome should mandate user creation at all, since
when Gnome is the OS Identity Management system/enforcer ?

Simo.

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