Ubuntu Wiki

Braindump - Oct 25

• SUS server = httpd(+mod_auth_krb5), client = apt/dpkg
• SUS server is an apt repo with kerb authentication (to authenticate clients)
• client computers separated into groups by repo "dists", ie. /myserver/dists/workstations or /myserver/dists/servers

User opens interface. His first task is to "Create a Repository". He does so, he names the repository, for example "dapper". This forms a new apt repository. He then adds 1 or more upstream repositories linked to this repository. Allow browsing Channels. For instance: dapper, dapper-security, dapper-updates. The repository is updated. It pulls each Release file, and each Packages.gz file of each component and creates it in the base file storage location for the repository (/var/lib/usus/repos/$name/proposed). This basically takes each Packages file, extracts and validates them, then merges each Package.gz from each configured upstream into one. Resulting in (/var/lib/usus/repos/$name/proposed/$component/$arch/Packages.gz) This Packages.gz would contain the contents of all of upstreams Packages.gz's for a given component/arch. It then generates new Release files. At some point a gpg key is created by the server and used to sign the files.

Each test client has something like "http://localserver/usus/dists dapper/proposed main" configured. This results in the client pulling updates from "http://localserver/usus/dists/dapper/proposed/main". These files of course contain the entire upstream Packages.gz. Clients post their complete dpkg -l list to "http://localserver/usus/dists/$dist/foo", or something. When the server receives one of these lists it scans the versions known in upstream, and determines what packages that particular client needs updated. It keeps track of new deps and recommends and such too. We can link to Smart to do this. Those packages go into a list of packages requring manual approval.

The admin comes around and examines the interface. He sees that some new versions of packages have been released and some clients have reported that they are needed. He limits the view to this. No need to approve updates nobody wants. He marks the updates he wants to approve. Smart is again used to determine what other updates are required by those updates, and those are marked as approved too. The non-proposed Package.gz files are generated based on ONLY approved packages. Clients can now pull those updates.

.deb files can be downloaded in the background for all approved updates, or async only when a client requests them. Whatever works.