Creating an Online Update Site and Publishing Patches

Overview

An Online Update Site is a web site used by SUSE Linux utilities to update software on users' systems. Online update sites 'extend' the built-in SUSE automatic update process to cover third-party updates as well as general SLE updates from Novell.

Partners who request driver kits from Novell will be provided with an online update site as part of the driver kit. Partners who create their own driver kits should create their own YUM patch repository, then place it on the URL they have chosen for their online update site. As partners develop new driver versions for customers, they can add patches to the online update site repository. The following information details how to create the initial online update site and how to update it with patches as necessary.

Definitions

Please see Driver Process Terminology.

Important Information

A Driver Process SLES10 partner online update site should meet two general requirements:

The site should contain current KMP versions, provided via patches.
The site should contain only patches/KMPs that are guaranteed to be compatible across the full range of systems that could be subscribed to the update site. In other words, before placing a patch (containing a new KMP version) on an online update site, a partner should be certain that the KMP will install and function correctly on any customer system which could have been automatically subscribed to the update site.

The above requirement #2 has significant implications for partners who wish to support their customers' migration from SLES 10 to SLES 10 SP1. Most KMPs built for SLES 10 SP1 will not install on SLES 10; therefore, partners must not place SLES 10 SP1 KMPs in online update sites which are intended to serve SLES 10 customers. To provide KMPS for their SLES 10 SP1 customers, partners will need to create new SP1-based online update sites.

In addition to providing a new SP1-based update site, partners can provide a patch (on their SLES10 partner update site) that will automatically migrate customers to the partner's new SP1-based site. Please refer to Migration to SP1 with Add-on and kmps for detailed information on how to migrate your SLES10 update site to a SLES10 SP1 update site.

General Approach

The first time a SLES10 partner online update site is created, it contains no patches or KMPs. It is simply created as a 'placeholder' so that when customers install a driver from a DUD/Add-on product or online install site, the installation process can automatically register the customer's system with the online update site.

Later, when there are new driver versions to provide to the customer, the partner creates patches and places them onto the online update site. The partner can add new patches as necessary; the online update site will host all the different patches in the same repository.

Step-by-Step Instructions

Creating the Initial "empty" YUM Repository

Create the YUM Repository

The initial online update site is created as an empty YUM repository: The repository will contain no KMPs or patches until the first update is provided through it.

Prerequisites:

ftp or http site configured with public read permission.

Create a staging directory on your local system.
In your staging directory, create the following directory structure:

Although the update site may be planned to include only specific architectures, it is not a problem to create empty placeholder directories.
On your local system, install the createrepo rpm from the SLES 10 SP1 SDK.
In your staging directory, run the createrepo script as follows: "createrepo ." This should create a "repodata" directory (containing the repository metadata files) in your staging directory.
Your initial YUM repository structure is complete.

Sign the YUM Repository

Note: If you do not sign your repository, the customer will be prompted to accept its use as an update site.

If you do not already have an established key, create one:

   gpg -q --gen-key

Get the value of this key (temporarily store it in the MY_KEY variable):

   MY_KEY=$( gpg --list-secret-keys | grep "^sec"|sed -e 's/.*\///;s/ .*//g;'  )

From within your staging directory, sign the repodata/repomd.xml file:

   gpg -a --detach-sign repodata/repomd.xml

Export your key:

   gpg -a --export "$MY_KEY" > repodata/repomd.xml.key

Test the YUM Repository

Using the SLES/SLED 10 YaST2->"Installation Sources" utility, add your staging directory as a local installation source. Since the repository does not contain any patches or KMPs, the test is complete.

Move the YUM Repository to the Host Site

Copy the entire contents of your staging directory to your host site.

Adding a Patch to the YUM Repository

Create a Staging Site

If your YUM repository already exists on your online update site, you need to create a local copy of it so that you can make your updates to a local copy:
- Create a staging directory on your local system.
- In your staging directory, place an exact copy of the YUM repository that is on your online update site.

Create the Patch

Prerequisites:
- KMPs intended to update existing KMPs on customer systems.
Place your updated KMPs in the appropriate architecture directories of your YUM repository.
Create a patch containing your updated KMPs:

    createpatch -i <patch-ID> -n <patch-name> -C <patch-category> -p KMP1,KMP2,KMP3,... -u .

Note 1: patch-ID should be a unique number w/ respect to the IDs for other patches in this repository. For instance, if the ID of the last patch created was 03, the ID for this patch might be "04".

Note 2: patch-name may be anything to describe the patch. Often, the patch name is simply set to the name of the package being updated.

Note 3: patch-category may be set to "recommended", "optional", etc. Pls. see createpatch -h for details.

Note 4: KMP1,KMP2,KMP3, etc. are the rpms to be installed by the patch. Each rpm should be listed by its rpm name, not including the version. Example: For the rpm intel-e1000-kmp-default-7.1.9_2.6.16.21-0.8, KMP1 would be "intel-e1000-kmp-default". Please note that one patch should generally include rpms for all different kernel flavors.

Note 5: You do not need to specify architectures; the patch will automatically include KMPs for all architectures.

Ignore the following warning/error messages:

     I/O error : failed to load external entity <KMP-name>    
     warning: failed to load external entity <KMP-name>

Your patch creation should be complete. A file patch-<patch-ID>-<patch-name>-<release>.xml should exist in your <staging>/repodata directory.

Test the Patch

Using the SLES/SLED 10 YaST2->"Installation Sources" utility, add your staging directory as a local installation source.
Using the Yast2->"Online Updates", ensure that the patches provided in your YUM repository are visible. Install the patches as necessary to ensure that they function as expected.

Move the Updated Patch Repository to the Host Site

Copy the entire contents of your staging directory to your host site.