3 Mirroring Repositories on the SMT Server

Before you create a local mirror of the repositories, you need appropriate organization credentials. You can get the credentials from SUSE Customer Center.

To get the credentials from SUSE Customer Center, follow these steps:

The obtained credentials should be set with the YaST SMT Server Configuration module or manually written to the /etc/smt.conf file. For more information about the /etc/smt.conf file, see Section 7.2.1, “/etc/smt.conf”.

Tip: Merging Multiple Organization Site Credentials

SMT can only work with one mirror credential at a time; multiple credentials are not supported. If a customer creates a new company, it results in a new mirror credential. This is not convenient as some products are available via the first set and other products via the second set. To request a merge of credentials, the customer is advised to send an e-mail to <Customer_CenterEMEA@novell.com> (for EMEA-based customers only—Europe, the Middle East and Africa) with the applicable customer and site IDs. The EMEA PIC team will verify the records. The contact for NALAAP is <CustomerResolution@novell.com> (North America, Latin America, and Asia Pacific).

This section describes tools and procedures for viewing information about software repositories available through SMT, configuring these repositories and setting up custom repositories on the command line. For details on the YaST SMT Server Management module, see Chapter 4, Managing Repositories with YaST SMT Server Management.

tux:~ # smt-repos -o
.---------------------------------------------------------------------------------------------------------------------.
| Mirr| ID | Type | Name                    | Target        | Description                             | Can be M| Stag|
+-----+----+------+-------------------------+---------------+-----------------------------------------+---------+-----+
| Yes |  1 | zypp | ATI-Driver-SLE11-SP2    | --            | ATI-Driver-SLE11-SP2                    | Yes     | Yes |
| Yes |  2 | zypp | nVidia-Driver-SLE11-SP2 | --            | nVidia-Driver-SLE11-SP2                 | Yes     | No  |
| Yes |  3 | nu   | SLED11-SP2-Updates      | sle-11-x86_64 | SLED11-SP2-Updates for sle-11-x86_64    | Yes     | No  |
| Yes |  4 | nu   | SLES11-SP1-Updates      | sle-11-x86_64 | SLES11-SP1-Updates for sle-11-x86_64    | Yes     | Yes |
| Yes |  5 | nu   | SLES11-SP2-Core         | sle-11-x86_64 | SLES11-SP2-Core for sle-11-x86_64       | Yes     | No  |
| Yes |  6 | nu   | SLES11-SP2-Updates      | sle-11-i586   | SLES11-SP2-Updates for sle-11-i586      | Yes     | No  |
| Yes |  7 | nu   | WebYaST-Testing-Updates | sle-11-i586   | WebYaST-Testing-Updates for sle-11-i586 | Yes     | No  |
'-----+----+------+-------------------------+---------------+-----------------------------------------+---------+-----'

3.2.5 Deleting Mirrored Repositories #

You can delete mirrored repositories that are no longer used. If you delete a repository, it will be physically removed from the SMT storage area.

To delete a repository with a particular name, use the smt-repos --delete command. To delete the repository in a namespace, specify the --namespace dirname option.

--delete lists all repositories, and by entering the ID number or by entering the name and target you can delete the specified repositories. If you want to delete all repositories, enter a.

Note: Detecting Repository IDs

Every repository has a sha1sum that you can use as an ID. You can get the repository's sha1sum by calling smt-repos -v.

3.2.6 Mirroring Custom Repositories #

Using SMT you can also mirror repositories that are not available at the SUSE Customer Center. Those repositories are called “custom repositories”. Use the smt-setup-custom-repos command for this purpose. Custom repositories can also be deleted.

When adding a new custom repository, smt-setup-custom-repos adds a new record in the database, and sets the mirror flag to true by default. If needed, you can disable mirroring later.

To set up a custom repository to be available through SMT, follow these steps:

1. If you do not know the ID of the product the new repositories should belong to, use smt-list-products to get the ID. For the description of the smt-list-products, see Section 7.1.2.4, “smt-list-products”.

2. Run

   smt-setup-custom-repos --productid product_id \
   --name repository_name --exturl repository_url

   In this command product_id is the ID of the product the repository belongs to, repository_name represents the name of the repository and repository_url is the URL the repository is available at. In case the added repository needs to be available for more than one product, specify the IDs of all products that should use the added repository.

   For example, to set My repository available at http://example.com/My_repository to the products with the IDs 423, 424, and 425, use the following command:

   smt-setup-custom-repositories --productid 423 --productid 424 \
   --productid 425 --name 'My_repository' \
   --exturl 'http://example.com/My_repository'

Note: Mirroring Unsigned Repositories

