4 Mirroring Repositories on the SMT Server #

Before you create a local mirror of the repositories, you need appropriate organization credentials. You can obtain 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 added directly to the /etc/smt.conf file. For more information about the /etc/smt.conf file, see Section 8.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. When a customer creates a new company, this generates a new mirror credential. This is not always convenient, as some products are available via the first set and other products via the second set. To request a merge of credentials, contact your account manager.

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 5, 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  |
'-----+----+------+-------------------------+---------------+-----------------------------------------+---------+-----'

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

Use the smt-repos --delete command to delete a repository with a specific name. To delete the repository in a namespace, specify the --namespace DIRNAME option.

The --delete option lists all repositories. You can delete the specified repositories by entering the ID number or the name and target. To delete all repositories, enter a.

Note: Detecting Repository IDs

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

4.2.6 Mirroring Custom Repositories #

 

SMT also makes it possible to mirror repositories that are not available at the SUSE Customer Center. These repositories are called “custom repositories”, and they can be mirrored using the smt-setup-custom-repos command. It is also possible to delete custom repositories.

When adding a new custom repository, the smt-setup-custom-repos command inserts a new record in the database and sets the mirror flag to true. You can disable mirroring later, if necessary.

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 8.1.2.4, “smt-list-products”.

2. Run

   smt-setup-custom-repos --productid PRODUCT_ID \
   --name REPOSITORY_NAME --exturl REPOSITORY_URL

   PRODUCT_ID is the ID of the product the repository belongs to, REPOSITORY_NAME is the name of the repository, and REPOSITORY_URL is the URL of the repository. If 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, the following command sets My repository available at http://example.com/My_repository to the products with the IDs 423, 424, and 425:

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

Note: Mirroring Unsigned Repositories

By default, SUSE Linux Enterprise 10 does not allow the use of unsigned repositories. So 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 existing custom repository from the SMT database, use smt-setup-custom-repos --delete ID, where ID is 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 8.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. If the directories already exist, they need to be removed prior to creating the link (the data in these directories will be lost). In the following examples, MIRRORTO needs to be replaced by the path the option MirrorTo is set to.

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

Here is an example where 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:

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

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

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

Important: Apache and Symbolic Links

By default Apache on SUSE Linux Enterprise Server is configured to not follow symbolic links. To enable symbolic links for /srv/www/htdocs/repo/ add the following snippet to /etc/apache2/default-server.conf (or the respective virtual host configuration in case you are running SMT on a virtual host):

<Directory "/srv/www/htdocs/repo">
 Options FollowSymLinks
</Directory>

After having made the change, test the syntax and reload the Apache configuration files to activate the change:

rcapache2 configtest && rcapache2 reload

The repository structure in the /srv/www/htdocs directory matches the structure specified in 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 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/repo/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, follow these steps:

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 be used to manage them. Using these tools, you can select patches, 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 workflow:

customer center => repo/full => repo/testing, => repo/production

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

You can either use the smt-staging command or the YaST SMT Management module for staging. For more details, see Section 5.3, “Staging Repositories”.

Figure 4.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 the /MIRRORTO/repo directory.

If you have an SLE 11-based update repository with patches, you can use SMT tools to manage them. Using these tools, you can select patches, create a snapshot and put it into repo/testing/. After tests are finished, you can put the content of repo/testing into the /repo production area called the default staging group. You can create additional staging groups as needed using 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.

Deploying multiple SMT servers can take time 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 or disk instead. To do this, follow these steps:

Important: Possible Error Messages

Errors, such as repomd.xml is the same, but repo is not valid. Start mirroring., are considered normal. They occur because the metadata of the preloaded repositories in the server's database remains incorrect until the initial mirror of the repositories has completed.