The two-step SMT Configuration Wizard helps you configure SMT after SUSE Linux Enterprise Server installation is finished. You can then change the configuration later using the YaST SMT Server Configuration module—see Chapter 2, SMT Server Configuration.

This section contains information about upgrading SMT from the previous versions.

Important: Upgrade from Versions Prior to 11 SP3

Direct upgrade path from SMT prior to version 11 SP3 is not supported. You need to upgrade the operating system to SUSE Linux Enterprise Server 11 SP3 or SP4 as described in https://www.suse.com/documentation/sles11/book_sle_deployment/data/cha_update_sle.html, and at the same time upgrade SMT to version 11 SP3 as described in https://www.suse.com/documentation/smt11/book_yep/data/smt_installation_upgrade.html. Then follow the steps described in Section 1.2.2, “Upgrade from SMT 11 SP3”.

smt ncc-scc-migration

   smt sync
   smt mirror

SMT already includes the SLP service description file (/etc/slp.reg.d/smt.reg). To enable SLP announcements of the SMT service, open respective ports in your firewall and enable the SLP service.

sysconf_addword /etc/sysconfig/SuSEfirewall2 FW_SERVICES_EXT_TCP "427"
sysconf_addword /etc/sysconfig/SuSEfirewall2 FW_SERVICES_EXT_UDP "427"
insserv slpd
rcslpd start

YaST provides an easy way to activate or deactivate the SMT service. To activate SMT with YaST, follow these steps:

To deactivate SMT with YaST, follow these steps:

When activating SMT, the following important operations are performed by YaST:

When deactivating SMT, the following important operations are performed by YaST:

YaST provides an interface to set and test the download server credentials and the URL of the download server service. To do so, follow these steps:

Figure 2.1: Setting the Update Server Credentials with YaST #

For security reasons, SMT uses its own user in the database. YaST provides an interface for setting up or changing the SMT database password. To set or change the SMT database password with YaST, follow these steps:

YaST SMT provides an interface for setting up a list of e-mail addresses to which SMT reports will be sent. To edit this list of addresses, follow these steps:

The comma-separated list of addresses for SMT reports is written to the reportEmail option of the /etc/smt.conf configuration file.

The SMT Configuration module provides an interface to schedule periodic SMT jobs. YaST uses cron to schedule configured jobs. If needed, cron can be used directly. Five types of periodic jobs can be set:

Figure 2.3: SMT Job Schedule Configuration #

To configure the schedule of SMT jobs with YaST, follow these steps:

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, send an e-mail to <entitlements@suse.com>.

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 #Edit source

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 #Edit source

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.

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 #Edit source

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 #Edit source

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 #Edit source

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.

To list SMT-registered client machines, use the smt-list-registrations command. The following information is listed for each client: its Unique ID, Hostname, date and time of Last Contact with the SMT server, and the Software Product the client uses.

To delete a registration from SMT and SUSE Customer Center, use the following command. To delete multiple registrations, the option -g can be used several times.

smt-delete-registration -g Client_ID

The ID of the client machine to be deleted can be determined from the output of the smt-list-registrations command.

The smt-register command registers clients at SUSE Customer Center. All clients that are currently not registered or whose data has changed since the last registration are registered.

To register clients whose registration has failed, use the --reseterror option. This option resets the SCC registration error flag and tries to submit failed registrations again.

SMT module allows for the easy scheduling of client registrations. In the default configuration, registrations are scheduled to repeat every 15 minutes. To create or modify a new registration schedule, follow these steps:

Scheduling of SMT jobs in general is covered in Section 2.5, “Setting the SMT Job Schedule with YaST”.

YaST uses cron to schedule SUSE Customer Center registrations and other SMT jobs. If you do not want to use YaST, use cron directly.

To disable automatic registration, change the forwardRegistration value in the [LOCAL] section of the /etc/smt.conf configuration file to false.

To assist customers in monitoring their license compliance, SMT generates a weekly report based on data from SMT and SUSE Customer Center. This report contains information about statistics of the registered machines, products used, and of the active, expiring or missing license subscriptions. If subscriptions are about to expire and/or more SUSE Linux Enterprise machines are registered than you have purchased licenses for, the report contains relevant warnings.

In order to calculate the compliance, the smt-report tool by default downloads information about the subscriptions and registrations (can be disabled).

You can configure the recipient addresses for the reports on the Database and Reporting tab of the YaST Subscription Management Tool configuration module. All of the e-mail configuration options are located in the [REPORT] section of /etc/smt.conf and explained in Section 7.2.1.6, “[REPORT] Section of /etc/smt.conf”.

The scheduling of the reports is configured in /etc/cron.d/novell.com-smt while the parameters to use with the cron jobs are in the REPORT_PARAMS section of /etc/smt.d/smt-cron.conf.

To describe the content of the reports is beyond the scope of this section, but a set of reports can be split into five individual parts. By default, these reports are attached as individual files to the mail on the weekly report run. The alerts report is a normal text file while the others are in CSV format. The reports can also be created in PDF or XML by specifying --pdf or --xml as output format.

To generate a set of reports in CSV files based on local data and to display them in the standard output, run the following command:

Tip

The example stores the reports in the /root directory. You can change it to any other safe and writable directory.

smt-report --local --csv --file /root/smt-local-rep

The command generates the following files:

/root/smt-local-rep-product_subscription_active.csv
/root/smt-local-rep-product_subscription_alerts.txt
/root/smt-local-rep-product_subscription_expired.csv
/root/smt-local-rep-product_subscription_expiresoon.csv
/root/smt-local-rep-product_subscription_summary.csv

