Configuring signing of staged repositories with SMT

Subscription Management Tool 1.1
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Server 10 SP3
SUSE Linux Enterprise Server 10 SP2
SUSE Linux Enterprise Desktop 11
SUSE Linux Enterprise Desktop 1P2

In order to provide for fully utilizing the staging functionality in Subscription Management Tool 11 (SMT), a gpg key infrastructure needs to be set up.
When creating filtered testing snapshots of repositories on the server, the metadata about the patches in the repodata directory needs to be regenerated, since the content of the repository no longer matches what is specified in the original metadata that has been mirrored from SUSE.
In order for the clients to accept this non-SUSE generated repodata without requiring user intervention, the changed metadata must be signed anew with a gpg key, that is known to the clients.
The signing process requires both the public and private keys. Although the public part of the "SuSE Package Signing Key" used by SUSE is present on all SUSE Linux Enterprise hosts, the private part is obviously not publicly available.
For this reason a public/private key set must be generated and made available to the user account named "smt" on the SMT server. Furthermore the public key should be exported to a file located in the $MirrorTo/repo/keys/ directory, which gets searched for new keys during the client registration process.

This document describes how to get that working. Although the procedure involves quite a number of steps, it is not as complicated as it maybe appears at first glance.
In order to ensure proper functionality (read: at all), it is crucial that the smt package have been updated to version 1.1.17-0.7.4, which has been released in January 2010. Also the other updates from the SLE-11-SMT-Updates released in the same token should be applied.
 

1. Creation of the key pair. If a key pair is already available, skip to step 4.
   For the ease of explanation this should be done on the SMT server itself, although it could be done elsewhere.
   Invoke the gpg --gen-key command and create a key that has a resonable lifetime and name. The dialog would look like the following smt11c:~ # gpg --gen-key
   gpg (GnuPG) 2.0.9; Copyright (C) 2008 Free Software Foundation, Inc.
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.
   Please select what kind of key you want:
      (1) DSA and Elgamal (default)
      (2) DSA (sign only)
      (5) RSA (sign only)
   Your selection? 1
   DSA keypair will have 1024 bits.
   ELG keys may be between 1024 and 4096 bits long.
   What keysize do you want? (2048)
   Requested keysize is 2048 bits
   Please specify how long the key should be valid.
            0 = key does not expire
         <n>  = key expires in n days
         <n>w = key expires in n weeks
         <n>m = key expires in n months
         <n>y = key expires in n years
   Key is valid for? (0) 5y
   Key expires at Tue 13 Jan 2015 11:45:11 AM CET
   Is this correct? (y/N) y
   You need a user ID to identify your key; the software constructs the user ID
   from the Real Name, Comment and Email Address in this form:
       "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
   Real name: Mycompany repository signing key
   Email address: sysadm@mycompany.com
   Comment:
   You selected this USER-ID:
       "Mycompany repository signing key <sysadm@mycompany.com>"
   Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
   You need a Passphrase to protect your secret key.
   can't connect to `/root/.gnupg/S.gpg-agent': No such file or directory
   gpg-agent[27692]: directory `/root/.gnupg/private-keys-v1.d' created
   We need to generate a lot of random bytes. It is a good idea to perform
   some other action (type on the keyboard, move the mouse, utilize the
   disks) during the prime generation; this gives the random number
   generator a better chance to gain enough entropy.
   gpg: key 1F199A30 marked as ultimately trusted
   public and secret key created and signed.
   gpg: checking the trustdb
   gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
   gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
   gpg: next trustdb check due at 2015-01-13
   pub   1024D/1F199A30 2010-01-14 [expires: 2015-01-13]
         Key fingerprint = 7524 F463 045C CCD9 5544  2D19 2B5B 1BF2 1F19 9A30
   uid                  Mycompany repository signing key <sysadm@mycompany.com>
   sub   2048g/A4935BFB 2010-01-14 [expires: 2015-01-13]
   
   To speed up the prime generation, launch a command like

   # find /

   The key ID is the 8-digit hex number in the "pub" line - in the above example 1F199A30.
   
   Note the password in a safe place. It must be entered when creating testing snapshots.
2. Export the public and private key with commands like the following while specifying the key ID and useful filenames :

   # gpg -a --export 1F199A30 > /tmp/smt-repo-key.key
   # gpg -a --export-secret-keys 1F199A30 > /tmp/smt-repo-key-secret.key 

3. Setup gpg directory for the user smt with the following commands :

   # mkdir /var/lib/smt/.gnupg
   # chown -R smt.www /var/lib/smt/.gnupg
   # chmod -R 0700 /var/lib/smt/.gnupg

4. Import the public and private keys to the smt user's key store :

   # sudo -u smt gpg --import /tmp/smt-repo-key.key
   # sudo -u smt gpg --import /tmp/smt-repo-key-secret.key

5. Verify that the keys have been imported successfully with :

   # sudo -u smt gpg --list-keys
   # sudo -u smt gpg --list-secret-keys

6. Record the key ID from the above command (the ID changes during import).
7. Edit the /etc/smt.conf file and enter the key ID as the value of the signingKeyID parameter.
8. Place a copy of the public key in the $MirrorTo/repo/keys/ directory - e.g. with

   # cp /tmp/smt-repo-key.key /srv/www/htdocs/repo/keys/

9. Ensure that robots.txt is not blocking search of the keys directory.
   If the file robots.txt exists in the /srv/www/htdocs/ directory, insert this line :
   Allow: /repo/keys
   before the line containing
   Disallow: /
10. At this point the must can be imported on the clients in one of the following ways:
    • Invoke the clientSetup4SMT.sh script
    • Importing it with an RPM command like the following:

      # rpm --import http://<smt.mycompany.com>/repo/keys/<key-file-name>.key

    • In case the smt-client package is installed on the clients, it is also possible to create an execution job on the SMT server that imports the key like this :

      # smt-job -c --t execute -X "rpm --import http://<smt.mycompany.com>/repo/keys/smt-repo-key.key" -g <GUID-of-client> -g ….

      Then the key will be imported during the next time the smt-client agent polls the SMT server for work to do (every three hours).

Once the clients have imported the key, the setup is ready to be used.

Verify that the server part works as follows :

1. Invoke the SMT Server Management module and enable the desired patches to be included in the testing snapshot.
2. Create a snapshot "From Full Mirror to Testing". A "Signing Key Passphrase" dialog will appear prompting for the password of the key.
3. Once the snapshot has been created, open the log file /var/log/smt/smt-staging.log and verify that messages like the following appear in the messages from the last operation :
   2010-01-14 14:20:02 SMT::Mirror::RpmMd - [info]  /srv/www/htdocs/repo/testing/$RCE/SLE11-SMT-Updates/sle-11-x86_64/.repodata/repomd.xml has been signed.
   2010-01-14 14:20:02 SMT::Mirror::RpmMd - [info]  /srv/www/htdocs/repo/testing/$RCE/SLE11-SMT-Updates/sle-11-x86_64/.repodata/repomd.xml.key successfully generated.

Verify the client part :

1. Reconfigure /etc/suseRegister.conf on a client to register against the testing environment. This is done by appending "&namespace=testing" (without quotes) to the following line
   register   = command=register
   The line should look like this :
   register   = command=register&namespace=testing
2. Re-register the client :

   # suse_register

3. Once the registration is completed, perform a refresh of the repositories with

   # zypper ref -s

4. Verify that the URI of the repository is pointing to the testing structure with

   # zypper lr -u

5. Finally verify that it actually also can see the updates in the repository with

   # zypper lu

For more information about SMT, please refer to the Subscription Management Tool master TID