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:
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.
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.
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.
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.
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.
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@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ
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.
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.
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.
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.
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.
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,
From: Adam Williamson awilliam@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
----- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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=msivak...).
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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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=msivak...).
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)...
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.
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=msivak...).
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.
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.
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.
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 :)
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.
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.
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.
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.
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.
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 ;)
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.
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 .
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.
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
On May 21, 2013 11:50 AM, "Adam Williamson" awilliam@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
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?
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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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@intel.com # Chris Lumens clumens@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
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.
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?
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
devel@lists.stg.fedoraproject.org
-
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