Note: Multiple SMT Servers

If you have multiple SMT servers deployed in your environment, the reports may not represent all of the SMT servers or machines in your environment. For the complete statistics of all your registered machines, refer to the information provided by SUSE Customer Center.

For more information about types of reports, output formats, and targets refer to Chapter 6, SMT Reports.

Generated SMT reports can be sent to a defined list of e-mail addresses periodically. To create or edit this list, and to set the frequency of the reports, use the YaST SMT Configuration module. How to configure this list is described in Section 2.4, “Setting E-mail Addresses to Receive Reports with YaST”. Configuration of the report schedule is described in Section 2.5, “Setting the SMT Job Schedule with YaST”.

The list can also be edited manually in the reportEmail option of the /etc/smt.conf configuration file. For more information about editing the list of addresses directly, see Section 7.2.1.6, “[REPORT] Section of /etc/smt.conf”. To set the frequency of reports manually, you can directly edit the smt-gen-report lines of the crontab in /etc/cron.d/novell.com-smt. For more information about the crontab format, see man 5 crontab.

Reports, including those created as a scheduled SMT job, are created by the smt-report command. This command has various parameters. To edit parameters used with scheduled commands, edit the /etc/smt.d/smt-cron.conf configuration file. For more information, see Section 7.2.2, “/etc/smt.d/smt-cron.conf”.

SMT reports can be printed to the standard output, exported to one or multiple files (in CSV format) and mailed to the defined list of e-mail addresses. Use the following options for the smt-report command:

Note: Disabling Sending Attachments

If you want to disable sending CSV attachments with report mails, edit the /etc/smt.d/smt-cron.conf configuration file as follows: remove the --attach option from the REPORT_PARAMS value. The default line reads: REPORT_PARAMS="--mail --attach -L /var/log/smt-report.log". To disable CSV attachments, change it to: REPORT_PARAMS="--mail -L /var/log/smt-report.log".

If you have disabled CSV attachments but need them occasionally, you can send them manually with the smt-report --mail --attach -L /var/log/smt-report.log command.

There are two important groups of SMT commands: The smt command with its sub-commands is used for managing the mirroring of updates, registration of clients, and reporting. The systemd smt.target is used for starting, stopping, restarting the SMT service and services that SMT depends on, and for checking their status.

7.1.1 SMT JobQueue #Edit source

Since SUSE Linux Enterprise version 11, there is a new SMT service called SMT JobQueue. It is a system to delegate jobs to the registered clients.

To enable JobQueue, the smt-client package needs to be installed on the SMT client. The client then pulls jobs from the server via a cron job (every 3 hours by default). The list of jobs is maintained on the server. Jobs are not pushed directly to the clients and processed immediately, but the client asks for them. Therefore, a delay of several hours may occur.

Every job can have its parent job, which sets a dependency. The child job only runs after the parent job successfully finished. Job timing is also possible: a job can have a start time and an expiration time to define its earliest execution time or the time the job will expire. A job may also be persistent. It is run repeatedly with a delay. For example, a patch status job is a persistent job that runs once a day. For each client, a patch status job is automatically generated after it registers successfully against an SMT 11 server. The patchstatus information can be queried with the smt-client command. For already registered clients, you can add patchstatus jobs manually with the smt-job command.

You can manipulate, list, create or delete the jobs. For this reason, the command line tool smt-job was introduced. For more details on smt-job, see Section 7.1.2.3, “smt-job”.

Note: Overriding the Automatic Creation of Patch Status Jobs

When creating a software push or an update job, normally a non-persistent patch status job will be added automatically with the parent id set to the id of the new job. To disable this behavior, use the --no-autopatchstatus option.

SMT is not intended to be a system to directly access the clients or to immediately report the results back; it is a longtime maintenance and monitoring system rather than a live interaction tool.

Note: Job Time Lag Limitation

The client will process one job at a time, report back the result, and then ask for the next job. If you create a persistent job with a time lag of only a few seconds, it will be repeated forever and block other jobs of this client. Therefore, adding jobs with a time lag smaller than one minute is not supported.

7.1.2 /usr/sbin/smt Commands #Edit source

The main command to manage the SMT is smt (/usr/sbin/smt). The smt command should be used together with various sub-commands described in this section. If the smt command is used alone, it prints a list of all available sub-commands. To get help for individual sub-commands, use smt subcommand --help.

The following sub-commands are available:

• smt-client

• smt-delete-registration

• smt-job

• smt-list-products

• smt-list-registrations

• smt-mirror

• smt-scc-sync

• smt-register

• smt-report

• smt-repos

• smt-setup-custom-repos

• smt-staging

• smt-support

• smt-sync

There are two syntax types you can use with the smt command: either use smt followed by a sub-command or use a single command (composed of smt, dash, and the sub-command of your choice). For example, it is possible to use either smt mirror or smt-mirror, as both have the same meaning.

Note: Conflicting Commands

Depending on your $PATH environment variable, the SMT smt command (/usr/sbin/smt) may collide with the smt command from the star package (/usr/bin/smt). Either use the absolute path /usr/sbin/smt, create an alias, or set your $PATH accordingly.

Another solution is to always use the smt- subcommand syntax (connected with a minus sign) instead of smt subcommand (separated by a space).

7.1.2.1 smt-client #Edit source

The smt-client command shows information about registered clients. The information includes:

