Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to Subscription Management Tool 11.3

3 Mirroring Repositories on the SMT Server

On the SMT server you can mirror the installation and update repositories locally. This allows you to bypass per-machine downloads and the bandwidth use that goes with it.

3.1 Mirroring Credentials

Before you create a local mirror of the repositories, you need appropriate organization credentials. You can get the credentials from Novell Customer Center or SUSE Customer Center, they are identical. To get the credentials from the Novell Customer Center, follow these steps:

  1. Visit Novell Customer Center at http://www.novell.com/center and log in.

  2. Click on My Products. The list of product families is shown.

  3. Expand any product family by clicking on its name. You can also expand all product families by clicking on the icon showing the arrow with two converse arrowheads (with the Expand All Product Families tool tip). Products in the expanded families are shown.

  4. Double click on any specific product in the list to show detailed information about the product.

  5. In the Downloads section, click on the Mirror Credentials link.

  6. If necessary (for example if you are accessing the page for the first time), click on the Generate button.

  7. The credentials and mirror sites will be listed. These values are the same for all users and subscriptions for a specific company.

    NU Credentials in Novell Customer Center
    Figure 3.1: NU Credentials in Novell Customer Center

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

  1. Visit SUSE Customer Center at http://scc.suse.com and log in.

  2. Click on Organization in the top menu.

  3. Click on the Organizational credentials tab.

  4. To show the password, click on Show password.

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”

To request a merge, the customer or their sales rep send an email to mailto:emea_pic@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 mailto:cmf@novell.com (North America, Latin America, and Asia Pacific).

3.2 Managing Software Repositories with SMT Command Line Tools

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.

3.2.1 Updating the local SMT database

The local SMT database needs to be updated periodically with the information downloaded from Novell Customer Center. These periodical updates can be configured with the SMT Management module, as described in Section 2.5, “Setting the SMT Job Schedule with YaST”.

To update the SMT database manually, use the smt-sync command. For more information about the smt-sync command, see Section 7.1.2.7, “smt-sync”.

3.2.2 Enabled Repositories and Repositories that Can Be Mirrored

The database installed with SMT contains information about all software repositories available on Novell Customer Center. However, the used mirror credentials determine which repositories can really be mirrored. For more information about getting and setting organization credentials, see Section 3.1, “Mirroring Credentials”.

The mirrorability of repositories is determined by retrieving https://nu.novell.com/repo/repoindex.xml using the provided organization credentials. Repositories that can be mirrored have the MIRRORABLE flag set in the repositories table in the SMT database.

The fact that a repository can be mirrored does not mean that it has to be mirrored. Only repositories with the DOMIRROR flag set in the SMT database will be mirrored. For more information about setting up, which repositories should be mirrored, see Section 3.2.4, “Selecting Repositories to be Mirrored”.

3.2.3 Getting Information About Repositories

Use the smt-repos command to list available software repositories and additional information. Using this command without any options lists all available repositories, including repositories that cannot be mirrored. In the first column, the enabled repositories (repositories set to be mirrored) are marked with Yes. Disabled repositories are marked with No. The other columns show ID, type, name, target, and description of the listed repositories. The last columns show whether the repository can be mirrored and staging is enabled.

Use the --verbose option, to get additional information about the URL of the repository and the path it will be mirrored to.

The repository listing can be limited to only repositories that can be mirrored or to enabled repositories. To list only repositories that can be mirrored, use the -m or --only-mirrorable option: smt-repos -m.

To list only enabled repositories, use the -o or --only-enabled option: smt-repos -o (see Example 3.1, “Listing All Enabled Repositories”).

Example 3.1: Listing All Enabled Repositories
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  |
'-----+----+------+-------------------------+---------------+-----------------------------------------+---------+-----'

You can also list only repositories with a particular name or show information about a repository with a particular name and target. To list repositories with a particular name, use the smt-repos repository_name command. To show information about a repository with a particular name and target, use the smt-repos repository_name target command.

To get a list of installation repositories from remote, see Section 8.6, “Listing Accessible Repositories”.

3.2.4 Selecting Repositories to be Mirrored

Only enabled repositories can be mirrored. In the database, the enabled repositories have the DOMIRROR flag set. Repositories can be enabled or disabled using the smt-repos command.

