Creating a YUM Repository and Publishing it with SMT

YUM (Yellow dog Updater, Modified) repositories are represented in XML where the repository metadata is stored in gzipped XML files in a repodata subdirectory – sibling to the rpm subdirectory. Repositories are described at Software Repositories.

Both SUSE Linux Enterprise (SLE) Desktop and Server 10 can be used to create the repository as the SLE 10 Software Development Kit 10 (SDK) installs on either of them and we need the createrepo package from the SLE 10 SDK.

The steps involved in this process are:

• create an RPM repository structure and populate it with packages
• use the createrepo utility to create the repository metadata
• sign and publish the repository
• setup mirroring of the repository in SMT
• enable non-interactive subscription to the catalog on clients

Create an RPM repository structure and populate it with packages

For the sake of simplicity this article describes a repository with a single, noarch package (hello_world) and its source RPM. Add or use other architectures like i586, x86_64 as needed.
Create the structure needed for the above with a command like the following:

# mkdir -p corp_updates/rpm/{noarch,src}

Now copy the RPM files to be part of the repository into their respective directories just created with your tool of choice.

In our example the structure of the repository at this point contains:

t60p:~/corp_updates # find
.
./rpm
./rpm/src
./rpm/src/hello_world-1.0-0.1.src.rpm
./rpm/noarch
./rpm/noarch/hello_world-1.0-0.1.noarch.rpm
t60p:~/corp_updates #

Use the createrepo utility to create the repository metadata

The createrepo tool is provided with the SLE 10 SDK, so make sure this has been installed as an add-on product on the SLE machine that is being used to set up the repository. Furthermore a working SLED/SLES installation source is required for providing the dependencies of the createrepo package.

When the SDK is present, the createrepo package can be installed via the YaST Software Management module.

Now go to the repository directory and invoke createrepo like this:

t60p:~/corp_updates # createrepo -v .
1/2 - rpm/src/hello_world-1.0-0.1.src.rpm
2/2 - rpm/noarch/hello_world-1.0-0.1.noarch.rpm
Saving Primary metadata
Saving file lists metadata
Saving other metadata
t60p:~/corp_updates #

This creates the metadata directory repodata/ and the standard files in there:

t60p:~/corp_updates # find repodata/
repodata/
repodata/filelists.xml.gz
repodata/repomd.xml
repodata/other.xml.gz
repodata/primary.xml.gz
t60p:~/corp_updates #

For more details on the RPM metada, see the following OpenSUSE page Standards/Rpm Metadata.

Sign and publish the repository

If the repository does not get signed, it will require manual intervention on the clients in order for them to accept and add it properly as an update service.

1. In order to sign the repomd.xml file a gpg key must be present. If you already have one that you would like to use – jump to step 3.
2. Create the gpg key with the command

   # gpg --gen-key

    

   Follow the instructions on the screen and choose a useful comment like e.g. “Repository key” during the key creation.

3. Sign repodata/repomd.xml file using the desired key with a command like

   # gpg -a --detach-sign --default-key "some-unique-part-of-the-uid-of-the-key" repodata/repomd.xml

    

   – e.g. :

   # gpg -a --detach-sign --default-key "Repository key" repodata/repomd.xml

    

   This leads to a dialog like the following :

   You need a passphrase to unlock the secret key for
   user: "Update Administration (Repository key) <updateadmin@mycompany.com>"
   1024-bit DSA key, ID 7ABED961, created 2008-10-09
   Enter passphrase:

4. Export the public key itself :

   # gpg -a --export "Repository key" > repodata/repomd.xml.key

    

5. With the repository being signed it is ready to be published. Do this on a web server which is reachable to the SMT server.
6. Verify the accessibility of the repository from the SMT server – e.g. with

   # wget <url-of-repository>/repodata/repomd.xml

    

It is important to note that the repomd.xml must be signed again each time the content of the repository changes and the repodata is regenerated. Since the key is already generated and exported to repodata/repomd.xml.key, this process only includes step 3 above.

Tip on gpg key handling :

The secret key is stored only on the server on which you carry out this procedure. In case the server and/or the .gnupg file with the key should lost or reinstalled, it is a good idea to export both the public and secret keys to a file, that is stored somewhere (more) safe. Do not forget to “back up” the password for the key as well ;-). This key file can then be imported on any other server and be used to re-sign the repository from there – by entering the password that was used to create the key.

To do this:

1. Export the (public and) secret keys into a file with a command like this :

   # gpg --armor --export-secret-keys "some-unique-part-of-the-uid-of-the-key" > updateadmin-secret.key

    

2. This file can then be imported on a different server with a command like the following :

   # gpg --import updateadmin-secret.key
   gpg: key 61AD4E31: secret key imported
   gpg: key 61AD4E31: public key "Update Administrator <updateadmin@mycompany.com>" imported
   gpg: Total number processed: 1
   gpg:               imported: 1
   gpg:       secret keys read: 1
   gpg:   secret keys imported: 1

    