• guid

• host name

• patch status

• time stamps of the patch status

• last contact with the SMT server

The smt-client understands the following options:

--verbose or -v

Show detailed information about the client. The last contact date is shown as well.

--debug or -d

Enable debugging mode.

--logfile or -Lfile

Specify the file the log will be written to.

--hostname or -hname

Only the entries whose host name begins with name will be listed.

--guid or -gguid

Only the entries whose GUID is guid will be listed.

--severity or -slevel

Filter the result by the patch status information. The value level can be one of 'packagemanager', 'security', 'recommended' or 'optional'. Only those entries are listed which have patches of the respective level.

7.1.2.2 smt-delete-registration #Edit source

The smt-delete-registration command deletes one or more registrations from SMT and SUSE Customer Center. It will unregister machines from the system. The following options are available:

--guid ID or -gID

Delete the machine with the guid ID from the system. You can use this option multiple times.

--debug or -d

Enable debugging mode.

7.1.2.3 smt-job #Edit source

The smt-job script manages jobs for individual SMT clients. You can list, create, edit, or delete jobs with it. The following options are available:

--list or -l

List all client jobs. This is the default if the operation mode switch is omitted.

--verbose or -vlevel

Show detailed information about a job or jobs in a list mode. The level value can be a number from 0 to 3. The bigger the value, the more verbose the command is.

--create or -c

Create a new job.

--edit or -e

Edit an existing job.

--delete or -d

Delete an existing job.

--guid or -gguid

Specify the client's guid. This parameter can be used multiple times to create a job for more than one client.

--jobid or -jid

Specify the job ID. You need to specify job ID and client's guid when editing or deleting a job, because the same job for multiple clients has the same job ID.

--deleteall or -Aid

Omit either the client's guid or the job ID in this delete operation. The missing parameter will match all respective jobs.

--type or -ttype

Specify the job type. The type can be one of 'patchstatus', 'softwarepush', 'update', 'execute', 'reboot', 'wait', 'eject'. On the client, only 'patchstatus', 'softwarepush' and 'update' are enabled by default.

--description description

Specify a job description.

--parentid

Specify the job ID of the parent job. Use it to describe a dependency. A job will not be processed until its parent has successfully finished.

--name or -n name

Specify a job name.

--persistent

Specify if a job is persistent. Non-persistent jobs are processed only once, while persistent jobs are processed again and again. Use --timelag to define the time that elapses until the next run.

--finished

Search option for finished jobs.

--targetedtime

Specify the earliest execution time of a job. Note that the job most likely will not run exactly at that point in time, but probably some minutes or hours after. The reason is that the client polls in a fixed interval for jobs.

--expirestime

Define when the job will no longer be executed anymore.

--timelagtime

Define the time interval for persistent jobs.

For a complete list of possible options and their explanation, see the manual page of the smt-job command (man smt-job).

7.1.2.3.1 Examples #Edit source

To list all finished jobs, enter the following:

smt-job --list --finished

To create a 'softwarepush' job that installs xterm and bash on client 12345 and 67890, enter the following:

smt-job --create -t softwarepush -P xterm -P bash -g 12345 -g 67890

To change the timing for a persistent job with job ID 42 and guid 12345 to run every 6 hours, enter the following:

smt-job --edit -j 42 -g 12345 --targeted 0000-00-00 --timelag 06:00:00

To delete all jobs with job ID 42, enter the following:

smt-job --delete -jobid 42 --deleteall

7.1.2.4 smt-list-products #Edit source

The smt-list-products script lists all software products in the SMT database. The following options are available:

--used or -u

Show only used products.

--catstat or -c

Show whether all repositories needed for a product are locally mirrored.

7.1.2.5 smt-list-registrations #Edit source

The smt-list-registrations script lists all registrations. There are two options available for this command.

--verbose or -v

Show detailed information about the registered devices.

--format or -fformat

Format the output. Possible types of formats are asciitable and csv.

7.1.2.6 smt-mirror #Edit source

The smt-mirror command performs the mirroring procedure and downloads repositories that are set to be mirrored.

You can run the smt-mirror with the following options:

--clean or -c

Remove all files no longer mentioned in the metadata from the mirror. No mirroring occurs before cleanup.

--debug or -d

Enable the debugging mode.

--deepverify

Turn on verifying of all package checksums.

--hardlink size

Search for duplicate files with a size greater than the size specified in kilobytes. Creates hard links for them.

--directory path

Define the directory to work on. If you use this option, the default value configured in the smt.conf configuration file is ignored.

--dbreplfile file

Define the path to the *.xml file to use as database replacement. You can create such a file with the smt-scc command.

--logfile file or -L file

Specify the path to a log file.

7.1.2.7 smt-sync #Edit source

The smt-sync or smt sync command gets data from SUSE Customer Center and updates the local SMT database. It can also save SUSE Customer Center data to a directory instead of the SMT database, or read the data from such a directory instead of downloading it from SUSE Customer Center itself.

For SUSE Linux Enterprise 11 clients, this script automatically decided whether Novell Customer Center or SUSE Customer Center would be used. Then smt-ncc-sync or smt-scc-sync was called, as appropriate. For SUSE Linux Enterprise 12 clients, only smt-scc-sync is supported.

7.1.2.8 smt-scc-sync #Edit source

The smt scc-sync command gets data from the SUSE Customer Center and updates the local SMT database. It can also save SUSE Customer Center data to a directory instead of the SMT database, or read SUSE Customer Center data from a directory instead of downloading it from SUSE Customer Center itself.

