SUSE Support

Here When You Need Us

Configuring signing of staged repositories with SMT

This document (7005187) is provided subject to the disclaimer at the end of this document.

Environment

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

Situation

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.

Resolution

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
 

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7005187
  • Creation Date: 20-Jan-2010
  • Modified Date:22-Dec-2021
    • Subscription Management Tool
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

tick icon

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

tick icon

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

tick icon

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.