4:25 p.m.
So I'm writing a blog post on this topic ATM, and that really kinda
brought home how messy this design is at present.
Quick refresher for anyone who hasn't looked at it much yet: in F19,
anaconda can create user accounts, and 'firstboot' has been replaced
with two alternative tools, 'initial-setup' which is used in any
graphical install other than a GNOME install and just replicates
anaconda's 'root password', 'user creation' and 'date/time'
spokes, and
gnome-initial-setup, which is used in GNOME installs and is its own
whole thing that can also do user creation.
I mapped out all the potential paths through this maze, and got this -
16(!!!) paths:
anaconda: root pw, no user - g-i-s: admin user
i-s: admin user
i-s: regular user
console: root
anaconda: root pw, regular user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: regular user + root
anaconda: root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
anaconda: no root pw, admin user - g-i-s: user mode
i-s: edit root pw or user
i-s: leave intact
console: admin user + root
Note the paths marked "i-s: edit root pw or user" are pretty messy and
open ended in themselves - initial-setup always runs if installed, no
matter what you set in anaconda, and at least theoretically lets you
change the settings you picked in anaconda.
This is...kinda nuts, and a QA nightmare. Can we maybe take a step back
and look if there's a more sensible way to design this, ideally with the
GNOME and anaconda teams working together?
If we imagined initial-setup didn't exist and we only had the
anaconda/g-i-s case, the proliferation of trees at least looks rather
better, because g-i-s can't set the root password or change what
anaconda did; if you create a user account during anaconda, g-i-s runs
only after you log in with that user account and just lets you configure
various settings for that user account, it doesn't let you create other
user accounts (this is what I've labelled as 'g-i-s: user mode' in the
tree). So the anaconda/g-i-s paths are broadly sane already. It's the
anaconda/i-s paths that are really complicating things. Still, it might
help to just take a step back and decide if we really need all this
flexibility. We could, for instance, simply force user creation during
anaconda, dump initial-setup entirely, and use only
gnome-initial-setup's "user mode" (desktops other than GNOME could
implement something like this "user mode" if they wanted to, or not).
That would be a hell of a lot simpler to code, test, support and
explain, with the minor(?) drawback that you couldn't install without a
user account and then create it on first boot any more. Xkcd Law tells
us that someone will not be happy about this:
https://xkcd.com/1172/
but still, it seems to be worth considering. Alternatively, we could
make i-s behave a lot more like g-i-s: it could dump its 'root password'
and 'date/time' spokes, and only run at all, and only to allow user
creation, if you didn't create a user during anaconda.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:44 p.m.
On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
but still, it seems to be worth considering. Alternatively, we could
make i-s behave a lot more like g-i-s: it could dump its 'root password'
and 'date/time' spokes, and only run at all, and only to allow user
creation, if you didn't create a user during anaconda.
Thinking about it more, this really seems to be the way to go. Forcing
user creation in anaconda is a problem for someone who wants to do a
minimal install with no user account. Doing the above would reduce the
paths to something manageable without compromising any existing use
cases.
So, vpodzime, msivak: can we lobotomize initial-setup? Can we jettison
the root password and time/date spokes, and make it only do user
creation, and only run it if a user account was not created during
anaconda? That seems to be the path forward to sanity, in my mind
anyway.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:51 p.m.
On Fri, 2013-05-17 at 14:44 -0700, Adam Williamson wrote:
On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> but still, it seems to be worth considering. Alternatively, we could
> make i-s behave a lot more like g-i-s: it could dump its 'root password'
> and 'date/time' spokes, and only run at all, and only to allow user
> creation, if you didn't create a user during anaconda.
Thinking about it more, this really seems to be the way to go. Forcing
user creation in anaconda is a problem for someone who wants to do a
minimal install with no user account. Doing the above would reduce the
paths to something manageable without compromising any existing use
cases.
So, vpodzime, msivak: can we lobotomize initial-setup? Can we jettison
the root password and time/date spokes, and make it only do user
creation, and only run it if a user account was not created during
anaconda? That seems to be the path forward to sanity, in my mind
anyway.
Heck, we could even then use initial-setup on GNOME installs too, and
only use gnome-initial-setup's "user mode". That would give us a really
consistent model: you set up root pw and/or user account in anaconda or
initial-setup, and then desktops can have a tool like
gnome-initial-setup which runs on the first login for a new user, to set
up the user's environment. It removes all the functionality overlap
between different tools and gives us a clear and straightforward model
for testing and development, that is desktop agnostic.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:46 p.m.
On Fri, 2013-05-17 at 14:51 -0700, Adam Williamson wrote:
On Fri, 2013-05-17 at 14:44 -0700, Adam Williamson wrote:
> On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
>
> > but still, it seems to be worth considering. Alternatively, we could
> > make i-s behave a lot more like g-i-s: it could dump its 'root
password'
> > and 'date/time' spokes, and only run at all, and only to allow user
> > creation, if you didn't create a user during anaconda.
>
> Thinking about it more, this really seems to be the way to go. Forcing
> user creation in anaconda is a problem for someone who wants to do a
> minimal install with no user account. Doing the above would reduce the
> paths to something manageable without compromising any existing use
> cases.
>
> So, vpodzime, msivak: can we lobotomize initial-setup? Can we jettison
> the root password and time/date spokes, and make it only do user
> creation, and only run it if a user account was not created during
> anaconda? That seems to be the path forward to sanity, in my mind
> anyway.
Heck, we could even then use initial-setup on GNOME installs too, and
only use gnome-initial-setup's "user mode". That would give us a really
consistent model: you set up root pw and/or user account in anaconda or
initial-setup, and then desktops can have a tool like
gnome-initial-setup which runs on the first login for a new user, to set
up the user's environment. It removes all the functionality overlap
between different tools and gives us a clear and straightforward model
for testing and development, that is desktop agnostic.
That would give us the worst of all worlds - you'd have to stop and
answer questions 3 times (anaconda, initial-setup and
gnome-initial-setup) during the installation.
For a desktop installation, we (speaking from the GNOME perspective)
really want the installer to be very simple, and ask as few questions as
possible. This vision is explained in more detail here:
https://live.gnome.org/GnomeOS/Design/Whiteboards/Installer
Anaconda is pretty far from that vision, and we've made
gnome-initial-setup deal with the reality of the situation by not
showing steps if we know that the have already been asked by anaconda.
I can understand that you want to make things easier for yourself from a
testing perspective, but you are really just dealing with a symptom
here. The core problem is the we're trying to use a single tool
(anaconda) to deal with many different use cases. As a consequence,
anaconda has to offer many optional tasks which you can choose to ignore
or not, and you can choose to act on them before or after the
installation is done. Your qa nightmare is built right into the design
of the installer - lots of forking paths through those spokes.
1:07 p.m.
On Mon, 2013-05-20 at 13:46 -0400, Matthias Clasen wrote:
On Fri, 2013-05-17 at 14:51 -0700, Adam Williamson wrote:
> On Fri, 2013-05-17 at 14:44 -0700, Adam Williamson wrote:
> > On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> >
> > > but still, it seems to be worth considering. Alternatively, we could
> > > make i-s behave a lot more like g-i-s: it could dump its 'root
password'
> > > and 'date/time' spokes, and only run at all, and only to allow
user
> > > creation, if you didn't create a user during anaconda.
> >
> > Thinking about it more, this really seems to be the way to go. Forcing
> > user creation in anaconda is a problem for someone who wants to do a
> > minimal install with no user account. Doing the above would reduce the
> > paths to something manageable without compromising any existing use
> > cases.
> >
> > So, vpodzime, msivak: can we lobotomize initial-setup? Can we jettison
> > the root password and time/date spokes, and make it only do user
> > creation, and only run it if a user account was not created during
> > anaconda? That seems to be the path forward to sanity, in my mind
> > anyway.
>
> Heck, we could even then use initial-setup on GNOME installs too, and
> only use gnome-initial-setup's "user mode". That would give us a
really
> consistent model: you set up root pw and/or user account in anaconda or
> initial-setup, and then desktops can have a tool like
> gnome-initial-setup which runs on the first login for a new user, to set
> up the user's environment. It removes all the functionality overlap
> between different tools and gives us a clear and straightforward model
> for testing and development, that is desktop agnostic.
That would give us the worst of all worlds - you'd have to stop and
answer questions 3 times (anaconda, initial-setup and
gnome-initial-setup) during the installation.
Only if you didn't create a user in anaconda; if you did, i-s would be
skipped and you'd only see post-user-creation g-i-s. In practice, now
anaconda offers user creation, I suspect most people will just do it
there. And even if the case where you see all three, they wouldn't
really be overlapping each other, each would be doing something
different, so I still don't think it'd be horrible.
For a desktop installation, we (speaking from the GNOME perspective)
really want the installer to be very simple, and ask as few questions as
possible. This vision is explained in more detail here:
https://live.gnome.org/GnomeOS/Design/Whiteboards/Installer
Anaconda is pretty far from that vision, and we've made
gnome-initial-setup deal with the reality of the situation by not
showing steps if we know that the have already been asked by anaconda.
Yes, and as I mentioned earlier in this thread, the *main* improvement
we can make here is to have i-s do the same thing.
Trying not to sound too snarky, but GNOME's vision of the ideal
installer is fine and good, but it is not a practical vision for
Fedora's installer. We have always had a very capable and featureful
installer and we really need to have one. We can't lobotomize anaconda
into a Ubiquity clone, however 'clean' it would render the design.
(Believe me, the anaconda team would love to do so if it was practical,
they don't _really_ enjoy the week long design whiteboarding sessions).
I can understand that you want to make things easier for yourself
from a
testing perspective, but you are really just dealing with a symptom
here. The core problem is the we're trying to use a single tool
(anaconda) to deal with many different use cases. As a consequence,
anaconda has to offer many optional tasks which you can choose to ignore
or not, and you can choose to act on them before or after the
installation is done. Your qa nightmare is built right into the design
of the installer - lots of forking paths through those spokes.
I don't think so, the main issue is really just i-s's replication of
anaconda functionality when it is unnecessary. I still think the design
where we use i-s for any post-install, pre-desktop tasks that are
necessary and then the desktops handle post-login setup would be the
most elegant from a distro perspective, but I'm not wedded to it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:23 a.m.
Hi,
Just to clarify things.
Anaconda currently requires root password OR user with administrator privileges (wheel
group). So if you set root password in Anaconda, initial-setup will start, but can be
dismissed immediately.
It might be good idea to add some explanation text to initial-setup together with the
hiding feature (some configuration is hidden because it was set during the first install
phase..) to avoid user confusion.
--
Martin Sivák
msivak(a)redhat.com
Red Hat Czech
RHEV-M SLA / Brno, CZ
11:23 a.m.
On Tue, 2013-05-21 at 05:23 -0400, Martin Sivak wrote:
Hi,
Just to clarify things.
Anaconda currently requires root password OR user with administrator
privileges (wheel group). So if you set root password in Anaconda,
initial-setup will start, but can be dismissed immediately.
I meant to check that but never got around to it. That in itself is a
bug: it ought to require user creation. We don't want to be encouraging
desktop login as root.
It might be good idea to add some explanation text to initial-setup
together with the hiding feature (some configuration is hidden because
it was set during the first install phase..) to avoid user confusion.
I don't think that's really necessary at least with the current layout.
I think the current state is far more confusing, because it makes you
scratch your head and say 'why is it showing all this stuff I just did'?
For all normal cases, once the 'hiding' stuff is implemented, there will
only be two possibilities for i-s: either it runs with a single spoke,
user creation, or it does not run at all. I'm not sure we need
explanatory text for that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:30 a.m.
On Fri, May 17, 2013 at 02:44:25PM -0700, Adam Williamson wrote:
Thinking about it more, this really seems to be the way to go.
Forcing
user creation in anaconda is a problem for someone who wants to do a
minimal install with no user account. Doing the above would reduce the
paths to something manageable without compromising any existing use
cases.
Who'd want to do a minimal install and not create an account?
(And wouldn't be doing that using a kickstart or another specialized
install method?)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
12:15 p.m.
On Sat, 2013-05-18 at 09:30 +0100, Richard W.M. Jones wrote:
On Fri, May 17, 2013 at 02:44:25PM -0700, Adam Williamson wrote:
> Thinking about it more, this really seems to be the way to go. Forcing
> user creation in anaconda is a problem for someone who wants to do a
> minimal install with no user account. Doing the above would reduce the
> paths to something manageable without compromising any existing use
> cases.
Who'd want to do a minimal install and not create an account?
(And wouldn't be doing that using a kickstart or another specialized
install method?)
Prior to F19 it was what happened by default: there was no user creation
in anaconda, and no CLI firstboot in Fedora (for a while there was one
but it didn't offer user creation); so on a minimal install you only had
to set a root password and you wound up with a system with just the root
user.
As I mentioned in my initial post, the Law of Xkcd informs us that if we
change this so that user creation is mandatory, it will *inevitably*
piss someone off. Having said that, I personally wouldn't mind doing it
and facing down the inevitable flamewar, but hey. Cutting i-s down to
size seems a more conservative and almost equally beneficial option.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:22 a.m.
On Sat, May 18, 2013 at 10:15:54AM -0700, Adam Williamson wrote:
On Sat, 2013-05-18 at 09:30 +0100, Richard W.M. Jones wrote:
> On Fri, May 17, 2013 at 02:44:25PM -0700, Adam Williamson wrote:
> > Thinking about it more, this really seems to be the way to go. Forcing
> > user creation in anaconda is a problem for someone who wants to do a
> > minimal install with no user account. Doing the above would reduce the
> > paths to something manageable without compromising any existing use
> > cases.
>
> Who'd want to do a minimal install and not create an account?
> (And wouldn't be doing that using a kickstart or another specialized
> install method?)
Prior to F19 it was what happened by default: there was no user creation
in anaconda, and no CLI firstboot in Fedora (for a while there was one
but it didn't offer user creation); so on a minimal install you only had
to set a root password and you wound up with a system with just the root
user.
I know, and it was a pain to remember the right groupadd/useradd
commands!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
9:26 a.m.
New subject: anaconda / initial-setup / gnome-initial-setup: can we do this better?
Speaking of initial user setup...it bugs me that I'm forced to create a group. If I
try to pick an existing group, the Fedora installer complains that the group already
exists, which is a strange error to report -- no duh it already exists. (I just want my
user account to be part of the "users" group; I don't need my own special
group account.) I always have to delete the group afterwards, then do a system-wide
find/chgrp.
10:15 a.m.
On Sunday 19 May 2013 15:22:12 Richard W.M. Jones wrote:
On Sat, May 18, 2013 at 10:15:54AM -0700, Adam Williamson wrote:
> ... so on a minimal install you only had to set a root password and
> you wound up with a system with just the root user.
I know, and it was a pain to remember the right groupadd/useradd
commands!
Huh? What's wrong with a simple "useradd foobar"?
On Fedora/RHEL/Centos the defaults for useradd in /etc/login.defs are
very sane, so you don't need extra commands:
- Create private group (USERGROUPS_ENAB) -- yes
- Create home directory (CREATE_HOME) -- yes
So all that is left is to "passwd foobar", but that is routine to any Linux user
even
during normal life-cycle.
Bye,
--
Oron Peled Voice: +972-4-8228492
oron(a)actcom.co.il http://users.actcom.co.il/~oron
"write your own operating system. It has worked every time for me"
-- Linus Thorvalds
8:43 a.m.
New subject: anaconda / initial-setup / gnome-initial-setup: can we do this better?
From: Adam Williamson <awilliam(a)redhat.com>
As I mentioned in my initial post, the Law of Xkcd informs us that if we
change this so that user creation is mandatory, it will *inevitably*
piss someone off.
Me for example, although I'd be more annoyed than pissed. ;-)
Both at home and work I have all user accounts centralized in LDAP. I
don't need or want anaconda or some other initial setup tool to force
account creation upon me. Nor the setup of using LDAP/Kerberos/etc. for
identification/authorization. That's one of puppet's jobs here and having
to create a dummy account to proceed past some mandatory setup is
irritating. I've raised this concern once before already. I don't mind
hitting a skip button -- I certainly don't want to make it hard for others
to set up their accounts manually if that's their cup o' tea.
--
John Florian
3:04 a.m.
----- Original Message -----
On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> but still, it seems to be worth considering. Alternatively, we could
> make i-s behave a lot more like g-i-s: it could dump its 'root password'
> and 'date/time' spokes, and only run at all, and only to allow user
> creation, if you didn't create a user during anaconda.
Thinking about it more, this really seems to be the way to go. Forcing
user creation in anaconda is a problem for someone who wants to do a
minimal install with no user account. Doing the above would reduce the
paths to something manageable without compromising any existing use
cases.
Well,
the main reason why we still have i-s while it's possible to do these
setup tasks in Anaconda itself are OEM installations. And I'm pretty
sure we don't have many ;-) OEM installations.
I talked to vpodzime last week about the possibilities - two features
that are still not implemented are for EULA/license and Welcome screen.
Historically it was in firstboot as far as I know, is it the right place?
I'd say no - Anaconda is the first UI you see and with possibility to
finish all steps in one tool, it's non sense. For OEM again - it's different.
So I agree with - putting as much functionality into Anaconda - licence,
welcome screen, user creation (at least recommend the creation in the
installer) and then there would be no reason to run i-s (unless user
is not created) and system-wide part of g-i-s.
Another reason why I'd prefer this solution are neverending problems with
firstboot/i-s theming under KDE.
So, vpodzime, msivak: can we lobotomize initial-setup? Can we
jettison
the root password and time/date spokes, and make it only do user
creation, and only run it if a user account was not created during
anaconda? That seems to be the path forward to sanity, in my mind
anyway.
+1, I think Vratislav will be on board too after our latest
conversation ;-).
Jaroslav
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:07 a.m.
Hi,
a quick note before I start: I am no longer maintainer of initial-setup. But since I
started it I will answer some of the questions.
the main reason why we still have i-s while it's possible to do
these
setup tasks in Anaconda itself are OEM installations. And I'm pretty
sure we don't have many ;-) OEM installations.
We (Fedora) probably don't, but we need this functionality for other products as well.
Plus there are some (enterprise..) hardware configurations that need special treatment
before the first login.
So I agree with - putting as much functionality into Anaconda -
licence,
welcome screen, user creation (at least recommend the creation in the
installer) and then there would be no reason to run i-s (unless user
is not created) and system-wide part of g-i-s.
It was actually intended to behave this way from the beginning. All the screens are shared
with Anaconda (and all we have right now live as part of Anaconda source code).
The hide/skip functionality is missing, but there is a proof of concept patch that hides
all already configured screens from initial-setup
(http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/commit/?h=msi...).
Another reason why I'd prefer this solution are neverending
problems with
firstboot/i-s theming under KDE.
No theming, initial-setup is the last step of installation and so should be considered DE
agnostic. For this reason it also looks the same as the installer.
> So, vpodzime, msivak: can we lobotomize initial-setup?
We do not have to, initial-setup is just an empty shell that can execute Anaconda screens
(either core screens or plugins, but the API is Anaconda based).
Best regards
--
Martin Sivák
msivak(a)redhat.com
Red Hat Czech
RHEV-M SLA / Brno, CZ
----- Original Message -----
> ----- Original Message -----
> > On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> >
> > > but still, it seems to be worth considering. Alternatively, we could
> > > make i-s behave a lot more like g-i-s: it could dump its 'root
password'
> > > and 'date/time' spokes, and only run at all, and only to allow
user
> > > creation, if you didn't create a user during anaconda.
> >
> > Thinking about it more, this really seems to be the way to go. Forcing
> > user creation in anaconda is a problem for someone who wants to do a
> > minimal install with no user account. Doing the above would reduce the
> > paths to something manageable without compromising any existing use
> > cases.
>
> Well,
the main reason why we still have i-s while it's possible to do
these
setup tasks in Anaconda itself are OEM installations. And I'm pretty
sure we don't have many ;-) OEM installations.
>
> I talked to vpodzime last week about the possibilities - two features
> that are still not implemented are for EULA/license and Welcome screen.
> Historically it was in firstboot as far as I know, is it the right place?
> I'd say no - Anaconda is the first UI you see and with possibility to
> finish all steps in one tool, it's non sense. For OEM again - it's
different.
>
So I agree with - putting as much functionality into Anaconda -
licence,
welcome screen, user creation (at least recommend the creation in the
installer) and then there would be no reason to run i-s (unless user
is not created) and system-wide part of g-i-s.
>
Another reason why I'd prefer this solution are neverending
problems with
firstboot/i-s theming under KDE.
>
> > So, vpodzime, msivak: can we lobotomize initial-setup? Can we jettison
> > the root password and time/date spokes, and make it only do user
> > creation, and only run it if a user account was not created during
> > anaconda? That seems to be the path forward to sanity, in my mind
> > anyway.
>
> +1, I think Vratislav will be on board too after our latest
> conversation ;-).
>
> Jaroslav
>
> > --
> > Adam Williamson
> > Fedora QA Community Monkey
> > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> > http://www.happyassassin.net
> >
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
11:41 a.m.
On Mon, 2013-05-20 at 05:07 -0400, Martin Sivak wrote:
It was actually intended to behave this way from the beginning. All
the screens are shared with Anaconda (and all we have right now live
as part of Anaconda source code).
The hide/skip functionality is missing, but there is a proof of
concept patch that hides all already configured screens from
initial-setup
(http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/commit/?h=msi...).
We do not have to, initial-setup is just an empty shell that can
execute Anaconda screens (either core screens or plugins, but the API
is Anaconda based).
Great. It's probably a bit late for Beta, but it would be awesome if we
could get it to behave as intended for final: hide unnecessary functions
and don't run unless needed (so in practice it'd only ever run to show
the user creation spoke). I guess that leaves the 'welcome / EULA'
question open - my preference would be just to ditch that at least for
non-OEM installs unless there's some kind of legal requirement for it (I
don't think there is)...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:55 p.m.
On Mon, 2013-05-20 at 09:41 -0700, Adam Williamson wrote:
Great. It's probably a bit late for Beta, but it would be awesome
if we
could get it to behave as intended for final: hide unnecessary functions
and don't run unless needed (so in practice it'd only ever run to show
the user creation spoke). I guess that leaves the 'welcome / EULA'
question open - my preference would be just to ditch that at least for
non-OEM installs unless there's some kind of legal requirement for it (I
don't think there is)...
gnome-initial-setup will display eulas, if you put a text file
into /usr/share/gnome-initial-setup/eulas. We could change that location
if necessary.
12:31 p.m.
On Mon, 2013-05-20 at 09:41 -0700, Adam Williamson wrote:
On Mon, 2013-05-20 at 05:07 -0400, Martin Sivak wrote:
> It was actually intended to behave this way from the beginning. All
> the screens are shared with Anaconda (and all we have right now live
> as part of Anaconda source code).
>
> The hide/skip functionality is missing, but there is a proof of
> concept patch that hides all already configured screens from
> initial-setup
>
(http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/commit/?h=msi...).
> We do not have to, initial-setup is just an empty shell that can
> execute Anaconda screens (either core screens or plugins, but the API
> is Anaconda based).
Great. It's probably a bit late for Beta, but it would be awesome if we
could get it to behave as intended for final: hide unnecessary functions
and don't run unless needed (so in practice it'd only ever run to show
the user creation spoke). I guess that leaves the 'welcome / EULA'
question open - my preference would be just to ditch that at least for
non-OEM installs unless there's some kind of legal requirement for it (I
don't think there is)...
So I turned https://bugzilla.redhat.com/show_bug.cgi?id=963935 into the
bug for this. I can't quite see a way to nominate it as a Final blocker
currently, but we really _really_ ought to do this for Final.
In writing the bug, it did occur to me that simply 'show spokes that
weren't completed in anaconda' may still not be good enough behaviour.
What if an admin user account was created in anaconda, obviating the
need for a root password? Does i-s still run and show the "root
password" spoke? I don't think that would be a good idea.
As I wrote in the bug, it still seems to me that i-s should simply never
ever show the date/time or root password spokes, outside of the 'OEM'
case where we assume that basically no configuration was performed at
install time.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:50 p.m.
On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
So I'm writing a blog post on this topic ATM, and that really
kinda
brought home how messy this design is at present.
So! I've been poking through the logic of this for the last few days,
still, and with some further testing of exactly what g-i-s and i-s
actually do, and what anaconda and firstboot did in previous releases, I
have an even simpler proposal:
Make anaconda warn if you don't create a user, and nuke initial-setup
for non-OEM installs.
Here is how F18 behaved:
* anaconda only let you create a root password, no user creation
* firstboot ran on graphical installs, not text
* firstboot would let you skip the user creation step, with a warning
So here are all the things you could do with F18 and earlier:
* Do a text install and create user account manually after initial login
if you want one
* Do a graphical install and create a user using firstboot
* Do a graphical install, skip user creation in firstboot, and create
user account manually if you want one
Since F19 has user creation in anaconda, we can actually cover all those
scenarios in anaconda quite easily. Literally all we have to do is make
it pop up a warning if you try to quit the installer without creating a
user account, but let you go ahead if you really want to.
If we do that, then initial-setup is entirely superfluous to
requirements. Anaconda would be able to do everything necessary, and
would be encouraging people down the right path, but those who really
want to do installs with no user account would still be able to.
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
likely want to go on popping up if a user account was not created during
installation. But that's entirely up to the desktop team what they want
to do, and it's not at all incompatible with this proposal.
So basically, I think we can just do a simple tweak to anaconda and not
bother running initial-setup at all on a 'normal' install. We can of
course keep it around for the OEM case, but that doesn't need to bother
anyone else.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:03 p.m.
On Tue, May 21, 2013 at 11:50:37AM -0700, Adam Williamson wrote:
Since F19 has user creation in anaconda, we can actually cover all
those
scenarios in anaconda quite easily. Literally all we have to do is make
it pop up a warning if you try to quit the installer without creating a
user account, but let you go ahead if you really want to.
Maybe more forgiving to also not pop up a warning if you've not created a
user but have set a root password? (And maybe put a block of text on the
root pw page suggesting that a user account is best practice?)
I'll let the UX experts make that call, though. :)
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.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:15 p.m.
On Tue, 2013-05-21 at 15:03 -0400, Matthew Miller wrote:
On Tue, May 21, 2013 at 11:50:37AM -0700, Adam Williamson wrote:
> Since F19 has user creation in anaconda, we can actually cover all those
> scenarios in anaconda quite easily. Literally all we have to do is make
> it pop up a warning if you try to quit the installer without creating a
> user account, but let you go ahead if you really want to.
Maybe more forgiving to also not pop up a warning if you've not created a
user but have set a root password?
No, that's what we do at present. It doesn't quite match what we're
aiming for here. We want to _allow_ you to do an install with a root
password but no user account, but _encourage_ you to create a user
account. This is the ultimate, high level behaviour that F18 and earlier
did, and so I'm figuring that's essentially what we want F19 to do.
Simply making anaconda make you jump through a hoop or two to create a
system with no user account, but ultimately let you do it, would achieve
this.
The alternative is to keep initial-setup around and have it do the 'warn
if no user account is created, but ultimately let you do it' thing. But
how is that any better? It's just added complexity and feature
duplication (okay, i-s just re-uses anaconda's code, but it appears as
duplication to the user). Now anaconda can handle user creation, I just
can't see any way it's better to do that in a post-install step than
simply to do it in anaconda.
> 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.
I'm going to reply to this in a separate thread because it requires
broadening out the debate and could sidetrack the primary proposal,
which I want to keep on track. Believe me, I've thought about all the
possibilities here :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:30 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
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!
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.
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.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:56 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
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
4:09 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On Tue, 2013-05-21 at 16:56 -0400, Simo Sorce wrote:
> 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 reason for forcing you would be that it was considered a greater
benefit to keep the install/first boot code paths simple than to make it
relatively easy to do installs with no user accounts. Remember, in this
mail, I was considering and presenting the pros and cons of all the
possible approaches. Please don't skim read and assume I'm advocating
one specific option. I did not in fact say I wanted to go ahead with
this option.
> 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 ?
Nothing much, and if you actually read both my mails fully, that is
precisely the path I proposed.
> 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 ?
Desktops and spins are considered to own their own destiny to at least
some extent. Effectively what is happening here is that the GNOME
desktop/spin believes that a user account should be mandatory to use
their desktop, and so they are enforcing the creation of one.
If people think this is terrible and want to make a fuss about it, there
are various avenues for doing so. Personally it doesn't bother me
overmuch.
Both g-i-s and anaconda/i-s appear to offer at least some mechanism for
configuring remote user accounts. I don't know in detail what
technologies they support; the g-i-s one looks like it supports at least
AD, I don't know what else. The anaconda/i-s "Use network login..."
button appears to do nothing in F19 Beta RC2. I'll file a bug on that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:22 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On Tue, 2013-05-21 at 14:09 -0700, Adam Williamson wrote:
On Tue, 2013-05-21 at 16:56 -0400, Simo Sorce wrote:
> > 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 reason for forcing you would be that it was considered a greater
benefit to keep the install/first boot code paths simple than to make it
relatively easy to do installs with no user accounts. Remember, in this
mail, I was considering and presenting the pros and cons of all the
possible approaches. Please don't skim read and assume I'm advocating
one specific option. I did not in fact say I wanted to go ahead with
this option.
It was a generic 'you', I was not accusing you personally :)
> > 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 ?
Nothing much, and if you actually read both my mails fully, that is
precisely the path I proposed.
Yeah I got that, I was just asking why we consider mandating something
when the current behavior seem, to work just fine.
> > 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 ?
Desktops and spins are considered to own their own destiny to at least
some extent. Effectively what is happening here is that the GNOME
desktop/spin believes that a user account should be mandatory to use
their desktop, and so they are enforcing the creation of one.
Well if you allow me this is a non-sequitur. Of course you need a user
account to login into a desktop environment, that doesn't mean you need
to force people to create a user account at install time. Some people
actually know what they are doing when they skip its creation.
If people think this is terrible and want to make a fuss about it,
there
are various avenues for doing so. Personally it doesn't bother me
overmuch.
Both g-i-s and anaconda/i-s appear to offer at least some mechanism for
configuring remote user accounts. I don't know in detail what
technologies they support; the g-i-s one looks like it supports at least
AD, I don't know what else. The anaconda/i-s "Use network login..."
button appears to do nothing in F19 Beta RC2. I'll file a bug on that.
It used to 'support' ldap and krb5 for auth and even a freeipa option,
but didn't really work in F18.
If someone wants to make user creation mandatory I think they should
first provide a working method to select external account providers in
anaconda. If that can't be done they should leave account creation
optional. Although it being a default and requiring an explicit and
noisy opt-out is fine by me.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
4:26 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On Tue, 2013-05-21 at 17:22 -0400, Simo Sorce wrote:
> Nothing much, and if you actually read both my mails fully, that
is
> precisely the path I proposed.
Yeah I got that, I was just asking why we consider mandating something
when the current behavior seem, to work just fine.
Well, I'm the one driving this thread, and I just considered it because
I try and think through all the possible options when looking at
something like this. I wrote down my thoughts because Matthew's mail
seemed to prompt it. But my primary proposal is still the 'make anaconda
encourage user creation and drop i-s' thing. I don't want to start a
bunfight over g-i-s' mandatory account creation, but if someone else
wants to, it's no skin off my nose.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:27 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On Tue, 2013-05-21 at 17:22 -0400, Simo Sorce wrote:
> Both g-i-s and anaconda/i-s appear to offer at least some
mechanism for
> configuring remote user accounts. I don't know in detail what
> technologies they support; the g-i-s one looks like it supports at least
> AD, I don't know what else. The anaconda/i-s "Use network login..."
> button appears to do nothing in F19 Beta RC2. I'll file a bug on that.
It used to 'support' ldap and krb5 for auth and even a freeipa option,
but didn't really work in F18.
Well, same button name, but the button you're thinking of in F18 was
part of firstboot, which is now dead code. I don't know if the code
behind the similarly-named button in anaconda shares anything in common
with it. Clearly, though, they've improved it to work magically and
instantly with zero user input ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:14 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On Tue, 2013-05-21 at 17:22 -0400, Simo Sorce wrote:
If someone wants to make user creation mandatory I think they should
first provide a working method to select external account providers in
anaconda. If that can't be done they should leave account creation
optional. Although it being a default and requiring an explicit and
noisy opt-out is fine by me.
As you said, logging in to a desktop environment without a user account
doesn't make much sense.
But g-i-s (and anaconda too, I believe) supports any 'external account
provider' that realmd knows about, so you should able to use your
identity server. If it doesn't work for your setup, I'm sure Stef will
take bug reports.
6:15 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On Tue, 2013-05-21 at 19:14 -0400, Matthias Clasen wrote:
On Tue, 2013-05-21 at 17:22 -0400, Simo Sorce wrote:
> If someone wants to make user creation mandatory I think they should
> first provide a working method to select external account providers in
> anaconda. If that can't be done they should leave account creation
> optional. Although it being a default and requiring an explicit and
> noisy opt-out is fine by me.
As you said, logging in to a desktop environment without a user account
doesn't make much sense.
But g-i-s (and anaconda too, I believe) supports any 'external account
provider' that realmd knows about, so you should able to use your
identity server. If it doesn't work for your setup, I'm sure Stef will
take bug reports.
Indeed it didn't work for Simo's setup, and he's filed
https://bugzilla.redhat.com/show_bug.cgi?id=965888 .
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:32 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On Tue, 2013-05-21 at 19:14 -0400, Matthias Clasen wrote:
On Tue, 2013-05-21 at 17:22 -0400, Simo Sorce wrote:
> If someone wants to make user creation mandatory I think they should
> first provide a working method to select external account providers in
> anaconda. If that can't be done they should leave account creation
> optional. Although it being a default and requiring an explicit and
> noisy opt-out is fine by me.
As you said, logging in to a desktop environment without a user account
doesn't make much sense.
But g-i-s (and anaconda too, I believe) supports any 'external account
provider' that realmd knows about, so you should able to use your
identity server. If it doesn't work for your setup, I'm sure Stef will
take bug reports.
It does not work indeed:
https://bugzilla.redhat.com/show_bug.cgi?id=965888
Also I think realmd has no way to set pure LDAP accounts (RHDS,
OpenLDAP, ...).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:39 p.m.
New subject: Possible alternative behaviours for user creation at install time (was Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?)
On 22.05.2013 03:32, Simo Sorce wrote:
Also I think realmd has no way to set pure LDAP accounts (RHDS,
OpenLDAP, ...).
Right, it doesn't yet have that ability. But realmd can gain the ability
to configure other sources than the Active Directory and FreeIPA
providers it currently supports.
That said, it will always only support standard realms, not completely
wild and woolly non-standard LDAP setups. For those you'll want to drop
to the command line and configure manually.
As you suggested on IRC, for OpenLDAP or RHDS we could support RFC 4876
[1] as a standard best-practice configuration that we could discover in
realmd.
Cheers,
Stef
[1] http://tools.ietf.org/html/rfc4876
5:26 a.m.
On May 21, 2013 11:50 AM, "Adam Williamson" <awilliam(a)redhat.com> wrote:
On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> So I'm writing a blog post on this topic ATM, and that really kinda
> brought home how messy this design is at present.
So! I've been poking through the logic of this for the last few days,
still, and with some further testing of exactly what g-i-s and i-s
actually do, and what anaconda and firstboot did in previous releases, I
have an even simpler proposal:
Make anaconda warn if you don't create a user, and nuke initial-setup
for non-OEM installs.
Here is how F18 behaved:
* anaconda only let you create a root password, no user creation
* firstboot ran on graphical installs, not text
* firstboot would let you skip the user creation step, with a warning
So here are all the things you could do with F18 and earlier:
* Do a text install and create user account manually after initial login
if you want one
* Do a graphical install and create a user using firstboot
* Do a graphical install, skip user creation in firstboot, and create
user account manually if you want one
Since F19 has user creation in anaconda, we can actually cover all those
scenarios in anaconda quite easily. Literally all we have to do is make
it pop up a warning if you try to quit the installer without creating a
user account, but let you go ahead if you really want to.
If we do that, then initial-setup is entirely superfluous to
requirements. Anaconda would be able to do everything necessary, and
would be encouraging people down the right path, but those who really
want to do installs with no user account would still be able to.
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
likely want to go on popping up if a user account was not created during
installation. But that's entirely up to the desktop team what they want
to do, and it's not at all incompatible with this proposal.
So basically, I think we can just do a simple tweak to anaconda and not
bother running initial-setup at all on a 'normal' install. We can of
course keep it around for the OEM case, but that doesn't need to bother
anyone else.
+1
4:09 a.m.
On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
So I'm writing a blog post on this topic ATM, and that really
kinda
brought home how messy this design is at present.
One thing that doesn't seem to have been covered in the discussion —
what about third-party firstboot modules?
For an install on a corporate machine we have a firstboot module which
asks for the Active Directory credentials, joins the Samba domain,
obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions
those in NetworkManager, adds a local user with the appropriate
username, provisions accounts in Evolution-EWS and pidgin-sipe, etc.
With firstboot gone, what form should our plugin take?
--
dwmw2
4:18 a.m.
Hi Adam,
Firstboot stays available in RHEL for this reason (legacy plugins). Fedora modules will
probably have to be updated. At least that was the plan. It is very easy to write a new
module with the new API. Ping vpodzime, he has a development guide.
--
Martin Sivák
msivak(a)redhat.com
Red Hat Czech
RHEV-M SLA / Brno, CZ
----- Original Message -----
On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> So I'm writing a blog post on this topic ATM, and that really kinda
> brought home how messy this design is at present.
One thing that doesn't seem to have been covered in the discussion —
what about third-party firstboot modules?
For an install on a corporate machine we have a firstboot module which
asks for the Active Directory credentials, joins the Samba domain,
obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions
those in NetworkManager, adds a local user with the appropriate
username, provisions accounts in Evolution-EWS and pidgin-sipe, etc.
With firstboot gone, what form should our plugin take?
--
dwmw2
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4:26 p.m.
On Wed, 2013-05-22 at 05:18 -0400, Martin Sivak wrote:
> One thing that doesn't seem to have been covered in the
discussion —
> what about third-party firstboot modules?
>
> For an install on a corporate machine we have a firstboot module which
> asks for the Active Directory credentials, joins the Samba domain,
> obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions
> those in NetworkManager, adds a local user with the appropriate
> username, provisions accounts in Evolution-EWS and pidgin-sipe, etc.
>
> With firstboot gone, what form should our plugin take?
>
Firstboot stays available in RHEL for this reason (legacy plugins).
Fedora modules will probably have to be updated. At least that was the
plan. It is very easy to write a new module with the new API. Ping
vpodzime, he has a development guide.
Thanks. Delayed response... I've finally got everything else working
nicely on Fedora 19 and I'm looking at this. I see firstboot is still
available, but it doesn't seem to *work*.
First it wants python-ethtool to be installed but didn't have the
appropriate dependency, and then it's still using pygtk while my own
code has been updated to pygobject and gtk3. (Which was done because
some other code I was *importing* had been upgraded, so I couldn't mix
the two. I don't think you get far with pygtk these days, do you?)
So I'm guessing that it's probably not worth looking at firstboot any
harder, and I should proceed straight to using initial-setup.
The UI part of my tool is a separate python module which can run
standalone too. The firstboot module is therefore fairly trivial, and
looks like this. Any pointers on converting to initial-setup would be
much appreciated. I note /usr/share/initial-setup/modules/README.txt is
a zero-length file... :)
#
# Xu Li <xu.li(a)intel.com>
# Chris Lumens <clumens(a)redhat.com>
#
# Copyright 2009 Intel Corp.
# Copyright 2008 Red Hat, Inc.
#
# This copyrighted material is made available to anyone wishing to use, modify,
# copy, or redistribute it subject to the terms and conditions of the GNU
# General Public License v.2. This program is distributed in the hope that it
# will be useful, but WITHOUT ANY WARRANTY expressed or implied, including the
# implied warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along with
# this program; if not, write to the Free Software Foundation, Inc., 51
# Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Any Red Hat
# trademarks that are incorporated in the source code or documentation are not
# subject to the GNU General Public License and may only be used or replicated
# with the express permission of Red Hat, Inc.
#
from gi.repository import Gtk, GObject
import os, string, sys
from firstboot.config import *
from firstboot.constants import *
from firstboot.functions import *
from firstboot.module import *
import logging
log = logging.getLogger("firstboot")
import gettext
_ = lambda x: gettext.ldgettext("firstboot", x)
N_ = lambda x: x
sys.path.append("/usr/share/intel-user-setup")
from iusMainWindow import iusMainWindow
class moduleClass(Module):
def __init__(self):
Module.__init__(self)
self.priority = 99
self.sidebarTitle = N_("Intel User Setup")
self.title = N_("Intel User Setup")
self.icon = ""
self.ius = None
self.needreboot = False
def apply(self, interface, testing=False):
if testing:
return RESULT_SUCCESS
try:
rc = self.ius.apply()
if rc == True:
# This should make it jump over the *normal* create_user page
interface.moveToPage(pageNum = interface._control.currentPage + 1)
self.needreboot=True
return RESULT_SUCCESS
else:
return self.showRetryDialog()
except Exception, e:
return self.showRetryDialog()
def createScreen(self, interface=None):
log.info("Display Intel user setup screen")
self.vbox = Gtk.VBox(spacing=5)
self.ius = iusMainWindow()
self.vbox.pack_start(self.ius.firstboot_widget(), False, False)
def initializeUI(self):
self.ius.local_users()
def showRetryDialog(self):
dlg = Gtk.MessageDialog(None, 0, Gtk.MESSAGE_ERROR, Gtk.BUTTONS_NONE, "Intel
user setup failed!")
dlg.add_button("Back", RESULT_FAILURE)
dlg.add_button("Ignore", RESULT_SUCCESS)
dlg.set_position(Gtk.WIN_POS_CENTER)
dlg.set_modal(True)
rc = dlg.run()
dlg.destroy()
return rc
def needsReboot(self):
return self.needreboot
--
dwmw2
6:52 p.m.
On Mon, 2013-07-15 at 22:26 +0100, David Woodhouse wrote:
Thanks. Delayed response... I've finally got everything else working
nicely on Fedora 19 and I'm looking at this. I see firstboot is still
available, but it doesn't seem to *work*.
First it wants python-ethtool to be installed but didn't have the
appropriate dependency, and then it's still using pygtk while my own
code has been updated to pygobject and gtk3. (Which was done because
some other code I was *importing* had been upgraded, so I couldn't mix
the two. I don't think you get far with pygtk these days, do you?)
So I'm guessing that it's probably not worth looking at firstboot any
harder, and I should proceed straight to using initial-setup.
FWIW after working around bug 984932 by making my *own* package depend
on the packages that firstboot should have required for itself, and
after downgrading my UI code from Gtk3 to pygtk2 (which required that I
stop using pyanaconda.users), I now have a firstboot module that works.
I'd still like to convert it to initial-setup at some point, but it's
working for now.
--
dwmw2
7:51 a.m.
On Mon, 2013-07-15 at 22:26 +0100, David Woodhouse wrote:
On Wed, 2013-05-22 at 05:18 -0400, Martin Sivak wrote:
> > One thing that doesn't seem to have been covered in the discussion —
> > what about third-party firstboot modules?
> >
> > For an install on a corporate machine we have a firstboot module which
> > asks for the Active Directory credentials, joins the Samba domain,
> > obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions
> > those in NetworkManager, adds a local user with the appropriate
> > username, provisions accounts in Evolution-EWS and pidgin-sipe, etc.
> >
> > With firstboot gone, what form should our plugin take?
> >
>
> Firstboot stays available in RHEL for this reason (legacy plugins).
> Fedora modules will probably have to be updated. At least that was the
> plan. It is very easy to write a new module with the new API. Ping
> vpodzime, he has a development guide.
Thanks. Delayed response... I've finally got everything else working
nicely on Fedora 19 and I'm looking at this. I see firstboot is still
available, but it doesn't seem to *work*.
First it wants python-ethtool to be installed but didn't have the
appropriate dependency, and then it's still using pygtk while my own
code has been updated to pygobject and gtk3. (Which was done because
some other code I was *importing* had been upgraded, so I couldn't mix
the two. I don't think you get far with pygtk these days, do you?)
So I'm guessing that it's probably not worth looking at firstboot any
harder, and I should proceed straight to using initial-setup.
In the absence of the promised documentation for initial-setup, I ended
up using firstboot anyway. I backported my code to pygtk2 again, and
filed a bug for the missing dependencies in the packaging.
The bug has now been closed on the basis that firstboot is deprecated
and replaced by initial-setup, but I *still* don't see any sign of the
long-promised documentation. Or even any example 'skeleton' of a
standalone module to start from. Is there any prospect of that happening
any time soon, please?
--
dwmw2
5:43 a.m.
On Mon, 2013-10-14 at 13:51 +0100, David Woodhouse wrote:
On Mon, 2013-07-15 at 22:26 +0100, David Woodhouse wrote:
> On Wed, 2013-05-22 at 05:18 -0400, Martin Sivak wrote:
> > > One thing that doesn't seem to have been covered in the discussion —
> > > what about third-party firstboot modules?
> > >
> > > For an install on a corporate machine we have a firstboot module which
> > > asks for the Active Directory credentials, joins the Samba domain,
> > > obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions
> > > those in NetworkManager, adds a local user with the appropriate
> > > username, provisions accounts in Evolution-EWS and pidgin-sipe, etc.
> > >
> > > With firstboot gone, what form should our plugin take?
> > >
> >
> > Firstboot stays available in RHEL for this reason (legacy plugins).
> > Fedora modules will probably have to be updated. At least that was the
> > plan. It is very easy to write a new module with the new API. Ping
> > vpodzime, he has a development guide.
>
> Thanks. Delayed response... I've finally got everything else working
> nicely on Fedora 19 and I'm looking at this. I see firstboot is still
> available, but it doesn't seem to *work*.
>
> First it wants python-ethtool to be installed but didn't have the
> appropriate dependency, and then it's still using pygtk while my own
> code has been updated to pygobject and gtk3. (Which was done because
> some other code I was *importing* had been upgraded, so I couldn't mix
> the two. I don't think you get far with pygtk these days, do you?)
>
> So I'm guessing that it's probably not worth looking at firstboot any
> harder, and I should proceed straight to using initial-setup.
In the absence of the promised documentation for initial-setup, I ended
up using firstboot anyway. I backported my code to pygtk2 again, and
filed a bug for the missing dependencies in the packaging.
The bug has now been closed on the basis that firstboot is deprecated
and replaced by initial-setup, but I *still* don't see any sign of the
long-promised documentation. Or even any example 'skeleton' of a
standalone module to start from. Is there any prospect of that happening
any time soon, please?
Sorry, I'd replied in the bugreport [1] before I saw
this thread going
on.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=984932
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
3839
days inactive
3990
days old
37 comments
14 participants
participants (14)
-
Adam Williamson -
Dan Mashal -
David Woodhouse -
Jaroslav Reznik -
John.Florian＠dart.biz -
Martin Sivak -
Matthew Miller -
Matthias Clasen -
Oron Peled -
Richard W.M. Jones -
Simo Sorce -
Stef Walter -
Steven Boswell II -
Vratislav Podzimek