You can run the smt-scc-sync with the following options:

--fromdir directory

Read SUSE Customer Center data from a directory instead of downloading it from SUSE Customer Center.

--todir directory

Write SUSE Customer Center data to the specified directory without updating the SMT database.

Tip: SUSE Manager's Subscription Matching Feature

This data can be consumed by the subscription matching feature of SUSE Manager, which gives you a detailed overview of your subscription usage. For more information on the subscription matching feature, see https://www.suse.com/documentation/suse-manager-3/book_suma_reference_manual/data/ref_webui_audit_subscription.html

--createdbreplacementfile

Create a database replacement file for using smt-mirror without database.

--logfile file or -L file

Specify the path to a log file.

--debug

Enable debugging mode.

7.1.2.9 smt-register #Edit source

The smt-register or smt register command registers all currently unregistered clients at the SUSE Customer Center. It also registers all clients whose data has changed since the last registration.

The following options are available:

--logfile file or -L file

Specify the path to a log file.

--debug

Enable debugging mode.

7.1.2.10 smt-report #Edit source

The smt-report or smt report command generates a subscription report based on local calculation or SUSE Customer Center registrations.

The following options are available:

--mail or -m

Activate mailing the report to the addresses configured with the SMT Server and written in /etc/smt.conf. The report will be rendered as tables.

--attach or -a

Append the report to the e-mails in CSV format. This option should only be used together with the --mail option.

--quiet or -q

Suppress output to STDOUT and runs smt-report in quiet mode.

--csv or -c

The report will be exported to multiple files in CSV format. The first line of each *.csv file consists of the column names, then the data starts on line two. The --csv parameter should only be used together with the --file parameter. If the specified file name contains .csv as extension, the report format will be CSV (as if the --csv parameter was used).

--pdf or -p

The report will be exported in PDF format. Use it only together with the -file option.

--xml

The report will be exported in XML format. Use it only together with the -file option. For a detailed description of this XML format, see the manual page of the smt-report command.

--file or -F

Export the report to one or several files. By default, the report will be written to a single file rendered as tables. Optionally, the file name or whole path may be specified after the parameter: --file filename. If no file name is specified, a default file name containing a time stamp is used. However, SMT will not check if the file or files already exist.

In CSV mode the report will be written to multiple files, therefore the specified file name will expand to [path/]filename-reportname.extension for every report.

--logfile filename or -L filename

Specify path to a log file.

--debug

Enable debugging mode.

7.1.2.11 smt-repos #Edit source

You can use smt-repos (or smt repositories) to list all available repositories and for enabling, disabling, or deleting repositories. The following options are available:

--enable-mirror or -e

Enable repository mirroring.

--disable-mirror or -d

Disable repository mirroring.

--enable-by-prod or -p

Enable repository mirroring by giving product data in the following format: Product[,Version[,Architecture[,Release]]].

--disable-by-prod or -P

Disable repository mirroring by giving product data in the following format: Product[,Version[,Architecture[,Release]]].

--enable-staging or -s

Enable repository staging.

--disable-staging or -S

Disable repository staging.

--only-mirrorable or -m

List only repositories that can be mirrored.

--only-enabled or -o

List only enabled repositories.

--delete

List repositories and delete them from disk.

--namespace dirname

Delete the repository in the specified name space.

--verbose or -v

Show detailed repository information.

7.1.2.12 smt-setup-custom-repos #Edit source

The smt-setup-custom-repos or smt setup-custom-repos script is a tool to set up custom repositories (repositories not present in the download server) to be used with SMT. You can use this script to add a new repository to the SMT database or to delete a repository from the database. The script recognizes the following options:

--productid

ID of a product the repository belongs to. If a repository should belong to multiple products, use this option multiple times to assign the repository to all relevant products.

--name

The name of the custom repository.

--description

The description of the custom repository.

--exturl

The URL where this repository can be mirrored from. Only HTTP and HTTPS protocols are supported (no directory, file, or FTP).

--delete

Remove a custom repository with a given ID from the SMT database.

To set up a new repository, use the following command:

smt-setup-custom-repos --productid Product_ID \
--name Catalog_Name --exturl URL

For example:

smt-setup-custom-repos --productid 434 \
--name My_Catalog --exturl http://my.example.com/My_Catalog

To remove a configured repository, use the following command:

smt-setup-custom-repos --delete Catalog_ID

For example:

smt-setup-custom-repos --delete 1cf336d819e8e5904f4d4b05ee081971a0cc8afc

7.1.2.13 smt-staging #Edit source

A patch is an update of a package or group of packages. The term update and patch are often interchangeable. With the smt-staging script, you can set up patch filters for update repositories. It can also help you generate both testing repositories and repositories for the production environment.

The first argument of smt-staging is always the command. It must be followed by a repository. The repository can be specified by Name and Target from the table scheme returned by the smt-repos command. Alternatively, it can be specified by its Repository ID, which is returned when running the commend smt-repos -v. The smt-staging script understands the following commands:

listupdates

List available patches and their allowed/forbidden status.

allow/forbid

Allow or forbid specified patches.

createrepo

Generate both testing and production repository with allowed patches.

status

Give information about both testing and production snapshots, and patch counts.

listgroups

List staging groups.

There is always one group available with the name “default”. The default group has the path repo/full, repo/testing and repo. With creating a new group, new paths can be specified.

creategroup

Create a staging group. Required parameters are: group name, testing directory name, and production directory name.

