Anaconda has been through a pretty major UI rewrite. Anybody that has tried either Fedora 18 Alpha or any of the nightly images since then should be well aware of this.
The UI rewrite was done for many reasons and accomplishes many goals. I'm not going to rehash that here. What I am going to talk about is what happened to text mode.
Text mode in F17 and before was ncurses based. This gave some kind of pretty UI to do things. There were drawbacks though. ncurses didn't work on all the terminals people throw at Anaconda, in particular dumb serial terminals and x3270, the terminal for s390x. Because of that we also had a (non-interactive) very simple display mode called 'cmdline'. This just did simple line printing of progress during a kickstart. Unfortunately due to the way the old UI was coded there wasn't a good complete separation of presentation from computation so many things were written 3 times. Once for gui, once for text, and once for cmdline. Fun right?
With Fedora 18 there is one text UI. It is used on full featured consoles as well as dumb ones. It doesn't use ncurses, it just uses simple line printing. It can be used over serial (interactively!) and over x3270 (non-interactively). It is a simple question and answer prompt.
The design of text mode for F18 and beyond is closely modelled after the design of the GUI for F18 and beyond. A hub and a set of spokes, so that users can do tasks in whatever order they wish, potentially while things happen in the background. There is a main setup hub where the user can set a time zone, set a root password, and do some basic storage configuration (pick target disks and a strategy to clear space on those disks). Once all tasks are complete the user can progress into the actual installation where we just throw up a running list of tasks the backend is accomplishing.
There are very few things you can do with text mode in Fedora 18. You cannot pick languages, and you cannot pick installation source. These can be provided via boot time arguments. You also cannot do advanced storage configuration which would need a kickstart file to accomplish via "text mode". We are planning to add some functionality for Fedora 19, but we haven't decided which items and how rich those items will be. Text mode is still de-emphasized in favor of direct GUI or remote GUI by way of VNC. For kickstarts however text mode is still pretty great. The minimal UI does not prevent a fully customized kickstart from being executed.
Give text mode a spin! It's simple, fast, unobtrusive, and gets the job done.
Friday, October 12, 2012
Thursday, October 11, 2012
Just in case you were wondering...
I've just made the Fedora 18 installer work well on s390x again. You know, for the 10s of you out there that care.
You're welcome.
You're welcome.
Root password in Fedora 18
As part of the Anaconda UI redesign, we had hoped to offload root password setting to the installed host. We had envisioned a scenario where the installer locked the root account and post-install software such as Firstboot or Gnome Initial Experience would take care of adding a user to the system and marking that user as a "super" user. This would obviate the need for a root password, as the super user could use sudo to accomplish admin tasks.
That's how things looked prior to Fedora 18 Alpha, but in testing it became apparent that we couldn't always count on Firstboot or GIE to set things up right, or even be present.
This was particularly true of text mode, where the only packages installed was the bare minimal set. So first text mode grew a password spoke, and we made it mandatory.
Then I wrote a password spoke for GUI mode which lived in the main setup hub. For Alpha this was an optional spoke and it defaulted to a locked root account. Some thought was put into flipping the optional vs mandatory state based on install data, such as whether or not Firstboot was selected for install. Part of being able to do that was moving the spoke from the main setup hub to the install (or configuration) hub. If it lives in this hub we should have finalized data about what packages were selected for install. However doubts arose as to whether "part of the payload" was enough data to ensure that Firstboot or GIE actually ran and we were worried we could still lead users into being locked out of their freshly installed system.
So, for Beta, I've just pushed a set of changes that will make the password spoke a mandatory spoke. You must visit the spoke before you can complete the install. You can still mark the root account as disabled, just by leaving the password fields blank, but you do so at your own risk. This configuration is likely to remain for Fedora 18.
That's how things looked prior to Fedora 18 Alpha, but in testing it became apparent that we couldn't always count on Firstboot or GIE to set things up right, or even be present.
This was particularly true of text mode, where the only packages installed was the bare minimal set. So first text mode grew a password spoke, and we made it mandatory.
Then I wrote a password spoke for GUI mode which lived in the main setup hub. For Alpha this was an optional spoke and it defaulted to a locked root account. Some thought was put into flipping the optional vs mandatory state based on install data, such as whether or not Firstboot was selected for install. Part of being able to do that was moving the spoke from the main setup hub to the install (or configuration) hub. If it lives in this hub we should have finalized data about what packages were selected for install. However doubts arose as to whether "part of the payload" was enough data to ensure that Firstboot or GIE actually ran and we were worried we could still lead users into being locked out of their freshly installed system.
So, for Beta, I've just pushed a set of changes that will make the password spoke a mandatory spoke. You must visit the spoke before you can complete the install. You can still mark the root account as disabled, just by leaving the password fields blank, but you do so at your own risk. This configuration is likely to remain for Fedora 18.
Subscribe to:
Posts (Atom)