4 Managing Repositories with YaST SMT Server Management

SMT Management is a YaST module. To start the module, do one of the following:

The SMT Management application window opens with the Repositories tab active.

Figure 4.1: List of Repositories #

In the Repositories tab, you can see the list of all available package repositories for SMT. For each repository, the list shows the repository's name, target product and architecture, mirroring and staging flag, date of last mirroring, and a short description. You can sort the list by clicking the relevant column's header, and scroll the list items using the scrollbars on the window's right side.

4.2.1 Filtering Repositories #

You can also filter out groups of repositories with the Repository Filter text box. Enter the phrase that you want included in the repository name and click Filter. The list of repositories reduces depending on the given phrase. To cancel the filtering and display all repositories, erase the Repository Filter field and click Filter.

Figure 4.2: Repository Filter #

4.2.2 Mirroring Repositories #

Before you can start to offer package repositories, you need to create a local mirror of their packages. To do so, follow this procedure:

1. From the list, select the line containing the name of the repository you want to mirror.

2. Click the selected line to highlight it.

3. Click the Toggle Mirroring button in the lower left part of the window. In the Mirroring column of the selected repository, a check mark appears. If the repository was already selected for mirroring before, the check mark will disappear, and the repository will not be mirrored anymore.

4. Hit the Mirror Now button and the repository will be mirrored immediately.

5. A pop-up window appears with the information about mirroring status and result.

6. Click OK and the original window with the list of repositories will be refreshed.

Figure 4.3: Status of Mirroring Process #

After the mirroring is finished, you can stage the mirrored repositories. In SMT, staging is a process where you create either testing or production repositories based on the mirrored ones. The testing repository helps you examine the repository and its packages before you make them available in a production environment. To make repositories available for staging, do the following:

Important: Toggle Staging Button Not Active

You can only stage the repositories that were previously selected for mirroring. If it is not the case, the Toggle Staging button will not be active.

Once you mirror the repositories and make them available for staging, click the Staging tab. In the upper left part of the window, there is a Repository Name drop-down box of all repositories which are available for staging. There the repository names have the name of the staging group attached in parentheses. Select the one you want to stage and a list of packages of this repository appears below. Information about the patch name, its version and category, testing and production flags, and a short summary is available for each patch.

Next to the Repository Name drop-down box, there is a Patch Category filter. It helps you to list only the patches that belong to one of the predefined categories.

If the selected repository allows for patch filtering, you can toggle the status flag for individual patches. Do so by clicking the Toggle Patch Status button in the lower left part of the window.

Before creating a repository of packages that are available in the production environment, you need to create and test the testing repository. Click the Create Snapshot drop-down box and select the From Full Mirror to Testing menu item. A small pop-up window appears informing you about the staging process. After the testing repository snapshot is created, the relevant check marks in the Testing column will be displayed.

Figure 4.4: Testing Snapshot Created #

Important: Creating a Production Snapshot

After you enable staging for an update repository, you need to create its production snapshot to make it available to the clients. Otherwise the clients will not be able to find the update repository.

After you have examined the newly created testing repository, you can safely create a production one. Click the Create Snapshot drop-down box and select the From Testing to Production menu item. A small pop-up window appears informing you about linking the testing repository to the production one. After the production snapshot is created, the relevant check marks in the Production column will be displayed. Also, a green check mark appears in the Repository Name drop-down box.

For each client that is registered against the SMT server, SMT creates a job queue. To make use of the job queue, you need to install the smt-client package on the client. During the installation of the smt-client package, a cron job is created that runs the client executable /usr/sbin/smt-agent every three hours by default. The agent then asks the server if it has any jobs in the queue belonging to this client, and executes these jobs. When there are no more jobs in the queue, the agent terminates completely. It is important to understand that jobs are not pushed directly to the clients when they get created, and are not executed until the client asks for them in the preconfigured intervals of the cron job. Therefore, a delay of several hours may occur from the creation time of a job on the server until the job is executed on the client.

Every job can have a parent job, which means that the child job only runs after the parent job has successfully finished. It is also possible to configure advanced timing and recurrence/persistence of jobs. You can find more details about SMT jobs in Section 7.1.2.3, “smt-job”.

When creating jobs, you need to specify the GUID of the target clients using the -g GUID parameter. Although the -g parameter can be specified multiple times on a single command, there is no "wild card" functionality to assign a job to all clients.

Currently the following types of jobs are relevant:

Tip: Default Job Types

By default only 'softwarepush', 'patchstatus', and 'update' jobs are allowed. To allow more types of jobs, append the job type to the ALLOWED_AGENTS list in /etc/sysconfig/smt-client.

All clients that register against the SMT server automatically get a persistent 'patchstatus' job added to their job queue. This is also true for clients with no smt-clients package (SUSE Linux Enterprise 10 and older, or non-SUSE based distributions). These clients will appear with a patchstatus of "Unknown" in the client lists. The 'patchstatus' jobs for such clients are not required, and clients can safely be deleted to clean up the output of smt-job. Remember that if you update a machine to SUSE Linux Enterprise 11 or later, you will need to create the 'patchstatus' job manually.

Whenever the client runs a 'patchstatus' job, it compares the currently installed updates with what is available in the repositories on the SMT server. The job then reports back the number of missing patches that need to be installed in each of the four categories:

Tip: The --agreelicense Option

To install a package and its dependencies, the job type 'softwarepush' is used. When creating this type of job, it is handy to always add the --agreelicense option. The reason for this is that if a package displays a license agreement and expects it to be accepted, the job will skip the package if --agreelicense was not specified. The smt-client forwards the installation process to zypper, which does not consider a failed acceptance of a license agreement to be an error. This results in the job being completed successfully, even though the package may not be installed.

4.4.1 Checking the Client Status with YaST #

The Clients Status tab of the SMT Management window contains the status information about all the clients that use the repositories on your SMT server. It is divided into two main parts: the list of the clients and the detailed information.

You can read the client's host name, the date and time of the last network contact with the SMT server, and its update status. The update status can be one of the following:

Up-to-date

The client packages are updated to their last version available in the production repository.

Updates available

This status means that there are updates available for the client that are either optional or recommended.

Critical

Either security patches or package manager patches are available for the client.

In the lower part of the window, more detailed information about the selected client is available. It usually consists of extended status information and detailed information about the number and types of available updates.

Figure 4.5: Clients Status #

The date and time in the Last Contact column is the real last time contact of the server, even if it only ran the regular registration update script. This date is not the date of the last 'patchstatus' report. The command line tool smt-client prints the correct date and calls it Patch Status Date (smt-client -v prints both dates, the 'patchstatus' date and the last contact of the client system).

Note: Hidden Patches

Package manager patches can "hide" other patches, since they may be a prerequisite to other patches in such a way that these do not show up as available until the package manager patch(es) have been installed.