removegroup

Remove a staging group. Required parameter is: group name.

The following options apply to any smt-staging command:

--logfile or -Lfile path

Write log information to the specified file. If it does not exist, it is created.

--debug or -d

Turn on the debugging output and log.

--verbose or -v

Turn more detailed output on.

The following options apply to specific smt-staging commands:

--patch

Specify a patch by its ID. You can get a list of available patches with the listupates command. This option can be used multiple times. Use it with the allow, forbid, and listupdates commands. If used with listupdates, the command will print detailed information about the specified patches.

--category

Specify the patch category. The following categories are available: 'security', 'recommended' and 'optional'. Use it with the allow, forbid, and listupdates commands.

--all

Allow or forbid all patches in the allow or forbid commands.

--individually

Allow or forbid multiple patches (for example by category) one by one, that is, as if the --patch option had been used on each of the patches.

--testing

Use with the createrepo command to generate a repository for testing. The repository will be generated from the full unfiltered local mirror of the remote repository. It will be written into the <MirrorTo>/repo/testing directory, where MirrorTo is the value taken from smt.conf.

--production

Use with the createrepo command to generate a repository for production use. The repository will be generated from the testing repository. It will be written into the <MirrorTo>/repo directory, where MirrorTo is the value taken from smt.conf. If the testing repository does not exist, the production repository will be generated from the full unfiltered local mirror of the remote repository.

--group

Specify on which group the command should work. The default for --group is the name default.

--nohardlink

During the repository creation with the createrepo command, avoid creating hard links instead of copying files. If not specified, hard links are created instead.

--nodesc

Do not print patch descriptions and summaries—to save some screen space and make the output more readable.

--sort-by-version

Sort the listupdates table by patch version. The higher the version, the newer the patch should be.

--sort-by-category

Sort the listupdates table by patch category.

7.1.2.14 smt-support #Edit source

The smt-support command manages uploaded support data usually coming from the supportconfig tool. You can forward the data to SUSE, either selectively or in full. This command understands the following options:

--incoming or -idirectory

Specify the directory where the supportconfig archives are uploaded. You can also set this option with the SMT_INCOMING environment variable. The default SMT_INCOMING directory is /var/spool/smt-support.

--list or -l

List the uploaded supportconfig archives in the incoming directory.

--remove or -rarchive

Delete the specified archive.

--empty or -R

Delete all archives in the incoming directory.

--upload or -uarchive

Upload the specified archive to SUSE. If you specify -s, -n, -c, -p, and -e options, the archive is repackaged with contact information.

--uploadall or -U

Upload all archives in the incoming directory to SUSE.

--srnum or -sSR number

Accept the Novell Service Request 11-digit number.

--name or -nname

Enter the first and last name of the contact, in quotes.

--company or -ccompany

Enter the company name.

--storeid or -did

Enter the store ID, if applicable.

--terminalid or -tid

Enter the terminal ID, if applicable.

--phone or -pphone

Enter the phone number of the contact person.

--email or -eemail

Enter the e-mail address of the contact.

The main SMT configuration file is /etc/smt.conf. You can set most of the options with the YaST SMT Server module. Another important configuration file is /etc/smt.d/smt-cron.conf, which contains parameters for commands launched as SMT scheduled jobs.

7.2.1 /etc/smt.conf #Edit source

The /etc/smt.conf file has several sections. The [NU] section contains the update credentials and URL. The [DB] section contains the configuration of the Maria DB database for SMT. The [LOCAL] section includes other configuration data. The [REPORT] section contains the configuration of SMT reports.

Warning: Passwords in Clear Text

The /etc/smt.conf file contains passwords in clear text, and its default permissions (640, root, wwwrun) make its content easily accessible with scripts running on the Apache server. Be careful with running other software on the SMT Apache server. The best policy is to use this server only for SMT.

7.2.1.1 [NU] Section of /etc/smt.conf #Edit source

The following options are available in the [NU] section:

NUUrl

URL of the update service. Usually it should contain the https://updates.suse.com/ URL.

NURegUrl

URL of the update registration service. It is used by smt-sync. If this option is missing, the URL from /etc/SUSEConnect is used as a fallback.

NUUser

NUUser should contain the user name for update service. For information about getting organization credentials, see Section 3.1, “Mirroring Credentials”. You can set this value with the SMT Server.

NUPass

NUPass is the password for the user defined in NUUser. For information about getting organization credentials, see Section 3.1, “Mirroring Credentials”. You can set this value with the SMT Server.

ApiType

ApiType is the type of service SMT uses; it can be either NCC for Novell Customer Center or SCC for SUSE Customer Center. The only supported value for SMT 12 is SCC.

7.2.1.2 [DB] Section of /etc/smt.conf #Edit source

The three options defined in the [DB] section are used for configuring the database for SMT. Currently, only Maria DB is supported by SMT.

config

The first parameter of the DBI->connect Perl method used for connection to the Maria DB database. The value should be in the form

dbi:mysql:database=smt;host=localhost

where smt is the name of the database and localhost is the host name of the database server.

user

The user for the database. The default value is smt.

pass

The password for the database user. You can set the password with the YaST SMT Server module.

7.2.1.3 [LOCAL] Section of /etc/smt.conf #Edit source

The following options are available in the [LOCAL] section:

url

The base URL of the SMT server which is used to construct URLs of the repositories available on the server. This value should be set by YaST automatically during installation. The format of this option should be: https://server.domain.tld/.

