Tuesday, February 26, 2008

Getting Rid of 2nd Stage of Installation

As you are already aware, we are re-designing the installation workflow for openSUSE 11.0. One of the goals is to simplify the installation, for example by reducing the number of steps needed to finish the installation.

The area of most of the steps is the 2nd stage of installation (after reboot). We internally call this the configuration of the new system and it consists of several steps giving the user maximum flexibility to setup the system before it starts in a full-scale. While the reasoning works for simple servers that get online immediately, it does not fit any of these use cases:
  1. server running mission-critical service - those servers are installed off-line, running in a testing mode for some time and only after that they are put into production environment
  2. workstations and home users - there, a user needs to be running full system as quickly as possible

So, one of the goals is to reduce the 2nd stage of installation to only the minimal set of steps.

Status in openSUSE 10.3

There are following steps in the 10.3 installation workflow:
  1. root password
  2. hostname and domain
  3. network hardware proposal
  4. test of internet access
  5. setup of updates repository
  6. application of the already released security and recommended updates
  7. adding non-root users
  8. release notes
  9. hardware configuration proposal
  10. congratulations screen
All of those steps are always presented during the installation except for 5) and 6). This makes the 2nd stage in the easiest case quite some 'Next' clicks. Yes, quite some of them can be already skipped, but this also means more clicks and it's a different purpose (avoid setting the particular part during installation).

How to Simplify?

There are several ways to simplify the workflow. It's easy to see that the only absolutely necessary step needed is entering the root password. However, having a normal user is also quite a good security policy, so this step should stay as well.

How to get rid of other steps?

The following steps can wait for the running system:

hostname and domain
test of internet access
setup of updates repository
application of the already released security and recommended updates

Hostname and domain is typically set by DHCP these days, or an admin knows how to set it up. The test of internet access can be easily done by starting Firefox or ping, and that's a typical first action of a user, right?

The question of security updates is a bit more complicated. Yes, it is very important to apply the security fixes as soon as possible, but frankly, who wants to wait for this before the machine can be used? Also, application of the updates are done by the applet, where the tendency is to have it as non-distracting as possible. So, the applet (and of course YaST Online Update (YOU) and zypper) could be enhanced to identify that there are no updates repositories set up and provide an easy option to do it. YOU already has this capability (it detects if there are not repositories containing patches). A final note: firewall is enabled by default during the whole installation.

What about the rest of the steps?

root password
network hardware proposal

adding non-root users
release notes
hardware configuration proposal
congratulations screen

The current proposal is to move the root password and adding of non-root users to the 1st stage, as they are mandatory for the system to be functional. This introduces quite interesting issues like checking the quality of root password as the cracklib dictionaries are big. Also, how to support LDAP, NIS and all other kinds of 'enterprise' authentication options (here, it would be possible to reactivate the needed parts of the interactive 2nd stage based on the input from the 1st stage).

This leaves us with 2 hardware-related proposals:

network hardware proposal
This contains both hardware proposal, but also configuration of firewall, proxy and remote administration. The hardware part could be easily handled by NetworkManager for workstations while servers need typically a complex static setup which is much easier done and is far less error-prone in the running system. For me, the only crucial part left is the firewall, specifically enabling of ssh access to the machine. Without this, you cannot remotely finish the configuration after the installation is done. OTOH, it's wise to activate the firewall with closed ssh port by default. A possible solution would be to move firewall to the 1st stage as well.

hardware proposal
This one might be tricky. The installation currently configures printers, sound, X11 and TV cards. In most cases, sound and TV cards just work with the proposal. Both printers and X11 are heading in direction of autoconfiguration, although if X11 proposal breaks, this can be quite an issue for the system - anyway, I'd consider to be a bug and the X11 configuration that's used during the install is available in the running system as fallback as well. As soon as the system has any running X11, there is plenty of tools to fine-tune the setup. So, the proposal solution would be here to autoconfigure all hardware and leave the fine-tuning to the running system as well.

congratulations screen
And of course, let's get rid of the congratulations screen ;-)

The Proposal

So, the summary of the proposed changes:
  1. root password -> 1st stage
  2. hostname and domain -> drop
  3. network hardware proposal -> NetworkManager + firewall in 1st stage
  4. test of internet access -> drop
  5. setup of updates repository -> opensuse-updater, zypper, YOU
  6. application of the already released security and recommended updates -> opensuse-updater, zypper, YOU
  7. adding non-root users -> 1st stage
  8. release notes -> 1st stage
  9. hardware configuration proposal -> autoconfigure in 1st stage
  10. congratulations screen -> drop

There are quite some assumptions and a big question if we can reach this state for 11.0 already, but in the end, the installation experience of openSUSE would be much improved in my opinion.

Note: This proposal is a result of my discussions with Coolo (who's driving the rewrite of the workflow), kobliha (who's maintaining YaST installation), Jiri Srain (one of the YaST team leads) and others.


Francis said...

