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 Section 4.3, 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
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.
To enable or disable the staging use the smt-repos command with --enable-staging or -s:
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.
To create the testing repository in the
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 SLES11-SP1-Updates and SLES11-SP2-Updates of the sle-11-x86_64 architecture into one repository of a group:
smt-staging creategroup SLES11SP1-SP2-Up test-sp1-sp2 prod-sp1-sp2 smt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP1-Updates sle-11-x86_64 --testing smt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP2-Updates sle-11-x86_64 --testing smt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP1-Updates sle-11-x86_64 --production smt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP2-Updates sle-11-x86_64 --production
For group names, these characters are allowed: -_, a-zA-Z, and 0-9.
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
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.
To register a client in the testing environment, modify the /etc/suseRegister.conf on the client machine by setting:
register = command=register&namespace=testing