You can change the URL manually. For example, the administrator may choose to use the http:// scheme instead of https:// for performance reasons. Another reason may be using an alias (configured with CNAME in DNS) instead of the host name of the server, for example http://smt.domain.tld/ instead of http://server1.domain.tld/.

nccEmail

E-mail address used for registration at the SUSE Customer Center. The SMT administrator can set this value with the YaST SMT Server module.

MirrorTo

Determines the path to mirror to.

MirrorAll

If the MirrorAll option is set to true, the smt-sync script will set all repositories that can be mirrored to be mirrored (DOMIRROR flag).

MirrorSRC

If the MirrorSRC option is set to true, source RPM packages are mirrored.

Note: Default Value Changed with SMT 11 SP2

With SMT 11 SP2, the preset default value was changed to false. If you also want SMT to mirror source RPM packages on new installations, set MirrorSRC to true.

Upgraded systems are not affected.

forwardRegistration

For SMT 11, this option determined whether the clients registered at SMT should be registered at Novell Customer Center, too. This option does not work with SUSE Customer Center yet.

rndRegister

Specify a delay in seconds before the clients are registered at SUSE Customer Center. The value is a random number between 0 and 450, generated by the YaST SMT Server module. The purpose of this random delay is to prevent a high load on the SUSE Customer Center server that would occur if all smt-register cron jobs connected at the same time.

mirror_preunlock_hook

Specify the path to the script that will be run before the smt-mirror script removes its lock.

mirror_postunlock_hook

Specify the path to the script that will be run after the smt-mirror script removes its lock.

HTTPProxy

If you do not want to use global proxy settings, specify the proxy to be used for HTTP connection here. Use the following form: http://proxy.example.com:3128.

If the proxy settings are not configured in /etc/smt.conf, the global proxy settings configured in /etc/syconfig/proxy are used. You can configure the global proxy settings with the YaST Proxy module.

HTTPSProxy

If you do not want to use global proxy settings, specify the proxy to be used for HTTPS connection here. Use the form: https://proxy.example.com:3128.

If the proxy settings are not configured in /etc/smt.conf, the global proxy settings configured in /etc/syconfig/proxy are used. You can configure the global proxy settings with the YaST Proxy module.

ProxyUser

If your proxy requires authentication, specify a user name and password here, using the username:password format.

If the proxy settings are not configured in /etc/smt.conf, the global proxy settings configured in /etc/syconfig/proxy are used. You can configure the global proxy settings with the YaST Proxy module.

Tip: Global User Authentication Setting

If you configure the global proxy settings with YaST, manually copy /root/.curlrc to the home directory of the smt and adjust the permissions with the following commands as root:

cp /root/.curlrc /var/lib/smt/
chown smt:www /var/lib/smt/.curlrc

requiredAuthType

Specify an authentication type to access the repository. There are three possible types:

• none - no authentication is required. This is the default value.

• lazy - only user name and password are checked. A valid user can access all repositories.

• strict - checks also if the user has access to the repository.

smtUser

Specify a user name of a Unix user under which all smt commands will run.

signingKeyID

Specify the ID of the GPG key to sign modified repositories. The user specified under smtUser needs to have access to the key. If this option is not set, the modified repositories will be unsigned.

7.2.1.4 [REST] Section of /etc/smt.conf #Edit source

The following options are available in the [REST] section:

enableRESTAdminAccess

If set to 1, turns administrative access to the SMT RESTService on. Default value is 0.

RESTAdminUser

Specify the user name that the REST-Admin uses to log in. Default value is RESTroot.

RESTAdminPassword

Specify the password for the REST-Admin user. The option has no default value. An empty password is invalid.

7.2.1.5 [JOBQUEUE] Section of /etc/smt.conf #Edit source

The following options are available in the [JOBQUEUE] section:

maxFinishedJobAge

Specify the maximum age of finished non-persistent jobs in days. Default value is 8.

jobStatusIsSuccess

Specify a comma separated list of JobQueue status IDs that should be interpreted as successful. For more information about possible status IDs, see smt-job --help. Leaving this option empty is interpreted as default (1,4).

7.2.1.6 [REPORT] Section of /etc/smt.conf #Edit source

The following options are available in the [REPORT] section:

reportEmail

A comma separated list of e-mail addresses to send SMT status reports to. You can set this list with the YaST SMT Server module.

reportEmailFrom

From field of report e-mails. If not set, the default root@hostname.domainname will be used.

mailServer

Relay mail server. If empty, e-mails are sent directly.

mailServerPort

Port of the relay mail server set in mailServer.

mailServerUser

User name for authentication to the mail server set in mailServer.

mailServerPassword

Password for authentication to the mail server set in mailServer.

7.2.1.7 Example /etc/smt.conf #Edit source

Example 7.1: smt.conf #

[NU]
NUUrl=https://updates.suse.com/
NURegUrl=https://scc.suse.com/connect
NUUser = exampleuser
NUPass = examplepassword
ApiType = SCC

[DB]
config = dbi:mysql:database=smt;host=localhost
user = smt
pass = smt

