KarmicGoldenIsoImage
|
Size: 4417
Comment: user stories
|
Size: 5990
Comment: finish initial draft
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| * '''Contributors''': * '''Packages affected''': |
* '''Contributors''': various * '''Packages affected''': `livecd-rootfs`; new package |
| Line 16: | Line 16: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. |
We now offer a simple command-line tool to build customised Ubuntu installation images, suitable for use in corporate environments. |
| Line 31: | Line 29: |
| * Corporate environments will not in general be satisfied with a simple live image with no provision for updates; they will generally want (or be highly receptive to arguments that they should want) a system that includes a local network-accessible archive, for the purpose of deploying updates. * Small configuration changes will need to be possible without needing to rebuild packages (and thus merge security updates for the rest of time, etc.). * If fetching the bulk of packages from the main Ubuntu archives is not possible, operators of this system will be able to set up a local mirror using any of the various tools we already offer for this purpose. (It may be that this should be simplified in various ways, but that is outside the scope of this specification.) |
|
| Line 33: | Line 35: |
| You can have subsections that better describe specific parts of the issue. | We will offer a straightforward way to build a repository with any additional packages that are required (perhaps backports, PPA packages, packages otherwise not in the standard Ubuntu repositories for whatever reason, local builds, etc.). This will probably just wrap up existing technology. There will be a special-purpose easy way to create a metapackage referring to all the top-level packages needed by the organisation. Preseeding will be used to add the internal repository to `/etc/apt/sources.list`, to configure automatic upgrades, and optionally to configure home directory encryption (via ecryptfs). We will advise that configuration changes should normally be made by changing packages (and will document the process for doing so), but in some cases it may instead be appropriate to permit manually editing configuration files in the live image. |
| Line 37: | Line 45: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | === Existing software === |
| Line 39: | Line 47: |
| === UI Changes === | The normal cdimage toolset we use to build official Ubuntu images is probably too complicated to set up here, but is by and large overkill for this purpose anyway. Most of the hard work it does involves building an apt archive on the CD, and with a customised image this is unnecessary. |
| Line 41: | Line 49: |
| Should cover changes required to the UI, or specific UI that is required to implement this | `livecd-rootfs`, which we use to build official Ubuntu live filesystems, is reasonably straightforward to run on a user machine. It is currently fairly specific to Ubuntu and its known derivatives, so it needs to have some more customisation facilities added to it: in particular it needs to be able to take a custom package list on its command line. |
| Line 43: | Line 51: |
| === Code Changes === | There are several suitable packages for managing local repositories, and there is clearly no need to invent another; `reprepro` seems to be a likely candidate. |
| Line 45: | Line 53: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | === New software === |
| Line 47: | Line 55: |
| === Migration === | To start with, we will offer a simple command-line toolset, using a single top-level command with subcommands. We expect that a graphical interface may be added later if time permits. |
| Line 49: | Line 57: |
| Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. |
The initial command set will be similar to the following: init:: set up a configuration directory and a local repository add-distribution:: add a distribution (e.g. `karmic`) to the archive remove-distribution:: remove a distribution from the archive add-package:: add packages (`.changes` files) to the archive remove-package:: remove packages from the archive add-metapackage:: build a metapackage depending on a given list of packages, and add it to the archive configure-image:: create or edit configuration for an image build-image:: build a live CD image for a distribution edit-image:: unpack an image, chroot into it, let the operator edit it, and save the result as a new image |
| Line 60: | Line 75: |
| == Unresolved issues == | == Future work == |
| Line 62: | Line 77: |
| 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 == {{{ Create customised image based on tested configuration with approved set of binary packages * Setting up URL to internal repository? * easy to do with preseeding, but would need to wrap up the process * Upgrade policy should be mandatory * Metapackage to assist upgrades * Repository gateway function not implemented yet * Enough preseeding support to set up more or less arbitrary `/etc/apt/sources.list` combination * Wrap up repository building function (feed in package, automatically build repository) * Require package changes rather than manually editing files in /etc, and so on Practicalities of building: * livecd-rootfs is reasonably straightforward to run on a user machine * cdimage toolset is probably too complicated, but is mostly not required (with a customised image, you don't need an apt archive) * start out with a live image * livecd-rootfs needs more customisation facilities; currently fairly specific to Ubuntu and its known derivatives * might not be entirely crazy to rewrite it in Python (currently shell) for better extensibility Encrypting data (may be necessary for people in sensitive environments): * just rely on ecryptfs? }}} |
It might make sense to rewrite `livecd-rootfs` in Python (it is currently written in shell) for better extensibility; or perhaps we should switch Ubuntu to `live-helper`. I think it is important that the software used for building customised images shares as much with the software used for building official Ubuntu images as possible, since that offers maximum probability of fixing common bugs in both rather than just in one. |
Launchpad Entry: foundations-karmic-golden-iso-image
Created: ColinWatson
Contributors: various
Packages affected: livecd-rootfs; new package
Summary
This work allows corporate IT users to:
- Create a customised image based on a tested configuration, consisting of packages they have approved. The user wants to create and distribute this image to employees to install on desktops and servers in their internal IT environment.
- Ensure that employees with access to sensitive information encrypt their data.
Release Note
We now offer a simple command-line tool to build customised Ubuntu installation images, suitable for use in corporate environments.
Rationale
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.
User stories
- Sam is an IT manager responsible for deploying Ubuntu to employees' desktops. He has a list of applications he wants to include as standard, along with various small configuration changes. He would like a customised installation image that can be given to junior technicians to install on new desktop systems.
- Jane is an information security officer in the civil service. Some of her staff have access to confidential documents. She requires that documents stored on their laptops be encrypted, and instructs the IT manager preparing Ubuntu for deployment to ensure that their laptops are configured that way from installation.
Assumptions
- Corporate environments will not in general be satisfied with a simple live image with no provision for updates; they will generally want (or be highly receptive to arguments that they should want) a system that includes a local network-accessible archive, for the purpose of deploying updates.
- Small configuration changes will need to be possible without needing to rebuild packages (and thus merge security updates for the rest of time, etc.).
- If fetching the bulk of packages from the main Ubuntu archives is not possible, operators of this system will be able to set up a local mirror using any of the various tools we already offer for this purpose. (It may be that this should be simplified in various ways, but that is outside the scope of this specification.)
Design
We will offer a straightforward way to build a repository with any additional packages that are required (perhaps backports, PPA packages, packages otherwise not in the standard Ubuntu repositories for whatever reason, local builds, etc.). This will probably just wrap up existing technology.
There will be a special-purpose easy way to create a metapackage referring to all the top-level packages needed by the organisation.
Preseeding will be used to add the internal repository to /etc/apt/sources.list, to configure automatic upgrades, and optionally to configure home directory encryption (via ecryptfs).
We will advise that configuration changes should normally be made by changing packages (and will document the process for doing so), but in some cases it may instead be appropriate to permit manually editing configuration files in the live image.
Implementation
Existing software
The normal cdimage toolset we use to build official Ubuntu images is probably too complicated to set up here, but is by and large overkill for this purpose anyway. Most of the hard work it does involves building an apt archive on the CD, and with a customised image this is unnecessary.
livecd-rootfs, which we use to build official Ubuntu live filesystems, is reasonably straightforward to run on a user machine. It is currently fairly specific to Ubuntu and its known derivatives, so it needs to have some more customisation facilities added to it: in particular it needs to be able to take a custom package list on its command line.
There are several suitable packages for managing local repositories, and there is clearly no need to invent another; reprepro seems to be a likely candidate.
New software
To start with, we will offer a simple command-line toolset, using a single top-level command with subcommands. We expect that a graphical interface may be added later if time permits.
The initial command set will be similar to the following:
- init
- set up a configuration directory and a local repository
- add-distribution
add a distribution (e.g. karmic) to the archive
- remove-distribution
- remove a distribution from the archive
- add-package
add packages (.changes files) to the archive
- remove-package
- remove packages from the archive
- add-metapackage
- build a metapackage depending on a given list of packages, and add it to the archive
- configure-image
- create or edit configuration for an image
- build-image
- build a live CD image for a distribution
- edit-image
- unpack an image, chroot into it, let the operator edit it, and save the result as a new image
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
Future work
It might make sense to rewrite livecd-rootfs in Python (it is currently written in shell) for better extensibility; or perhaps we should switch Ubuntu to live-helper. I think it is important that the software used for building customised images shares as much with the software used for building official Ubuntu images as possible, since that offers maximum probability of fixing common bugs in both rather than just in one.
FoundationsTeam/Specs/KarmicGoldenIsoImage (last edited 2009-06-17 13:26:41 by 82-69-40-219)