Configuring signing of staged repositories with SMT
This document (7005187) is provided subject to the disclaimer at the end of this document.
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
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.
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.
- 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) <email@example.com>"
Real name: Mycompany repository signing key
Email address: firstname.lastname@example.org
You selected this USER-ID:
"Mycompany repository signing key <email@example.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: 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 <firstname.lastname@example.org>
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.
- 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
- 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
- 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
- Verify that the keys have been imported successfully with :
# sudo -u smt gpg --list-keys # sudo -u smt gpg --list-secret-keys
- Record the key ID from the above command (the ID changes during import).
- Edit the /etc/smt.conf file and enter the key ID as the value of the signingKeyID parameter.
- 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/
- 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 :
before the line containing
- 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).
Verify that the server part works as follows :
- Invoke the SMT Server Management module and enable the desired patches to be included in the testing snapshot.
- Create a snapshot "From Full Mirror to Testing". A "Signing Key Passphrase" dialog will appear prompting for the password of the key.
- 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 :
- 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
- Re-register the client :
- Once the registration is completed, perform a refresh of the repositories with
# zypper ref -s
- Verify that the URI of the repository is pointing to the testing structure with
# zypper lr -u
- Finally verify that it actually also can see the updates in the repository with
# zypper lu
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
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com