In its default configuration, SUSE Linux Enterprise 10 does not allow the use of unsigned repositories. Therefore, if you want to mirror unsigned repositories and use them on client machines, be aware that the package installation tool—YaST or zypper—will ask you whether to use repositories that are not signed.

To remove an already-set custom repository from the SMT database, use smt-setup-custom-repositories --delete ID, where ID represents the ID of the repository to be removed.

The path to the directory containing the mirror is set by the MirrorTo option in the /etc/smt.conf configuration file. For more information about /etc/smt.conf, see Section 7.2.1, “/etc/smt.conf”. If the MirrorTo option is not set to the Apache htdocs directory /srv/www/htdocs/, the following links need to be created. In case the directories already exist, they need to be removed prior to creating the link (the data from those directories will be lost!):

The directory specified by the option MirrorTo and the subdirectories listed above must exist. Files, directories and links in /MirrorTo need to belong to the user smt and the group www.

For example, if the MirrorTo is set to /mirror/data:

l /srv/www/htdocs/repo/
total 16
lrwxrwxrwx 1 smt  www    22 Feb  9 14:23 $RCE -> /mirror/data/repo/$RCE/
drwxr-xr-x 4 smt  www  4096 Feb  9 14:23 ./
drwxr-xr-x 4 root root 4096 Feb  8 15:44 ../
lrwxrwxrwx 1 smt  www    23 Feb  9 14:23 RPMMD -> /mirror/data/repo/RPMMD/
lrwxrwxrwx 1 smt  www    22 Feb  9 14:23 full -> /mirror/data/repo/full/
drwxr-xr-x 2 smt  www  4096 Feb  8 11:12 keys/
lrwxrwxrwx 1 smt  www    25 Feb  9 14:23 testing -> /mirror/data/repo/testing/
drwxr-xr-x 2 smt  www  4096 Feb  8 14:14 tools/

The links can be created using the ln -s commands. For example:

for LINK in \$RCE RPMMD full testing; do
ln -s /mirror/data/repo/${LINK}/ && chown -h smt.www ${LINK}
done

Note: The /srv/www/htdocs/repo Directory

The /srv/www/htdocs/repo directory must not be a symbolic link.

The repository structure in the /srv/www/htdocs directory matches the structure as it comes from SUSE Customer Center. There are the following directories in the structure (selected examples, similar for other products and architectures):

repo/SUSE/Products/SLE-SDK/12/x86_64/product/

contains the -POOL repository of SDK (the GA version of all packages).

repo/SUSE/Products/SLE-SDK/12/x86_64/product.license/

contains EULA associated with the product.

repo/SUSE/Updates/SLE-SDK/12/x86_64/update/
repo/SUSE/Updates/SLE-SDK/12/s390x/update/
repo/SUSE/Updates/SLE-SERVER/12/x86_64/update/

contain update repositories for respective products.

repo/full/SUSE/Updates/SLE-SERVER/12/x86_64/update/
repo/testing/SUSE/Updates/SLE-SERVER/12/x86_64/update/

contain repositories optionally created for staging of respective repositories.

You can mirror repositories to a test environment instead of the production environment. The test environment can be used with a limited number of client machines before the tested repositories are moved to the production environment. The test environment can be run on the main SMT server.

The testing environment uses the same structure as the production environment, but it is located in the /srv/www/htdocs/repos/testing/ subdirectory.

To mirror a repository to the testing environment, you can use the Staging tab in the YaST SMT Management module, or the command smt-staging.

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

namespace: testing

To move the testing environment to the production environment, manually copy or move it using the cp -a or mv command.

You can enable “staging” for a repository in the Repositories tab of the SMT Management module or with the smt-repos command. The mirroring happens automatically to repo/full/.

If you have an 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 copy it into repo/testing/. After tests are finished you can copy the contents of repo/testing into the production area /repo.

SLE10-based update repositories are not supported by SMT tools. Not all of these repositories support selective staging. In this case you must mirror the complete package.

Recommended work flow:

repo => repo/full,
repo/full => repo/testing,
repo/testing => repo

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”.

Figure 3.1: SMT Staging Schema #

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 an SLE 11-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.

Although SUSE servers with software repositories are accelerated, deploying multiple SMT servers may become time consuming if each new SMT server must mirror the same repositories.

To save time when deploying new SMT servers, the repositories can be preloaded from another server/disk instead. Follow these steps:

Important: Possible Error Messages

Be prepared for errors such as repomd.xml is the same, but repo is not valid. Start mirroring. These errors occur, since the metadata about the preloaded repositories in the server's database is incorrect until this initial mirror of the repositories has completed.