KarmicGoldenIsoImage

Differences between revisions 2 and 3
Revision 2 as of 2009-06-17 12:00:40
Size: 4417
Editor: 82-69-40-219
Comment: user stories
Revision 3 as of 2009-06-17 12:56:41
Size: 5279
Editor: 82-69-40-219
Comment: assumptions; design
Deletions are marked like this. Additions are marked like this.
Line 31: Line 31:
 * 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 37:
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 67: Line 77:
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
Line 83: Line 83:

Encrypting data (may be necessary for people in sensitive environments):
 * just rely on ecryptfs?

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

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.

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

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

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.

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.

Unresolved 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

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


CategorySpec

FoundationsTeam/Specs/KarmicGoldenIsoImage (last edited 2009-06-17 13:26:41 by 82-69-40-219)