To enable one or more repositories, follow these steps:

  1. If you want to enable all repositories that can be mirrored or just choose one repository from the list of all repositories, run the smt-repos -e command.

    You are able to limit the list of repositories by using the relevant options. To limit the list to only repositories that can be mirrored, use the -m option: smt-repos -m -e. To limit the list to only repositories with a particular name, use the smt-repos -e repository_name command. To list only a repository with a particular name and target, use the command smt-repos -e repository_name target.

    If you want to enable all repositories belonging to a certain product, use the --enable-by-prod or -p option followed by the name of the product and, optionally, its version, architecture, and release:

    smt-repos -p product[,version[,architecture[,release]]]

    For example, to enable all repositories belonging to SUSE Linux Enterprise Server 10 SP4 for PowerPC architecture, use the following command:

    smt-repos -p SUSE-Linux-Enterprise-Server-SP4,10,ppc

    The list of known products can be obtained with the smt-list-products command.

  2. If more than one repository is listed, choose the one you want to enable by specifying its ID listed in the repository table and pressing Enter. If you want to enable all the listed repositories, use a and press Enter.

To disable one or more repositories, follow these steps:

  1. If you want to disable all enabled repositories or just choose one repository from the list of all repositories, run the smt-repos -d command.

    If you want to choose the repository to be disabled from a shorter list, or if you want to disable all repositories from a limited group, you can use any of the available options to limit the list of the repositories. To limit the list to only enabled repositories, use the -o option: smt-repos -o -d. To limit the list to only repositories with a particular name, use the smt-repos -d repository_name command. To list only a repository with a particular name and target, use the smt-repos -d repository_name target command.

  2. If more than one repository is listed, choose which one you want to disable by specifying its ID listed in the repository table shown and pressing Enter. If you want to disable all the listed repositories, use a and press Enter.

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
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 Novell 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
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, you have to allow this explicitly by executing the following command on the client machines:

rug set security-level checksum

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.

3.2.7 Mirroring SUSE Linux Enterprise Server 9 Repositories

For mirroring old style update repositories which were used for SUSE Linux Enterprise Server 9 and similar products, use a special command: smt-mirror-sle9. This command mirrors from the https://you.novell.com server. The download URL for SUSE Linux Enterprise Server 9 clients is following:

http(s)://example.com/repo/YOU9/<architecture>/update/<product>/<version>/

The smt-mirror-sle9 command does not store information about repositories to be mirrored in the SMT database. It only uses the configuration from the /etc/smt.conf file. The configuration of smt-mirror-sle9 is described in Section 7.2.1.7, “smt-mirror-sle9 Sections of /etc/smt.conf”.

The smt-mirror-sle9 command uses wget to mirror repositories. Therefore, you can exclude anything you do not want to be mirrored by adding the exclude_directories option to the /var/lib/smt/.wgetrc configuration file. For more information about wget and /var/lib/smt/.wgetrc, see man wget.

3.3 The /srv/www/htdocs Structure for SLE 11

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 that directories will be lost!). MIRRORTO has to be replaced with the path defined with MirrorTo:

  • /srv/www/htdocs/repo/$RCE should point to MIRRORTO/repo/$RCE/

  • /srv/www/htdocs/repo/RPMMD to MIRRORTO/repo/RPMMD/

  • /srv/www/htdocs/repo/testing to MIRRORTO/repo/testing/ and

  • /srv/www/htdocs/repo/full to MIRRORTO/repo/full/

The directory specified by the option MirrorTo and the subdirectories listed above must exist. Files and directories in /MirrorTo as well as the links 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:

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
Important: The /srv/www/htdocs/repo Directory

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

Important
Important: Apache and Symbolic Links

By default Apache on SUSE Linux Enterprise is configured to not follow symbolic links. To enable symblic links for /srv/www/htdocs/repo/ add the following snippet to /etc/apache2/default-server.conf (or the respetive virtual host configurtion 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

3.4 Using the Test Environment

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, modify the /etc/suseRegister.conf on the client machine by setting:

register = command=register&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 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 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

3.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 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 default staging group. You can create additional staging groups as needed with the smt-staging creategroup command.

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

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
Print this page