The key is now ready to be used to sign files as described in steps 3 and 4 above.

Setup mirroring of the repository in SMT

When configuring custom catalogs to be mirrored with smt-mirror all catalogs must be associated to one or more Novell product IDs. This ID can be determined using the smt-list-products command:

# smt-list-products | grep SUSE-Linux-Enterprise-Server-SP2 | grep x86
|  824 | SUSE-Linux-Enterprise-Server-SP2            |      10 | x86_64       | -         |     5 |
|  839 | SUSE-Linux-Enterprise-Server-SP2            |      10 | x86_64       | online    |     0 |
|  809 | SUSE-Linux-Enterprise-Server-SP2-migration  |      10 | x86_64       | -         |     1 |

As can be seen from the output above there can be multiple IDs for the same product depending on the release, which basically represents the way that the SLE product has been installed. Base is installed directly and online is an upgraded product – e.g. a machine originally installed from SLES 10 SP1 medium and then online updated to SP2.

To determine the release of a SLE 10 SP2 product execute

# /usr/lib/zypp/zypp-query-pool products @system
i|product|SUSE_SLES_SP2|10.2-0|x86_64|SUSE-Linux-Enterprise-Server-SP2|10-SP2|base|SLES 10 SP2|SUSE Linux Enterprise Server 10 SP2

The 8th field is the release

base      = “-”    in smt-list-products
online    = online in smt-list-products

On SLE 11, the product determination is easier :

# zypper products --installed
Loading repository data...
Reading installed packages...
S | Name      | Version | Type
--+-----------+---------+-----
i | SUSE_SLES | 11-0    | base

So for the x86_64 based SLES 10 machine above (which was installed from SLES 10 SP2 medium) the product ID would be 824.

Given the catalog is published at http://download.my.company/corp_updates/ and it should be associated to x86_64-based SLES 10 SP2 machines the command to set it up for mirroring on an SMT server would look like this (all in one line):

# smt-setup-custom-catalogs --productid 824 \
--name "Internal_SLES10_SP2_UPDATES" \
--exturl "http://download.my.company/corp_updates" \
--description "Corporate SLES updates"

To associate a catalog with multiple product IDs, just add more –productid ID# parameters.
For more on setting up custom catalogs refer to smt-setup-custom-catalogs -h or section 2.5 in the SMT guide.

Now mirror the catalog with debug output to verify the details:

# smt-mirror -d -L /var/log/smt-mirror.log

Enable non-interactive subscription to the catalog on clients

In its default configuration SUSE Linux Enterprise 10 does not allow the use of unsigned repositories. This also counts for repositories signed with an unknown key, which is what applies to the scenario described in this document.

The directory /srv/www/htdocs/repo/keys/ is created during installation of SMT 1.1. When the SLE 11 clients register against the server, they check for key files in it and prompts the user to approve them. However it still requires user intervention.

So the clients still need to be configured to enable them to properly use the update service and see the packages in the catalog without requiring user interaction.

On SLE 10 and 11, the most secure option is to import the key – either during installation or later.

• During installation time using AutoYaST
  Add a post-script to the AutoYaST profile like the following:

    <scripts>
      <post-scripts config:type="list">
        <script>
          <filename>keyimport.sh</filename>
          <interpreter>shell</interpreter>
          <chrooted config:type="boolean">false</chrooted>
          <source><![CDATA[
            #!/bin/sh
            # Import repository key
            rpm --import http://mysmt/repo/keys/corpupdates.key
            ]]>
          </source>
        </script>
      </post-scripts>
    </scripts>

  The log file from the script will be stored in /var/adm/autoinstall/logs/.

• Post installation time :
  Import the key that was used to sign the repository into the client’s RPM database with this command :

  # rpm --import <url-of-key>

  e.g.:

  # rpm --import http://mysmt/repo/RPMMD/corp_updates/repodata/repomd.xml.key

On SLE 10 it is also possible to lower the security level check from signature to checksum in ZENworks Management Daemon (ZMD) by executing the following command on the client machines:

# rug set security-level checksum

This setting will generally allow subscription to any unsigned repository and may be a security concern of your company.

Now the configuration is complete.

Refreshing the update services on the clients with

SLE 10 : # rug refresh (or rug ca)
SLE 11 : # zypper refresh --services (or zypper ref -s)

should make the service appear in the list. If it does not, then perform a registration

# suse_register

and a refresh as described above.

The catalog should now be listed in the output of

SLE 10 : # rug catalogs (or rug ca)
SLE 11 : # zypper repos (or zypper lr)

If the client has an older version of any of the packages published through the catalog, these updates from the catalog can be seen with a

SLE 10 : # rug list-updates (or rug lu)
SLE 11 : # zypper list-updates (or zypper lu)

This is just one example of how to achieve the goal of establishing a YUM repository for application updates and automatically publishing it to clients that are registered against an in-house SMT server.

Feedback and suggestions for improvements are most welcome.

Changelog :
10 Dec 2009 : Adapted to include SLE 11 and SMT 1.1 info