NetworkWideUpdates

Revision 19 as of 2005-08-06 15:30:58

Clear message

NetworkWideUpdates

Status

Introduction

Network Wide Updates provide a framework that allows systems to have a central repository to get their software updates and new packages from.

Rationale

Network Wide Updates enable a framework that allows many systems on a network to get updated software packages from a central repository. Some thoughts behind it:

  • Not only saves bandwidth, but in an enterprise setting, all machines are kept up-to-date

  • apt-cacher solution ?

Scope and Use Cases

  • Need to be able to push updates to a (large) group of machines in one go, so we don't need to touch each one
  • Might want to install arbitrary local packages / archives on all machines
  • Need to conserve bandwidth in large environments (proxy/cache)

Implementation Plan

  • Big red button to deploy the updates
    • Package auto-pkg-update (depends on ssh-server) that creates a sudo user that can only run apt-get install" and setup a ssh configuration
      • instead of sudo we may write a small sudo application that will wrap the calls to apt-get (so that the sudo file does not too complicated and we can make sure that no options are passed to apt that makes it read a different configuration/sources.list so that a attacker can not install any package it wants)
      • Tricky: generating the package as it needs a ssh key, solution: have auto-pkg-update-source that will generate the binary package.

      • the package should setup/modify the sources.list of the clients too

      • add a note about the recommended proxy/cache
      • push individual packages
  • Proxy for the packages

    • Investigate the various apt-proxy programs, we should probably only make recommendations to the user, rather than automate this, since we wouldn't necessarily know where in their network they want a proxy and they also don't need a proxy for the other features to work (we probably don't want to encourage a mirror/partial mirror tool for bandwidth reasons):

      • apt-proxy

      • apt-cacher

      • squid (squid is reported to be a good candidate if the object size is set to a bigger size)

  • Tools for the creation of local repositories should be integrated. A a single button creates a Packages file and a Release file and signs it afterwards. It works on a per-directory basis. Repositories created like this need to integrate with the auto-pkg-update package and update the sources.list of all the clients).

Data Preservation and Migration

The package updates should be tested on a machine before the actual netwide deploy. In the general case, a rollback of a update is not possible because the {pre,post}inst scripts of the package works in general only in the upgrade direction not in the downgrade direction (when e.g. a database file is converted to a new format during a upgrade, a downgrade will result in a unreadable database file for the old version).

Packages Affected

One of the apt-cacher/apt-proxy packages is likely to be used for storing the packages on the server. ssh-server is needed on the clients to make it possible for the server to connect to the clients. The push should happen with a command line application. We may think about writing a front-end in python-gtk for it.

User Interface Requirements

Since we target network administrators, a command line UI should be sufficient. A optional pygtk interface may be useful. Additionally a webmin (html) kind of UI may be useful, but that opens some issue with security and should be targeted later.

Outstanding Issues

No work has been done yet. The various apt proxies/mirror solutions need to be investigated. Then the auto-pkg-update package needs to be written.

CategoryUdu CategorySpec