[LOCAL]
# Default should be http://server.domain.top/
url = http://smt.example.com/
# This email address is used for registration at SCC
nccEmail = exampleuser@example.com
MirrorTo = /srv/www/htdocs
MirrorAll = false
MirrorSRC = false
forwardRegistration = true
rndRegister = 127
# The hook script that should be called before the smt-mirror script removes its lock
mirror_preunlock_hook = 
# The hook script that should be called after the smt-mirror script removed its lock
mirror_postunlock_hook = 
# specify proxy settings here, if you do not want to use the global proxy settings
# If you leave these options empty the global options are used.
# 
# specify which proxy you want to use for HTTP connection
# in the form http://proxy.example.com:3128
HTTPProxy = 
# specify which proxy you want to use for HTTPS connection
# in the form http://proxy.example.com:3128
HTTPSProxy = 
# specify username and password if your proxy requires authentication
# in the form username:password
ProxyUser = 
#
# require authentication to access the repository?
# Three possible authtypes can be configured here
# 1) none   : no authentication required (default)
# 2) lazy   : check only username and password. A valid user has access to all repositories
# 3) strict : check also if this user has access to the repository. 
#
requiredAuthType = none
#
# the smt commands should run with this unix user
#
smtUser = smt
#
# ID of the GPG key to be used to sign modified (filtered) repositories.
# The key must be accessible by the user who runs SMT, i.e. the user specified
# in the 'smtUser' configuration option.
#
# If empty, the modified repositories will be unsigned.
#
signingKeyID = 
#
# This string is sent in HTTP requests as UserAgent.
# If the key UserAgent does not exist, a default is used.
# If UserAgent is empty, no UserAgent string is set.
#
#UserAgent=
# Organization credentials for this SMT server.
# These are currently only used to get list of all available repositories
# from https://your.smt.url/repo/repoindex.xml
# Note: if authenticated as a client machine instead of these mirrorUser,
# the above URL returns only repositories relevant for that client.
mirrorUser = 
mirrorPassword = 

[REST]
# Enable administrative access to the SMT RESTService by setting enableRESTAdminAccess=1
# default: 0
enableRESTAdminAccess = 0
# Define the username the REST-Admin uses for login
# default: RESTroot
RESTAdminUser = RESTroot
# Define the password for the REST-Admin (note: empty password is invalid)
# default: <empty>
RESTAdminPassword = 

[JOBQUEUE]
# maximum age of finished (non-persistent) jobs in days
# default: 8
maxFinishedJobAge = 8
# comma separated list of JobQueue status IDs that should be interpreted as successful
# See smt-job --help for more information about possible Status IDs
# Please note: An empty string will be interpreted as default (1,4).
# default: 1,4
# useful:  1,4,6
jobStatusIsSuccess = 1,4

[REPORT]
# comma separated list of eMail addresses where the status reports will be sent to
reportEmail = exampleuser@example.com
# from field of report mails - if empty it defaults to "root@<hostname>.<domainname>"
reportEmailFrom = 
# relay mail server - leave empty if mail should be sent directly
mailServer = 
mailServerPort = 
# mail server authentication - leave empty if not required
mailServerUser = 
mailServerPassword =

For communication between the SMT server and client machines, the encrypted HTTPS protocol is used, requiring a server certificate. If the certificate is not available, or if clients are not configured to use the certificate, the communication between server and clients will fail.

Every client must be able to verify the server certificate by trusting the CA (certificate authority) certificate that signed the server certificate. Therefore, the SMT server provides a copy of the CA at /srv/www/htdocs/smt.crt. This CA can be downloaded from every client via the URL http://FQDN/smt.crt. The copy is created when YaST writes the SMT configuration. Whenever SMT is started with systemctl start smt.target, it checks the certificate. If a new CA certificate exists, it is copied again. Therefore, whenever the CA certificate is changed, restart SMT using the systemctl restart smt.target command.

When the SMT Server module applies configuration changes, it checks for the existence of the common server certificate. If the certificate does not exist, YaST asks whether the certificate should be created. If the user confirms, the YaST CA Management module is started.

Important: regcert Parameter Support

Note that the regcert kernel boot parameter is supported for SLE 10 and 11. It is not supported from SLE 12.

Any client can be configured to use SMT by providing the following kernel parameters during machine boot: regurl and regcert. The first parameter is mandatory, the latter is optional.

Warning: Beware of Typing Errors

Make sure the values you enter are correct. If regurl has not been specified correctly, the registration of the update source will fail.

If an invalid value for regcert has been entered, you will be prompted for a local path to the certificate. In case regcert is not specified, it will default to http://FQDN/smt.crt with FQDN being the name of the SMT server.

Warning: Change of SMT Server Certificate

If the SMT server gets a new certificate from an untrusted CA, the clients need to retrieve the new CA certificate file.

On SLE 10 and 11, this is done automatically with the registration process but only if a URL was used at installation time to retrieve the certificate, or if the regcert parameter was omitted and thus the default URL is used. If the certificate was loaded using any other method, such as floppy or local path, the CA certificate will not be updated.

On SUSE Linux Enterprise Server 12, after the certificate has changed, YaST displays a dialog for importing a new certificate. If you confirm importing the new certificate, the old one is replaced with the new one.

Clients can be configured to register with SMT server via AutoYaST profile. For general information about creating AutoYaST profiles and preparing automatic installation, refer to the AutoYaST Guide. In this section, only SMT specific configuration is described.

To configure SMT specific data using AutoYaST, follow the steps for the relevant version of SMT client.

In SLE 11 and 12, the /usr/share/doc/packages/smt/clientSetup4SMT.sh script is provided together with SMT. This script allows you to configure a client machine to use an SMT server. It can also be used to reconfigure an existing client to use a different SMT server.

Note: Installation of wget

The script clientSetup4SMT.sh itself uses wget, so wget must be installed on the client.

