OemConfigServer

Differences between revisions 1 and 11 (spanning 10 versions)
Revision 1 as of 2008-06-25 11:13:51
Size: 2368
Editor: mx
Comment:
Revision 11 as of 2009-01-23 12:13:29
Size: 3977
Editor: 82-69-40-219
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from oem-config-server
Line 3: Line 4:
 * '''Launchpad Entry''': UbuntuSpec:oem-config-server  * '''Launchpad Entry''': https://blueprints.launchpad.net/oem-config/+spec/oem-config-server
Line 5: Line 6:
 * '''Contributors''':  * '''Contributors''': ColinWatson
Line 10: Line 11:
OEM willing to ship server with Ubuntu pre-installed are blocked by the fact that oem-config currently only provide a gui interface. We need to develop a text based (curses?) front-end for oem-config. Develop a server-oriented frontend for oem-config, and some additional configuration modules.
Line 14: Line 15:
oem-config can now be used by hardware vendors to ship their servers with Ubuntu pre-installed, thanks to a text based interface that is now available at first boot. oem-config can now be used by hardware vendors to ship their servers with Ubuntu pre-installed, thanks to a text-based interface that is now available at first boot. Additionally, oem-config can now also be used by virtual appliances to define base parameters of the appliance during the user's first login.
Line 18: Line 19:
OEMs willing to ship servers with Ubuntu pre-installed are blocked by the fact that oem-config currently only provides a graphical user interface. We need to develop a frontend usable from a text console, and adjust the set of available configuration pages to include ones suitable for servers.

In parallel, people building virtual appliances need a way to offer their users a way to perform the base configuration of their appliance upon first login, requiring more extensibility than is currently available.
Line 20: Line 25:
 * OEM want to ship his server with Ubuntu Server Edition pre-installed but still let the end user specify the last part of the installation.  * An OEM wants to ship his server with Ubuntu Server Edition pre-installed but still let the end user specify the last part of the installation.
Line 23: Line 28:
   * timezone
Line 24: Line 30:
   * Timezone
   * server name
   * ip configuration
   * Tasks to install (same list as the one offered on the server installer)
   * network configuration
   * tasks to install (same list as the one offered on the server installer)
 
 * An ISV ships a Foo``Server Deluxe 3000 virtual appliance (based on Ubuntu) and needs the end user to configure the last part of the install after the user has logged in for the first time. The ISV needs to be able to modify the questions in a reasonable way without excessively difficult development work.
Line 29: Line 35:
== Assumptions ==
 
 * oem-config is already designed to have multiple front-ends (gtk, qt). This would mainly add a text based front end.
 * The Ubuntu team needs to have a way for the user to perform simple base configuration when first starting a base image provided on some cloud (such as EC2).
Line 35: Line 39:
This should basically keep the same design oem-config uses on the desktop. We will add a new frontend to oem-config. Other oem-config frontends intercept the debconf protocol and use it to display hand-designed pages in a graphical user interface. This new frontend will not do this; instead, it will simply arrange for the questions to be asked via debconf, as if they had been asked as part of package configuration. This will give a unified feel, as the same style of interface is used both in the server installer and in later package installation. '''[done, oem-config 1.54.2]'''

We will arrange for this frontend to be invoked before the first login if the `oem-config-prepare` program has been run, in the same way as is done for other frontends. '''[done, oem-config 1.54.2]'''

We will modify oem-config's frontends (including the new debconf frontend) to fetch the set of pages to display from debconf. This matches our configuration framework for all other installer components, and is easy for a system integrator to set.

We will add `netcfg` and `tasksel` wrapper components to oem-config.

We will document the process for adding new installation steps to oem-config, and make simplifications as required so that this documentation is not excessively involved. In particular, we expect to make it possible to implement a simple page without complex debconf protocol programming when it falls into the pattern of "ask a small number of simple questions and store the results" without attempting to wrap another existing program.
Line 39: Line 51:
 * Add a tasksel option to oem-config
 * Add a curses front end to the existing ones in oem-config

=== UI Changes ===

 * No UI changes to the existing oem-config apart from adding a tasksel and ip configuration option

=== Code Changes ===

''Code changes should include an overview of what needs to change, and in some cases even the specific details.''
In order to implement a working debconf frontend, we must fix [[https://bugs.launchpad.net/bugs/28890|bug 28890]] so that any timezone can be selected even with a plain debconf frontend. '''[done, tzsetup 1:0.24ubuntu1]'''
Line 52: Line 55:
An oem-config scenario needs to be added to the iso-testing for server.
 * Install server
 * run oem-config prep
 * reboot
 * answer questions
 * check correct configuration

== Outstanding Issues ==

''This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.''

== BoF agenda and discussion ==

''Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.''

Summary

Develop a server-oriented frontend for oem-config, and some additional configuration modules.

Release Note

oem-config can now be used by hardware vendors to ship their servers with Ubuntu pre-installed, thanks to a text-based interface that is now available at first boot. Additionally, oem-config can now also be used by virtual appliances to define base parameters of the appliance during the user's first login.

Rationale

OEMs willing to ship servers with Ubuntu pre-installed are blocked by the fact that oem-config currently only provides a graphical user interface. We need to develop a frontend usable from a text console, and adjust the set of available configuration pages to include ones suitable for servers.

In parallel, people building virtual appliances need a way to offer their users a way to perform the base configuration of their appliance upon first login, requiring more extensibility than is currently available.

Use Cases

  • An OEM wants to ship his server with Ubuntu Server Edition pre-installed but still let the end user specify the last part of the installation.
  • Joe buys a server with Ubuntu pre-installed, the first time he boots it, he is requested to specify
    • timezone
    • account information and password
    • network configuration
    • tasks to install (same list as the one offered on the server installer)
  • An ISV ships a FooServer Deluxe 3000 virtual appliance (based on Ubuntu) and needs the end user to configure the last part of the install after the user has logged in for the first time. The ISV needs to be able to modify the questions in a reasonable way without excessively difficult development work.

  • The Ubuntu team needs to have a way for the user to perform simple base configuration when first starting a base image provided on some cloud (such as EC2).

Design

We will add a new frontend to oem-config. Other oem-config frontends intercept the debconf protocol and use it to display hand-designed pages in a graphical user interface. This new frontend will not do this; instead, it will simply arrange for the questions to be asked via debconf, as if they had been asked as part of package configuration. This will give a unified feel, as the same style of interface is used both in the server installer and in later package installation. [done, oem-config 1.54.2]

We will arrange for this frontend to be invoked before the first login if the oem-config-prepare program has been run, in the same way as is done for other frontends. [done, oem-config 1.54.2]

We will modify oem-config's frontends (including the new debconf frontend) to fetch the set of pages to display from debconf. This matches our configuration framework for all other installer components, and is easy for a system integrator to set.

We will add netcfg and tasksel wrapper components to oem-config.

We will document the process for adding new installation steps to oem-config, and make simplifications as required so that this documentation is not excessively involved. In particular, we expect to make it possible to implement a simple page without complex debconf protocol programming when it falls into the pattern of "ask a small number of simple questions and store the results" without attempting to wrap another existing program.

Implementation

In order to implement a working debconf frontend, we must fix bug 28890 so that any timezone can be selected even with a plain debconf frontend. [done, tzsetup 1:0.24ubuntu1]

Test/Demo Plan


CategorySpec

OemConfigServer (last edited 2009-02-19 16:02:30 by 82-69-40-219)