Summary

Ubuntu Server customers for this feature have large (+200) installations, where IT has set processes and policies around software updates that employees must follow. These customers have no *easy* way to setup an internal package repository to deploy updates and customized packages to users. We would like to allow them to pick and choose which fixes are deployed internally, and have the ability to define staging and production policy-based groups.

Release Note

Setup of internal repositories with special policies is provided via the inteal repo script.

Rationale

Often the IT department wants to certify/test updates before they are rolled out to the company. This shoudl be a well supported operation.

User stories

Gerd is a IT admin for a network with 200 workstation. He wants to apply updates first to the IT department (~10 clients) and only if there are no issues there roll them out to the general public. The new system makes this easy.

Assumptions

Design

From the feedback we got from larger installations the common requirements are that the clients do not talk directly to archvie.ubuntu.com (or a mirror) but instead talk to a internal mirror.

Internal mirror

There should be a easy way to build a local mirror that is part of this framework. This internal mirror is then used as the basis to provide "views" into the mirror (see below).

Testing of updates

This internal mirror needs to support a pipeline approach for the updates.

The most common setup is:

The system should then allow propagation of individual package/groups of pacakge from one stage to the next based on certain criteria (that is up to the admin). This needs to take dependencies into account. A alternative approach is to not deal with packages individually but instead snapshot at a certain time and show the snapshoted archive.

Both mechanism require that the mirroring makes sure to keep packages around that are still referenced by some internal repository even if they got removed on the ubuntu archive.

Internal package

In addition a common requirement is to have a way to inject modified package and then blacklist certain packages from the repository. A example is a modified cups that gets installed on all machines but should never be replaced with the one from the archive.

Applying updates

A common mechanism how the updates can be applied on the client machine should be developed as well. If the clients shoudl update automatically and unattended, we should modify unattended-upgrades to make this use-case easy. If the users can choose the time to upgrade themself, but should not be able to get root on the machine or install new software we can provide a modified rapt (lp:~mvo/+junk/rapt). The repository signature generation and distribution is also part of this.

Implementation

We need to implement/adapt the following features:

  1. mirror
  2. repository views (unstable, testing, stable)
  3. interal repository tool
  4. client side updates

UI Changes

The current plan is to provide a commandline UI but the code should be done in a way that makes alernative UIs (like a web ui) easy to add.

Releated work

The mirror and the internal repository work can be shared with foundations-karmic-golden-iso-image specification


CategorySpec

FoundationsTeam/Specs/KarmicInternalRepositoryManagement (last edited 2009-06-18 14:03:36 by mvo)