Important: Upgrade clientSetup4SMT.sh

If you migrated your client OS from an older SUSE Linux Enterprise, you need to check if the version of the clientSetup4SMT.sh script on your host is up to date. clientSetup4SMT.sh from older versions of SMT cannot manage SMT 12 clients. If you apply software patches regularly on your SMT server, you can always find the latest version of clientSetup4SMT.sh at <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

To configure a client machine to use SMT with the clientSetup4SMT.sh script, follow these steps:

The clientSetup4SMT.sh script works with SUSE Linux Enterprise 10 SP2 and later SPs, SLE 11, and SLE 12 systems.

This script is also provided for download. You can get it by running

wget http://smt.example.com/repo/tools/clientSetup4SMT.sh

Important: Extension and Module Registration in SUSE Linux Enterprise 12

When registering an existing system against SMT 12—both on the command line and using YaST—you need to register additional extensions and modules separately, one by one. This applies both to already installed extensions and to extensions that you plan to install.

Allow: /repo/keys

To configure a client to register against the test environment instead of the production environment, modify /etc/suseRegister.conf on the client machine by setting:

register = command=register&namespace=testing

For more information about using SMT with a test environment, see Section 3.5, “Using the Test Environment”.

To configure a client to register against the test environment instead of the production environment, modify /etc/SUSEConnect on the client machine by setting:

namespace: testing

For more information about using SMT with a test environment, see Section 3.5, “Using the Test Environment”.

To retrieve the accessible repositories for a client, download repo/repoindex.xml from the SMT server with the client's credentials. The credentials are stored in /etc/zypp/credentials.d/SCCcredentials (SUSE Linux Enterprise Server 12) or /etc/zypp/credentials.d/NCCcredentials (SUSE Linux Enterprise Server 11) on the client machine. Using wget, the command for testing could be as follows:

wget https://USER:PASS@smt.example.com/repo/repoindex.xml

repoindex.xml returns the complete repository list as they come from the vendor. If a repository is marked for staging, repoindex.xml lists the repository in the full namespace (repos/full/$RCE).

To get a list of all repositories available on the SMT server, use the credentials specified in the [LOCAL] section of /etc/smt.conf on the server as mirrorUser and mirrorPassword.

SUSE Linux Enterprise clients registered against SMT can be migrated online to the latest service pack of the same major release the same way as clients registered against SUSE Customer Center or Novell Customer Center. Before starting the migration, make sure that SMT is configured to provide the correct version of repositories to which you need the clients to migrate.

For detailed information on online migration, see https://www.suse.com/documentation/sles11/book_sle_deployment/data/cha_update_sle.html for SUSE Linux Enterprise 11 clients, or Book “Deployment Guide”, Chapter 18 “Upgrading SUSE Linux Enterprise” for SUSE Linux Enterprise 12 clients.

SMT enables customers that possess the required entitlements to mirror updates for Red Hat Enterprise Linux (RHEL). Refer to http://www.suse.com/products/expandedsupport/ for details on SUSE Linux Enterprise Server Subscription with Expanded Support. This section discusses the actions required to configure the SMT server and clients (RHEL servers) for this solution.

Note: SUSE Linux Enterprise Server 10

Configuring RHEL client with Subscription Management Tool for SUSE Linux Enterprise (SMT 1.0) running SUSE Linux Enterprise Server 10 is slightly different. For more information, see How to update Red Hat Enterprise Linux with SMT.

Creating backups of the SMT server regularly can help restore it quickly and reliably if the server fails.

There are three main areas on the SMT server to back up:

9.1.1 Configuration Files and Repositories #Edit source

The SMT server configuration is stored in the /etc/smt.conf file and files in the /etc/smt.d directory.

As SMT depends on the services provided by the Apache Web server and Maria DB database engine, you need to back up their configuration files as well. Apache's configuration files are located in the /etc/apache2 directory, while the configuration files for Maria DB are /etc/my.cnf, /etc/mysqlaccess.conf, and files in the /etc/my.cnf.d directory.

Package repositories are stored in the /srv/www/htdocs/repo directory. Although you can normally mirror the repositories on the restored server from the update server as well, the download can take a long time. Therefore backing up the repositories saves you time and bandwidth. Furthermore, backing up the repositories is necessary if you are using repository staging and want to restore the snapshots of the repositories (see Section 3.6, “Testing and Filtering Update Repositories with Staging”).

Warning: Size of the Repositories

The size of the software repositories can be huge and you will need to transfer them from the update server.

Use your preferred tool to back up the configuration and repository files.

mysqldump -u root -p smt_db_password smt > /backup_dir/smt-db-backup.sql

In some restricted environments it is not possible for SMT servers to access the Internet because they are located in disconnected or isolated networks. By using some special parameters on the SMT commands and a mobile disk, it is possible to accommodate for this.

You need to have one external SMT server that mirrors the repositories from SUSE Customer Center. Then you can 'mirror' these repositories to the SMT servers on the isolated network using the mobile storage medium.

Figure 9.1: SMT Disconnected Setup #

Although the initial setup of this solution requires additional configuration, the regular update synchronization with SUSE Customer Center and distribution to isolated servers is simple. The steps required during the initial setup consist of:

Day-to-day operation includes:

A detailed description of the individual steps follows:

Now the configuration of both the external and internal SMT servers is complete. However, the update repository is still empty. After you run the following daily operation routines for the first time, the repository will get synchronized, and the internal SMT server will be ready to serve clients.