Thanks a lot for sharing! What I personally wish is that the whole second part of the installation is slimmed down (pretty much exactly to how you said), and all integrated into the first part.

Most users tend to think the installation has finished after all the packages have been installed, but then they find they have a few more steps to do and it makes the whole installation feel longer.

This also helps specifically on the live CD, where entering configuration information after a reboot is even more unexpected.

Justin said...

One suggestion I have is this: If the hostname/domain was set from a previous installation, it should just use that.

Jiří Suchomel said...

Just a note, I hope you know it: even completely non-interactive 2nd stage doesn't mean no 2nd stage. For example saving that user configured in first stage (currently) must be done in the 2nd stage (due to yast2-users usage).

Gabriel Stein said...

Why not use a XML file with all setup? For example, if I need install openSUSE on 10 machines, I will use a sample XML file to install quickly and with my package selection ready.

My idea: Create a XML file to put on network install server(a local server with opensuse files), and the installation program parse this configs to install process.

Do you need a help? I´m working in a simple monitoring system to openSUSE/SLED, but...

Christian Boltz said...

Moving all the user input to the first stage is a very good idea.

However, I have some proposals:

Network hardware

Please use a dialog with two options:

(o) automatic configuration using NetworkManager
( ) manual network configuration

You may even add an "experts only" to the second option, but please offer it in the installation workflow.

Reason: I'm not sure if NetworkManager will be able to find correct network settings when I install a (web)server over SSH...

If you really want to hide it, add a "network" section to the proposal screen so that it can be changed from there.

hostname and domain

Everybody will see the hostname when opening a xterm, so I'm not sure if you should really drop this step ;-)

update repository setup

You can simply offer download.opensuse.org/update/11.0 at the start of the installation. This way, the updated packages will be included in the installation already. I would even say that you should enable this repo by default.

Checking for an update repository in YOU and opensuseupdater is of course a good idea.

test of internet access

Hmmm, how do you want to find out the number of installations in the future? ;-)) (for those who wonder: AFAIK the release notes downloads were counted. Simple and effective.)

Since online repositories can be included at the beginning of the installation already, the internet test (aka release notes download) is more or less done anyways...

hardware configuration

Autoconfiguration is a good idea, but please offer a way to change the settings - even if it is "only" a section on the proposal screen.

To sum it up:
Don't get me wrong - I'm not against changing the installation workflow. I just want to make sure that everything works afterwards, and this sometimes means that you have to do some settings manually.

I also won't object if you create separate workflows for "normal" and "expert" users.

@Gabriel: You are looking for AutoYaST ;-)

dadiconza said...

The installer no ask netbios name of PC, workgroup or domain name , security for smb.conf .
This information is elemental for desktop in enviroment multiplataform of work real.
The user is create in linux but not in smbpasswd or samba user backend.

Facu said...

you should give options for predefined system with different workflows..
in the first step we shoul be able to select:
- Mission critical server
- Mid range server
- Worstation/home user

Then, each one of this option has its own workflow with it own configuration requirements (firewall, root password, user sources).

the other option is to define the workflow based on the level of skill selected by the user.

hope this help.

[Knuckles] said...

I think slimming the installation procedure is nice, but I also liked the idea of user-configuration being done on a second stage, as this allowed you, to install an opensuse system for someone and just leave the second stage for them to do when they started the pc (so they selected their own root password, that's important).

But I guess that's a not-so-typical usecase, so it might not be interesting/useful enough to consider it.

Grósz said...

"The test of internet access can be easily done by starting Firefox or ping, and that's a typical first action of a user, right?"
"who wants to wait for this before the machine can be used?"

There seems to be a problem here: as you said, a user will much likely open Firefox at first and browse the web - without security updates installed! Some months after the release there may be quite a number of browser, remote (blocked by the firewall) and local security holes.

"the X11 configuration that's used during the install is available in the running system as fallback as well"

Sometimes the installer can't start X and works in text mode. YaST2 works much the same in text mode and in GUI so even a, unexperienced user can manage to install the system. But, after the installation, if there is no X11 configuration during the installation, they will only see a console login screen after the installation.

Most of what is currently configured during the installation, has to be configured sometime anyway, and I think it is better to have a completely working system after the installation (even if it takes more steps) than doing a lot of configuration after the installation, on the halfly working system.

Frank said...

This is only a very small part of the workflow, but it's something that's bugged me for years. How about making the release notes readable during the stage where the selected packages are being copied to the hard drive? There's nothing else for the user to do during that time anyways except read a bunch of repeated boring slides extolling the virtues of opensuse. That screen already has tabs to switch from the boring slides to a "package installation details" view, so it would be no great burden to add a "Release Notes" tab as well. As it is now, I never read the release notes because they're displayed at the very end of the installation procedure, by which time I'm bored with waiting and looking forward to actually using the system. It seems to me this would remove one of the second stage steps while also encouraging people to actually read the release notes.

jimmac said...
This comment has been removed by the author.