4.5 Testing and Filtering Update Repositories with Staging

You can test repositories on any clients with smt-staging before moving them to the production environment. You can select new update repositories manually to be installed on clients.

For staging, you can either use the smt-staging command, or use the YaST SMT Management module. For more details, see Staging Repositories.

Repositories with staging enabled are mirrored to the /MirrorTo/repo/full subdirectory. This subdirectory is usually not used by your clients. Incoming new updates are not automatically visible to the clients before you get a chance to test them. Later you can generate a testing environment of this repository, which goes to /MirrorTo/repo directory.

If you have a SLE11 based Update repository with patches, SMT tools can help you with the management. With these tools you can select patches and create a snapshot and put it into repo/testing/. After tests are finished you can put the content of repo/testing into the production area /repo. repo/testing/ and /repo is called the default staging group. You can create additional staging groups as needed with the smt-staging creategroup command.

NOTE: SLE 10 Based Update Repositories

SLE 10 based Update repositories are not supported by SMT tools. Not all of these repositories support selective staging. In this case you need to mirror the complete package.

Enabling Staging

To enable or disable the staging use the smt-repos command with --enable-staging or -s:

smt-repos --enable-staging

You can enable the required repositories by entering the ID number or by entering the name and target. If you want to enable all repositories enter a.

Generating Testing and Production Snapshots

To create the testing repository in the default staging group enter:

smt-staging createrepo Repository_ID -–testing

Now, you can test the installation and functionality of the patches in testing clients. If no problems are discovered during testing, create the production repository by entering:

smt-staging createrepo Repository_ID --production

To create testing and production repositories in a named staging group first create the group and then the repositories in this group:

smt-staging creategroup Groupname Testingdir Productiondir
smt-staging createrepo --group Groupname Repository_ID -–testing
smt-staging createrepo --group Groupname Repository_ID -–production

This can help you, if you for example, want to combine OES2018-Updates and OES2018-SP1-Updates of the sle-12-x86_64 architecture into one repository of a group:

smt-staging creategroup OES2018-SP0-SP1 test-sp0-sp1 prod-sp0-sp1 
smt-staging createrepo --group OES2018-SP0-SP1 \
OES2018-Updates sle-12-x86_64 --testing
smt-staging createrepo --group OES2018-SP0-SP1 \
OES2018-SP1-Updates sle-12-x86_64 --testing
smt-staging createrepo --group OES2018-SP0-SP1 \
OES2018-Updates sle-12-x86_64 --production
smt-staging createrepo --group OES2018-SP0-SP1 \
OES2018-SP1-Updates sle-12-x86_64 --production

For group names, these characters are allowed: -_, a-zA-Z, and 0-9.

Filtering Patches

You can allow or forbid all or selected patches with the allow or forbid commands by their ID or Category:

smt-staging forbid --patch ID
smt-staging forbid --category Categoryname

Signing Changed Repositories

If you filter one or more patches from a repository,the original signature becomes invalid. The repository needs to be signed again. The smt-staging createrepo command takes care of that automatically if you configure the SMT server.

In order to enable signing of changed metadata, the admin needs to generate a new signing key. This can be done with GPG like this:

mkdir some_dir
gpg --gen-key --homedir some_dir
sudo mv some_dir /var/lib/smt/.gnupg
sudo chown smt:users -R /var/lib/smt/.gnupg
sudo chmod go-rwx -R /var/lib/smt/.gnupg

Then, the ID of the newly generated key as seen in the gpg --gen-key command output, must be written into /etc/smt.conf, option signingKeyID.

At this point the clients do not know about this new key. In order to import the new key to clients during their registration, the following can be done:

sudo -u smt gpg --homedir /var/lib/smt/.gnupg \
  --export -a signingKeyID \
  > /MirrorTo/repo/keys/smt-signing-key.key

In this example, MirrorTo stands for the base directory where repositories will be mirrored. Once done, clients can import this key during the registration process.

Registering Clients in the Testing Environment

To register a client in the testing environment, modify the /etc/suseRegister.conf on the client machine by setting:

register = command=register&namespace=testing