OemConfigServer

Differences between revisions 4 and 12 (spanning 8 versions)
Revision 4 as of 2008-11-13 20:52:34
Size: 3164
Editor: mx
Comment:
Revision 12 as of 2009-01-23 12:17:57
Size: 4552
Editor: 82-69-40-219
Comment: test/demo plan
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from 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. In parallel people building virtual appliances need a way to offer their users to perform the base configuration of their appliance upon first login. 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. Additionally, oem-config can now also be used by virtual appliances to define base parameters of the appliance during the user's first login. 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
   * se
rver 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)
Line 29: Line 33:
 * ISV ships a whatever server virtual appliance and need the end user to configure the last part of the install after the user has loggeg in a first time. ISV needs to be able to modify the questions in a reasonable way without having to recompile the tool.  * 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 31: Line 35:
 * Distro teams needs to have a way for the user to initialize base configuration option when first starting a base image provide on some cloud (such as EC2)

== Assumptions ==
 
 * oem-config is already designed to have multiple front-ends (gtk, qt). This would mainly add a text based front end.
 * oem-config can be modified to be called as part of a first login script
 * oem-config can be modified to handle variable question list based on some configuration file
 * 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 41: Line 39:
This should basically keep the same design oem-config uses on the desktop if this can be done with the above assumptions 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 45: Line 51:
 * Add a tasksel option to oem-config
 * Add a curses front end to the existing ones in oem-config
 * ...

=== UI Changes ===

 * add a tasksel
 * add ip configuration option
 * add ability to define runtime options

=== 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 61: Line 55:
Perform an installation of the Ubuntu server edition in OEM mode. After the first reboot, run 'oem-config-prepare', and reboot. It should ask a series of configuration questions, including locale, timezone, keyboard, account information, network configuration, and tasks.
Line 62: Line 57:
== Outstanding Issues == Perform an installation of the Ubuntu desktop edition in OEM mode to ensure that it has not regressed.
Line 64: Line 59:
''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.''
Following the documentation written for adding new installation steps, add a simple page to confirm acceptance of a licence, produce a virtual machine image including that page, and test it.

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

Perform an installation of the Ubuntu server edition in OEM mode. After the first reboot, run 'oem-config-prepare', and reboot. It should ask a series of configuration questions, including locale, timezone, keyboard, account information, network configuration, and tasks.

Perform an installation of the Ubuntu desktop edition in OEM mode to ensure that it has not regressed.

Following the documentation written for adding new installation steps, add a simple page to confirm acceptance of a licence, produce a virtual machine image including that page, and test it.


CategorySpec

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