subscription management tool for sles 12 sp4 - suse linux ... · 4 managing repositories with yast...

Subscription ManagementTool for SLES 12 SP4

SUSE Linux Enterprise Server 12 SP4

Subscription Management Tool for SLES 12 SP4SUSE Linux Enterprise Server 12 SP4by Tomáš Bažant, Jakub Friedl, and Florian Nadge

Publication Date: May 15, 2020

SUSE LLC10 Canal Park DriveSuite 200Cambridge MA 02141USA

https://www.suse.com/documentation

Copyright © 2006– 2020 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Docu-

mentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright

notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation

License”.

For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the prop-

erty of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates.

Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not

guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable

for possible errors or the consequences thereof.

https://www.suse.com/documentation

https://www.suse.com/company/legal/

Contents

About This Guide vii

1 SMT Installation 11.1 SMT Configuration Wizard 2

1.2 Upgrading from Previous Versions of SMT 4

Upgrade from SMT 12 SP1 5 • Upgrade from SMT 11 SP3 5

1.3 Enabling SLP Announcements 7

2 SMT Server Configuration 8

2.1 Activating and Deactivating SMT with YaST 9

2.2 Setting the Update Server Credentials with YaST 10

2.3 Setting SMT Database Password with YaST 12

2.4 Setting E-mail Addresses to Receive Reports with YaST 12

2.5 Setting the SMT Job Schedule with YaST 13

3 Mirroring Repositories on the SMT Server 163.1 Mirroring Credentials 16

3.2 Managing Software Repositories with SMT Command Line Tools 17

Updating the Local SMT Database 17 • Enabled Repositories and

Repositories That Can Be Mirrored 17 • Getting Information about

Repositories 17 • Selecting Repositories to Be Mirrored 18 • Deleting

Mirrored Repositories 20 • Mirroring Custom Repositories 20

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

3.4 The Structure of /srv/www/htdocs for SLE 12 23

3.5 Using the Test Environment 23

3.6 Testing and Filtering Update Repositories with Staging 24

iii SMT Guide

3.7 Repository Preloading 27

4 Managing Repositories with YaST SMT ServerManagement 29

4.1 Starting SMT Management Module 29

4.2 Viewing and Managing Repositories 29

Filtering Repositories 30 • Mirroring Repositories 30

4.3 Staging Repositories 31

4.4 Jobs and Client Status Monitoring 33

Checking the Client Status with YaST 35

5 Managing Client Machines with SMT 37

5.1 Listing Registered Clients 37

5.2 Deleting Registrations 37

5.3 Manual Registration of Clients at SUSE Customer Center 37

5.4 Scheduling Periodic Registrations of Clients at SUSE CustomerCenter 38

5.5 Compliance Monitoring 39

6 SMT Reports 41

6.1 Report Schedule and Recipients 41

6.2 Report Output Formats and Targets 42

7 SMT Tools and Configuration Files 44

7.1 Important Scripts and Tools 44

SMT JobQueue 44 • /usr/sbin/smt Commands 45 • SMT systemd

Commands 59

7.2 SMT Configuration Files 60

/etc/smt.conf 60 • /etc/smt.d/smt-cron.conf 68

iv SMT Guide

7.3 Server Certificates 69

Certificate Expiration 69 • Creating a New Common

Server Certificate 69 • Importing a Common Server

Certificate 71 • Synchronizing Time between SMT Server and Clients 72

8 Configuring Clients to Use SMT 73

8.1 Using Kernel Parameters to Access an SMT Server 74

8.2 Configuring Clients with AutoYaST Profile 76

Configuring SUSE Linux Enterprise 11 Clients 76 • Configuring SUSE Linux

Enterprise 12 Clients 77

8.3 Configuring Clients with the clientSetup4SMT.sh Script in SLE 11 and12 77

Problems Downloading GPG Keys from the Server 79

8.4 Configuring Clients with YaST 80

Configuring Clients with YaST in SLE 11 80 • Configuring Clients with YaST in

SLE 12 80

8.5 Registering SLE11 Clients against SMT Test Environment 81

8.6 Registering SLE12 Clients against SMT Test Environment 81

8.7 Listing Accessible Repositories 81

8.8 Online Migration of SUSE Linux Enterprise Clients 82

8.9 How to Update Red Hat Enterprise Linux with SMT 82

How to Prepare SMT Server for Mirroring and Publishing Updates for

RHEL 82 • How to Configure the YUM Client on RHEL 5.2 to Receive Updates

from SMT 83 • How to Configure the UP2DATE Client on RHEL 3.9 and

4.7 to Receive Updates from SMT 84 • How to Register RHEL 5.2 against

SMT 85 • How to Register RHEL 4.7 and RHEL 3.9 against SMT 85

9 Advanced Topics 87

9.1 Backup of the SMT Server 87

Configuration Files and Repositories 87 • The Database 88

9.2 Disconnected SMT Servers 88

v SMT Guide

A SMT REST API 93

B Documentation Updates 104

B.1 October 2018 (Documentation Maintenance Update for SUSE LinuxEnterprise Server 12 SP3) 104

B.2 September 2017 (Initial Release of SUSE Linux Enterprise Server 12SP3) 105

B.3 April 2017 (Documentation Maintenance Update for SUSE LinuxEnterprise Server 12 SP2) 105

B.4 November 2016 (Initial Release of SUSE Linux Enterprise Server 12SP2) 106

B.5 March 2016 (Documentation Maintenance Update for SUSE LinuxEnterprise Server 12 SP1) 107

B.6 December 2015 (Initial Release of SUSE Linux Enterprise Server 12SP1) 108

vi SMT Guide

About This Guide

Subscription Management Tool (SMT) for SUSE Linux Enterprise 12 SP4 allows enterprise cus-tomers to optimize the management of SUSE Linux Enterprise software updates and subscriptionentitlements. It establishes a proxy system for SUSE® Customer Center with repository (formerlyknown as catalog) and registration targets. This helps you centrally manage software updateswithin the firewall on a per-system basis, while maintaining your corporate security policiesand regulatory compliance.

SMT allows you to provision updates for all of your devices running a product based on SUSELinux Enterprise. By downloading these updates once and distributing them throughout the en-terprise, you can set more restrictive firewall policies. This also reduces bandwidth usage, asthere is no need to download the same updates for each device. SMT is fully supported and avail-able as a download for customers with an active SUSE Linux Enterprise product subscription.

Subscription Management Tool provides functionality that can be useful in many situations,including the following:

You want to update both SUSE Linux Enterprise and RedHat Enterprise Linux servers.

You want to get a detailed overview of your company's license compliance.

Not all machines in your environment can be connected to SUSE Customer Center to reg-ister and retrieve updates for bandwidth or security reasons.

There are SUSE Linux Enterprise hosts that are restricted and difficult to update withoutputting in place a custom update management solution.

You need to integrate additional software update external or internal repositories into yourupdate solution.

You are looking for a turnkey box staging solution for testing updates before releasingthem to the clients.

You want to have a quick overview of the patch status of your SUSE Linux Enterpriseservers and desktops.

vii SLES 12 SP4

FIGURE 1: SMT

1 Overview

The Subscription Management Tool Guide is divided into the following chapters:

SMT Installation

Introduction to the SMT installation process and the SMT Configuration Wizard. You willlearn how to install the SMT add-on on your base system during the installation processor on an already installed base system.

SMT Server Configuration

Description of the YaST configuration module SMT Server. This chapter explains how to setand configure organization credentials, SMT database passwords, and e-mail addresses tosend SMT reports, or set the SMT job schedule, and activate or deactivate the SMT service.

Mirroring Repositories on the SMT Server

Explanation of how to mirror the installation and update sources with YaST.

Managing Repositories with YaST SMT Server Management

Description of how to register client machines on SUSE Customer Center. The client ma-chines must be configured to use SMT.

viii Overview SLES 12 SP4

SMT Reports

In-depth look at generated reports based on SMT data. Generated reports contain statis-tics of all registered machines and products used and of all active, expiring, or missingsubscriptions.

SMT Tools and Configuration Files

Description of the most important scripts, configuration les and certificates supplied withSMT.

Configuring Clients to Use SMT

Introduction to configuring any client machine to register against SMT and download soft-ware updates from there instead of communicating directly with the SUSE Customer Cen-ter.

2 Additional Documentation and Resources

Chapters in this manual contain links to additional documentation resources that are availableeither on the system or on the Internet.

For an overview of the documentation available for your product and the latest documentationupdates, refer to http://www.suse.com/documentation .

3 Giving Feedback

Your feedback and contribution to this documentation is welcome! Several channels are avail-able:

Service Requests and Support

For services and support options available for your product, refer to https://www.suse.com/

support/ .To open a service request, you need a subscription at SUSE Customer Center. Go to https://

scc.suse.com/support/requests , log in, and click Create New.

ix Additional Documentation and Resources SLES 12 SP4

http://www.suse.com/documentation

https://www.suse.com/support/

https://www.suse.com/support/

https://scc.suse.com/support/requests

https://scc.suse.com/support/requests

Bug Reports

Report issues with the documentation at https://bugzilla.suse.com/ . To simplify thisprocess, you can use the Report Documentation Bug links next to headlines in the HTML ver-sion of this document. These preselect the right product and category in Bugzilla and adda link to the current section. You can start typing your bug report right away. A Bugzillaaccount is required.

Contributions

To contribute to this documentation, use the Edit Source links next to headlines in theHTML version of this document. They take you to the source code on GitHub, where youcan open a pull request. A GitHub account is required.For more information about the documentation environment used for this doc-umentation, see the repository's README (https://github.com/SUSE/doc-sle/blob/mas-

ter/README.adoc) .

Mail

Alternatively, you can report errors and send feedback concerning the documentation [email protected] . Make sure to include the document title, the product version andthe publication date of the documentation. Refer to the relevant section number and title(or include the URL) and provide a concise description of the problem.

4 Documentation ConventionsThe following notices and typographical conventions are used in this documentation:

/etc/passwd : directory names and le names

PLACEHOLDER : replace PLACEHOLDER with the actual value

PATH : the environment variable PATH

ls , --help : commands, options, and parameters

user : users or groups

package name : name of a package

Alt , Alt – F1 : a key to press or a key combination; keys are shown in uppercase as ona keyboard

File, File Save As: menu items, buttons

x Documentation Conventions SLES 12 SP4

https://bugzilla.suse.com/

https://github.com/SUSE/doc-sle/blob/master/README.adoc

https://github.com/SUSE/doc-sle/blob/master/README.adoc

x86_64 This paragraph is only relevant for the AMD64/Intel 64 architecture. The arrowsmark the beginning and the end of the text block. System z, POWER This paragraph is only relevant for the architectures z Systems andPOWER . The arrows mark the beginning and the end of the text block.

Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter inanother manual.

Commands that must be run with root privileges. Often you can also prefix these com-mands with the sudo command to run them as non-privileged user.

root # commandtux > sudo command

Commands that can be run by non-privileged users.

tux > command

Notices

Warning: Warning NoticeVital information you must be aware of before proceeding. Warns you about securityissues, potential loss of data, damage to hardware, or physical hazards.

Important: Important NoticeImportant information you should be aware of before proceeding.

Note: Note NoticeAdditional information, for example about differences in software versions.

Tip: Tip NoticeHelpful information, like a guideline or a piece of practical advice.

xi Documentation Conventions SLES 12 SP4

1 SMT Installation

SMT is included in SUSE Linux Enterprise Server starting with version 12 SP1. To install it, startSUSE Linux Enterprise Server installation, and click Software on the Installation Settings screen.Select the Subscription Management Tool pattern on the Software Selection and System Tasks screen,then click OK.

FIGURE 1.1: SMT PATTERN

Tip: Installing SMT on an Existing SystemTo install SMT on the existing SUSE Linux Enterprise Server system, run YaST Soft-ware Software Management, select View Patterns and select the SMT pattern there.

It is recommended to check for available SMT updates immediately after installing SUSE LinuxEnterprise Server using the zypper patch command. SUSE continuously releases maintenanceupdates for SMT, and newer packages are likely to be available.

After the system is installed and updated, perform an initial SMT configuration using YaST Net-work Services SMT Configuration Wizard.

1 SLES 12 SP4

Note: Install smt-clientThe smt-client package needs to be installed on clients connected to the SMT server.The package requires no configuration, and it can be installed using the sudo zypperin smt-client command.

1.1 SMT Configuration Wizard

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

1. The Enable Subscription Management Tool service (SMT) option is enabled by default. Toggleit only if you want to disable the SMT product.If the firewall is enabled, enable Open Port in Firewall to allow access to the SMT servicefrom remote computers.Enter your SUSE Customer Center organization credentials in User and Password. If you donot know your SUSE Customer Center credentials, refer to Section 3.1, “Mirroring Credentials”.Test the entered credentials using the Test button. SMT will connect to the Customer Centerserver using the provided credentials and download testing data.Enter the e-mail address you used for the SUSE Customer Center registration into SCC E-mail Used for Registration.Your SMT Server URL should contain the URL of the SMT server being configured. It ispopulated automatically.Click Next to continue to the second configuration step.

2 SMT Configuration Wizard SLES 12 SP4

FIGURE 1.2: SMT WIZARD

2. For security reasons, SMT requires a separate user to connect to the database. In the Data-base Password for smt User screen, set the database password for this user.Enter all e-mail addresses for receiving SMT reports using the Add button. Use the Editand Delete buttons to modify and delete the existing addresses. When you have done that,click Next.

3. If the current database root password is empty, you will be prompted to specify it.

4. By default, SMT is set to communicate with the client hosts via a secure protocol. Forthis, the server needs to have a server SSL certificate. The wizard displays a warning ifthe certificate does not exist. You can create a certificate using the Run CA Managementbutton. Refer to Book “Security Guide”, Chapter 17 “Managing X.509 Certification”, Section 17.2

“YaST Modules for CA Management” for detailed information on managing certificates withYaST.

3 SMT Configuration Wizard SLES 12 SP4

FIGURE 1.3: MISSING SERVER CERTIFICATE

1.2 Upgrading from Previous Versions of SMT

This section provides information on upgrading SMT from the previous versions.

4 Upgrading from Previous Versions of SMT SLES 12 SP4

Important: Upgrade from Versions Prior to 11 SP3A direct upgrade path from SMT prior to version 11 SP3 is not supported. You need todo the following:

1. Upgrade the operating system to SUSE Linux Enterprise Server 11 SP3 or SP4 asdescribed at https://www.suse.com/documentation/sles11/book_sle_deployment/da-

ta/cha_update_sle.html .

2. At the same time upgrade SMT to version 11 SP3 as describedat https://www.suse.com/documentation/smt11/book_yep/data/smt_installation_up-

grade.html .

3. Follow the steps described in Section 1.2.2, “Upgrade from SMT 11 SP3”.

1.2.1 Upgrade from SMT 12 SP1

Upgrade from SMT 12 SP1 is performed automatically during the SUSE Linux Enterprise Serverupgrade and requires no additional manual steps. For more information on SUSE Linux Enter-prise Server upgrade, see Book “Deployment Guide”, Chapter 19 “Upgrading SUSE Linux Enterprise”.

1.2.2 Upgrade from SMT 11 SP3

To upgrade SMT from version 11 SP3 to 12 SP2, follow the steps below.

1. If you have not already done so, migrate from Novell Customer Center to SUSE CustomerCenter as described in Section 1.2.2.1, “Migration to SUSE Customer Center on SMT 11 SP3”.

2. Back up and migrate the database. See the general procedure in Book “Deployment Guide”,

Chapter 19 “Upgrading SUSE Linux Enterprise”, Section 19.3.4 “Migrate your MySQL Database”.

3. Upgrade to SUSE Linux Enterprise Server 12 SP2 as described in Book “Deployment Guide”,

Chapter 19 “Upgrading SUSE Linux Enterprise”.

4. Look if the new /etc/my.cnf.rpmnew exists and update it with any custom changes youneed. Then copy it over the existing /etc/my.cnf :

cp /etc/my.cnf.rpmnew /etc/my.cnf

5 Upgrade from SMT 12 SP1 SLES 12 SP4

https://www.suse.com/documentation/sles11/book_sle_deployment/data/cha_update_sle.html


https://www.suse.com/documentation/smt11/book_yep/data/smt_installation_upgrade.html

https://www.suse.com/documentation/smt11/book_yep/data/smt_installation_upgrade.html

5. Enable the smt target to start at the system boot:

systemctl enable smt.target

Start it immediately, if necessary:

systemctl start smt.target

1.2.2.1 Migration to SUSE Customer Center on SMT 11 SP3

Before upgrading to SUSE Linux Enterprise Server 12, you need to switch the registration centeron SUSE Linux Enterprise Server 11. SMT now registers with SUSE Customer Center instead ofNovell Customer Center. You can do this either via a YaST module or command line tools.

Before performing the switch between customer centers, make sure that the target customercenter serves all products that are registered with SMT. Both YaST and the command line toolsperform a check to nd out whether all products can be served with the new registration server.

To perform the migration to SUSE Customer Center via command line, use the following com-mand:

smt ncc-scc-migration

The migration itself takes time, and during the migration process the SMT server may not beable to serve clients that are already registered.

The migration process itself changes the registration server and the proper type of API in theconfiguration les. No further (configuration) changes are needed on the SMT.

To migrate from Novell Customer Center to SUSE Customer Center via YaST, use the YaST smt-server module.

When migration has been completed, it is necessary to synchronize SMT with the customercenter. It is recommended to ensure that the repositories are up to date. This can be done usingthe following commands:

smt sync smt mirror

6 Upgrade from SMT 11 SP3 SLES 12 SP4

1.3 Enabling SLP AnnouncementsSMT includes the SLP service description le ( /etc/slp.reg.d/smt.reg ). To enable SLP an-nouncements of the SMT service, open respective ports in your firewall and enable the SLPservice:

sysconf_addword /etc/sysconfig/SuSEfirewall2 FW_SERVICES_EXT_TCP "427"sysconf_addword /etc/sysconfig/SuSEfirewall2 FW_SERVICES_EXT_UDP "427"systemctl enable slpd.servicesystemctl start slpd.service

7 Enabling SLP Announcements SLES 12 SP4

2 SMT Server Configuration

This chapter introduces the YaST configuration module for the SMT server. This module can beused to set and configure mirroring credentials, SMT database passwords, and e-mail addressesfor receiving SMT reports. The module also lets you set the SMT job schedule, and activate ordeactivate the SMT service.

To configure SMT with SMT Server Configuration, follow the steps below.

1. Start the YaST module SMT Server Configuration from the YaST control center or by runningyast smt-server from the command line.

2. To activate SMT, toggle the Enable Subscription Management Tool Service (SMT) option inthe Customer Center Access section. For more information about activating SMT with YaST,see Section 2.1, “Activating and Deactivating SMT with YaST”.

3. If the firewall is enabled, activate Open Port in Firewall.

4. In the Customer Center Configuration section of Customer Center Access, you can set the cus-tom server URLs. Set and test credentials for the SUSE Update service. Correct credentialsare necessary to enable mirroring from the download server and determine the productsthat should be mirrored. Also set the e-mail address used for the registration and the URLof your SMT server. For more information, see Section 2.2, “Setting the Update Server Creden-

tials with YaST”.

5. In the Database and Reporting section, set the password for the SMT user in the Maria DBdatabase and specify e-mail addresses for receiving reports. For more information, seeSection 2.3, “Setting SMT Database Password with YaST” and Section 2.4, “Setting E-mail Addresses

to Receive Reports with YaST”.

6. In the Scheduled SMT Jobs section, set a schedule for SMT jobs, such as synchronization ofupdates, SUSE Customer Center registration, and SMT report generation. For more infor-mation, see Section 2.5, “Setting the SMT Job Schedule with YaST”.

7. When you are satisfied with the configuration, click OK. YaST updates the SMT configu-ration and starts or restarts necessary services.If you want to abort the configuration and cancel any changes, click Cancel.

8 SLES 12 SP4

Note: Check for CertificateWhen the SMT Configuration applies changes, it checks whether the common servercertificate exists. If the certificate does not exist, you will be asked whether thecertificate should be created.

2.1 Activating and Deactivating SMT with YaSTYaST provides an easy way to activate or deactivate the SMT service. To activate SMT usingYaST, follow the steps below.

1. Switch to the Customer Center Access section in the SMT Configuration.

2. Activate the Enable Subscription Management Tool service (SMT) option.

Note: Organization CredentialsSpecify organization credentials before activating SMT. For more information onhow to set organization credentials with YaST, see Section 2.2, “Setting the Update

Server Credentials with YaST”.

3. Click Finish to apply the changes and leave the SMT Configuration.

To deactivate SMT with YaST, proceed as follows.

1. Switch to the Customer Center Access section in the SMT Configuration.

2. Disable the Enable Subscription Management Tool service (SMT) option.

3. Click Finish to apply the changes and leave the SMT Configuration.

When activating SMT, YaST performs the following actions.

The Apache configuration is changed by creating symbolic links in the /etc/apache2/conf.d/ directory. Links to the /etc/smt.d/nu_server.conf and /etc/smt.d/

smt_mod_perl.conf les are created there.

The Apache Web server is started (or reloaded if already running).

9 Activating and Deactivating SMT with YaST SLES 12 SP4

The Maria DB server is started or restarted. The smt user and all necessary tables in thedatabase are created, if needed.

The schema of the SMT database is checked. If the database schema is outdated, the SMTdatabase is upgraded to the current schema.

Cron is updated by creating a symbolic link in the /etc/cron.d/ directory. A link to the/etc/smt.d/novell.com-smt le is created there.

When deactivating SMT, YaST performs the following actions.

Symbolic links that were created upon SMT activation in the /etc/apache2/conf.d/ and /etc/cron.d/ directories are deleted.

The Cron daemon, the Apache server, and the Maria DB database daemon are restarted.Neither Apache nor Maria DB are stopped, as they may be used for other purposes thanthe SMT service.

2.2 Setting the Update Server Credentials with YaST

The following procedure describes how to set and test the download server credentials and theURL of the download server service using YaST.

10 Setting the Update Server Credentials with YaST SLES 12 SP4

FIGURE 2.1: SETTING THE UPDATE SERVER CREDENTIALS WITH YAST

1. Switch to the Customer Center Access section in the SMT Configuration. If the credentialshave been already set with YaST or via the /etc/smt.conf configuration le, they willbe displayed in the User and Password elds.

2. If you do not have credentials, visit SUSE Customer Center to obtain them. For moredetails, see Section 3.1, “Mirroring Credentials”.

3. Enter your user name and password in the appropriate elds.

4. Click Test to check the credentials. YaST will try to download a list of available repositorieswith the provided credentials. If the test succeeds, the last line of the test results will readTest result: success . If the test fails, check the provided credentials and try again.

11 Setting the Update Server Credentials with YaST SLES 12 SP4

FIGURE 2.2: SUCCESSFUL TEST OF THE UPDATE SERVER CREDENTIALS

5. Enter the SCC E-mail Used for Registration. This should be the address you used to registerto SUSE Customer Center.Enter Your SMT Server URL if it has not been detected automatically.

6. Click OK.

2.3 Setting SMT Database Password with YaSTFor security reasons, SMT uses its own user in the database. YaST provides an interface forsetting up or changing the SMT database password. To set or change the SMT database passwordwith YaST, follow the steps below.

1. Switch to the Database and Reporting section in the SMT Configuration module.

2. Enter the Database Password for SMT User. Confirm the password by re-entering it, thenclick OK.

2.4 Setting E-mail Addresses to Receive Reports withYaSTYaST SMT provides an interface for setting up a list of e-mail addresses for receiving reportsfrom SMT. To edit this list of addresses, proceed as follows.

1. Switch to the Database and Reporting section in the SMT Configuration.

12 Setting SMT Database Password with YaST SLES 12 SP4

2. The list of e-mail addresses is shown in the table. Use the appropriate buttons to add, edit,and delete existing address entries.

3. Click OK.

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

2.5 Setting the SMT Job Schedule with YaST

The SMT Configuration module provides an interface to schedule recurring SMT jobs. YaST usescron to schedule configured jobs. If needed, cron can be used directly. There are ve typesof recurring jobs that can be set:

Synchronization of Updates

Synchronizes with SUSE Customer Center, updates repositories, and downloads new up-dates.

Generation of Reports

Generates and sends SMT Subscription Reports to addresses defined in Section 2.4, “Setting

E-mail Addresses to Receive Reports with YaST”.

SCC Registration

Registers with SUSE Customer Center all clients that are not already registered or thatchanged their data since the last registration.

Job Queue Cleanup

Cleans up queued jobs. It removes finished or failed jobs from the job queue that are olderthan eight days. It also removes job artifacts that are left in the database as result of anerror.

13 Setting the SMT Job Schedule with YaST SLES 12 SP4

FIGURE 2.3: SMT JOB SCHEDULE CONFIGURATION

Use the following procedure to configure the schedule of SMT jobs with YaST.

1. Switch to the Scheduled SMT Jobs section in the SMT Configuration. The table contains alist of all scheduled jobs, their type, frequency, date, and time to run. You can add, delete,and edit the existing scheduled tasks.

2. To add a scheduled SMT job, click Add. This opens the Adding New SMT Scheduled Jobdialog.Choose the synchronization job to schedule. You can choose between Synchronization ofUpdates, Report Generation, SCC Registration, and Job Queue Cleanup.Choose the Frequency of the new scheduled SMT job. Jobs can be performed Daily, Weekly,Monthly, or Periodically (every n-th hour or every m-th minute).Set the Job Start Time by entering Hour and Minute. In case of a recurring job, enter therelevant intervals. For weekly and monthly schedules, select Day of the Week or Day ofthe Month.Click Add.

3. To edit a scheduled SMT job (for example, change its frequency, time, or date), select thejob in the table and click Edit. Then change the desired parameters and click OK.


FIGURE 2.4: SETTING SCHEDULED JOB WITH YAST

4. To cancel a scheduled job and delete it from the table, select the job in the table andclick Delete.

5. Click OK to apply the settings and quit the SMT Configuration.


3 Mirroring Repositories on the SMT Server

You can mirror the installation and update repositories on the SMT server. This way, you do notneed to download updates on each machine, which saves time and bandwidth.

Important: SUSE Linux Enterprise Server 9 RepositoriesAs SUSE Linux Enterprise Server 9 is no longer supported, SMT does not mirror SUSELinux Enterprise Server 9 repositories.

3.1 Mirroring CredentialsBefore you create a local mirror of the repositories, you need appropriate organization creden-tials. You can obtain the credentials from SUSE 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. If you are member of multiple organizations, chose the organization you want to workwith from the drop-down box in the top-right corner.

3. Click Organization in the top menu.

4. Switch to the Organizational credentials section.

5. To see the password, click Show password.

The obtained credentials should be set with the YaST SMT Server Configuration module or addeddirectly to the /etc/smt.conf le. For more information about the /etc/smt.conf le, seeSection 7.2.1, “/etc/smt.conf”.

Tip: Merging Multiple Organization Site CredentialsSMT can only work with one mirror credential at a time. Multiple credentials are notsupported. When a customer creates a new company, this generates a new mirror creden-tial. This is not always convenient, as some products are available via the rst set andother products via the second set. To request a merge of credentials, send an e-mail [email protected] .

16 Mirroring Credentials SLES 12 SP4

http://scc.suse.com

3.2 Managing Software Repositories with SMTCommand Line Tools

This section describes tools and procedures for viewing information about software repositoriesavailable through SMT, configuring these repositories, and setting up custom repositories on thecommand 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 fromSUSE Customer Center. These periodic updates can be configured with the SMT Managementmodule, 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 informationabout 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 availableon SUSE Customer Center. However, the used mirror credentials determine which repositoriescan really be mirrored. For more information about getting and setting organization credentials,see Section 3.1, “Mirroring Credentials”.

Repositories that can be mirrored have the MIRRORABLE ag set in the repositories table in theSMT database. That a repository can be mirrored does not mean that it needs to be mirrored.Only repositories with the DOMIRROR ag set in the SMT database will be mirrored. For moreinformation about configuring 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 repositoriesthat cannot be mirrored. In the rst column, the enabled repositories (repositories set to be

17 Managing Software Repositories with SMT Command Line Tools SLES 12 SP4

mirrored) are marked with Yes . Disabled repositories are marked with No . The other columnsshow ID, type, name, target, and description of the listed repositories. The last columns showwhether the repository can be mirrored and whether staging is enabled.

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

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

To list only enabled repositories, use the -o or --only-enabled option: smt-repos -o (seeExample 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 specific name or show information about a repositorywith a specific name and target. To list repositories with a particular name, use the smt-reposREPOSITORY_NAME command. To show information about a repository with a specific name andtarget, use the smt-repos repository_name TARGET command.

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

3.2.4 Selecting Repositories to Be Mirrored

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

To enable one or more repositories, follow these steps:

1. To enable all repositories that can be mirrored or to choose one repository from the listof all repositories, run the smt-repos -e command.

18 Selecting Repositories to Be Mirrored SLES 12 SP4

You can limit the list of repositories by using the relevant options. To limit the list to therepositories that can be mirrored, use the -m option: smt-repos -m -e . To limit thelist to the repositories with a specific name, use the smt-repos -e REPOSITORY_NAMEcommand. To list a repository with a specific name and target, use the smt-repos -eREPOSITORY_NAME TARGET command.To enable all repositories belonging to a specific product, use the --enable-by-prod or-p option, followed by the name of the product and optionally the version, architecture,and release:

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

For example, to enable all repositories belonging to SUSE Linux Enterprise Server 10SP3 for PowerPC architecture, use the smt-repos -p SUSE-Linux-Enterprise-Serv-er-SP3,10,ppc command. The list of known products can be obtained with the smt-list-products command.

Tip: Installer Self-Update RepositorySMT supports mirroring the installer self-update repository (nd more informationin Book “Deployment Guide”, Chapter 6 “Installation with YaST”, Section 6.4.1 “Self-Update

Process”). If you need to provide the self-update repository, identify and enable it,for example:

$ smt-repos -m | grep Installer$ smt-repos -e SLES12-SP2-Installer-Updates sle-12-x86_64

2. If more than one repository is listed, choose the one you want to enable: specify its ID listedin the repository table and press 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. To disable all enabled repositories or just choose one repository from the list of all repos-itories, run the smt-repos -d command.To choose the repository to be disabled from a shorter list, or to disable all repositoriesfrom a limited group, use any of the available options to limit the list of repositories. Tolimit the list to the enabled repositories, use the -o option: smt-repos -o -d . To limit

19 Selecting Repositories to Be Mirrored SLES 12 SP4

the list to repositories with a particular name, use the smt-repos -d REPOSITORY_NAMEcommand. To show a repository with a specific 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: specify itsID listed in the repository table and press Enter . If you want to disable all the listedrepositories, 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 willbe physically removed from the SMT storage area.

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

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

Note: Detecting Repository IDsEvery repository has an SHA-1 hash that you can use as an ID. You can get the repository'shash by calling smt-repos -v .

3.2.6 Mirroring Custom Repositories

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

When adding a new custom repository, the smt-setup-custom-repos command inserts a newrecord in the database and sets the mirror ag to true . You can disable mirroring later, ifnecessary.

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 Sec-

tion 7.1.2.4, “smt-list-products”.

20 Deleting Mirrored Repositories SLES 12 SP4

2. Run

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

PRODUCT_ID is the ID of the product the repository belongs to, REPOSITORY_NAME is thename of the repository, and REPOSITORY_URL is the URL of the repository. If the addedrepository needs to be available for more than one product, specify the IDs of all productsthat should use the added repository.For example, the following command sets My repository available at http://exam-ple.com/My_repository to the products with the IDs 423 , 424 , and 425 :

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

Note: Mirroring Unsigned RepositoriesBy default, SUSE Linux Enterprise 10 does not allow the use of unsigned repositories. So ifyou want to mirror unsigned repositories and use them on client machines, be aware thatthe package installation tool—YaST or zypper—will ask you whether to use repositoriesthat are not signed.

To remove an existing custom repository from the SMT database, use smt-setup-custom-repos--delete ID , where ID is the ID of the repository to be removed.

3.3 The Structure of /srv/www/htdocs for SLE 11The path to the directory containing the mirror is set by the MirrorTo option in the /etc/smt.conf configuration le. 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. If the directories already exist, they need to beremoved prior to creating the link (the data in these directories will be lost). In the followingexamples, MIRRORTO needs to be replaced by the path the option MirrorTo is set to.

/srv/www/htdocs/repo/$RCE must point to MIRRORTO/repo/$RCE/

/srv/www/htdocs/repo/RPMMD must point to MIRRORTO/repo/RPMMD/

21 The Structure of /srv/www/htdocs for SLE 11 SLES 12 SP4

/srv/www/htdocs/repo/testing must point to MIRRORTO/repo/testing/

/srv/www/htdocs/repo/full must point to MIRRORTO/repo/full/

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

Here is an example where the MirrorTo is set to /mirror/data :

l /srv/www/htdocs/repo/total 16lrwxrwxrwx 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/repofor LINK in \$RCE RPMMD full testing; do ln -s /mirror/data/repo/${LINK}/ && chown -h smt.www ${LINK}done

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

Important: Apache and Symbolic LinksBy default Apache on SUSE Linux Enterprise Server is configured to not follow symboliclinks. To enable symbolic links for /srv/www/htdocs/repo/ add the following snippetto /etc/apache2/default-server.conf (or the respective virtual host configurationin 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 lesto activate the change:

rcapache2 configtest && rcapache2 reload

3.4 The Structure of /srv/www/htdocs for SLE 12The repository structure in the /srv/www/htdocs directory matches the structure specified inSUSE Customer Center. There are the following directories in the structure (selected examples,similar for other products and architectures):

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

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

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

Contains EULA associated with the product.

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

Contain update repositories for respective products.

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

Contain repositories created for staging of respective repositories.

3.5 Using the Test EnvironmentYou can mirror repositories to a test environment instead of the production environment. Thetest environment can be used with a limited number of client machines before the tested repos-itories are moved to the production environment. The test environment can be run on the mainSMT server.


The testing environment uses the same structure as the production environment, but it is locatedin the /srv/www/htdocs/repo/testing/ subdirectory.

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

To register a client in the testing environment, modify /etc/SUSEConnect on the client machineas follows:

namespace: testing

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

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

If you have an SLE11-based update repository with patches, SMT tools can be used to managethem. Using these tools, you can select patches, create a snapshot and copy it into repo/test-ing/ . After tests are finished, you can copy the contents of repo/testing into the productionarea /repo .

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

Recommended workflow:

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

3.6 Testing and Filtering Update Repositories withStaging

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

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

24 Testing and Filtering Update Repositories with Staging SLES 12 SP4

Full

Testing

Production

Customer Center

Client

Client

Client

FIGURE 3.1: SMT STAGING SCHEMA

Repositories with staging enabled are mirrored to the /MIRRORTO/repo/full subdirectory. Thissubdirectory is usually not used by your clients. Incoming new updates are not automaticallyvisible to the clients before you get a chance to test them. Later, you can generate a testingenvironment of this repository, which goes to the /MIRRORTO/repo directory.

If you have an SLE 11-based update repository with patches, you can use SMT tools to managethem. Using these tools, you can select patches, create a snapshot and put it into repo/test-ing/ . After tests are finished, you can put the content of repo/testing into the /repo pro-duction area called the default staging group. You can create additional staging groups asneeded using the smt-staging creategroup command.

Note: SLE 10-based Update RepositoriesSLE 10-based update repositories are not supported by SMT tools. Not all of these repos-itories support selective staging. In this case, you need to mirror the complete package.


Enabling Staging

To enable or disable staging, use the smt-repos command with the --enable-stagingor -s options:

smt-repos --enable-staging

You can enable the required repositories by entering the ID number or by entering thename 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, run the following command:

smt-staging createrepo REPOSITORY_ID -–testing

You can then test the installation and functionality of the patches in testing clients. Iftesting was successful, create the production repository:

smt-staging createrepo REPOSITORY_ID --production

To create testing and production repositories in a named staging group, create the groupand the repositories in this group:

smt-staging creategroup GROUPNAME TESTINGDIR PRODUCTIONDIRsmt-staging createrepo --group GROUPNAME REPOSITORY_ID -–testingSMT-STAGING createrepo --group GROUPNAME REPOSITORY_ID -–production

This can be useful when you want to combine SLES11-SP1-Updates and SLES11-SP2-Up-dates of the sle-11-x86_64 architecture into one repository of a group:

smt-staging creategroup SLES11SP1-SP2-Up test-sp1-sp2 prod-sp1-sp2smt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP1-Updates sle-11-x86_64 --testingsmt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP2-Updates sle-11-x86_64 --testingsmt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP1-Updates sle-11-x86_64 --productionsmt-staging createrepo --group SLES11SP1-SP2-Up \ SLES11-SP2-Updates sle-11-x86_64 --production

Group names can contain the following characters: -_ , a-z A-Z , and 0-9 .

Filtering Patches

You can allow or forbid all or selected patches using the allow or forbid commands:

smt-staging forbid --patch IDsmt-staging forbid --category CATEGORYNAME


Signing Changed Repositories

Filtering one or more patches from a repository invalidates the original signature, and therepository needs to be signed again. The smt-staging createrepo command does thatautomatically, provided you configure the SMT server.To enable signing of changed metadata, the admin needs to generate a new signing key.This can be done with GPG like this:

mkdir DIRgpg --gen-key --homedir DIRsudo mv DIR /var/lib/smt/.gnupgsudo chown smt:users -R /var/lib/smt/.gnupgsudo chmod go-rwx -R /var/lib/smt/.gnupg

The ID of the newly generated key can be obtained using the gpg --gen-key command.The ID must be added to the signingKeyID option in the /etc/smt.conf le.At this point, the clients are not aware of the new key. Import the new key to clients duringtheir registration as follows:

sudo -u smt gpg --homedir /var/lib/smt/.gnupg \ --export -a SIGNING_KEYID \ > /MIRRORTO/repo/keys/smt-signing-key.key

In this example, MIRRORTO is the base directory where repositories will be mirrored. Afterthat, 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/SUSEConnect le on theclient machine:

namespace: testing

3.7 Repository PreloadingDeploying multiple SMT servers can take time if each new SMT server must mirror the samerepositories.

To save time when deploying new SMT servers, the repositories can be preloaded from anotherserver or disk instead. To do this, follow these steps:

1. Enable the repositories to be mirrored with the SMT, for example:

smt-repos -e SLES12-Updates sle-12-x86_64

27 Repository Preloading SLES 12 SP4

2. Perform a dry run of smt-mirror to create the required repository directories:

smt-mirror -d --dryrun -L /var/log/smt/smt-mirror.log

The following directories are created based on the repository above and the default Mir-rorTo :

/srv/www/htdocs/repo/repoindex.xml/srv/www/htdocs/repo/$RCE/SLES12-Updates/sle-12-x86_64/*

3. Then copy the repositories from another SMT server, for example:

rsync -av 'smt12:/srv/www/htdocs/repo/\$RCE/SLES12-Updates/sle-12-x86_64/' \ '/srv/www/htdocs/repo/$RCE/SLES12-Updates/sle-12-x86_64/'

4. To get the repository data xed, run the following command:

smt-mirror -d -L /var/log/smt/smt-mirror.log

Important: Possible Error MessagesErrors, such as repomd.xml is the same, but repo is not valid. Start mirror-ing. , are considered normal. They occur because the metadata of the preloaded reposi-tories in the server's database remains incorrect until the initial mirror of the repositorieshas completed.

28 Repository Preloading SLES 12 SP4

4 Managing Repositories with YaST SMT Server Man-agement

The YaST SMT Server Management module is designed to perform daily management tasks. Itcan be used to enable and disable the mirroring of repositories, the staging ag for repositories,and perform the mirroring and staging.

4.1 Starting SMT Management ModuleSMT Management is a YaST module. There are two ways to start the module:

Start YaST and select Network Services, then SMT Server Management

Run the yast2 smt command in the terminal as root

This opens the SMT Management application window and switches to the Repositories section.

FIGURE 4.1: LIST OF REPOSITORIES

4.2 Viewing and Managing RepositoriesIn the Repositories section, you can see the list of all available package repositories for SMT. Foreach repository, the list shows the repository's name, target product and architecture, mirroringand staging ag, date of last mirroring, and a short description. Sort the list by clicking thedesired column header, and scroll the list items using the scrollbar on the right side.

29 Starting SMT Management Module SLES 12 SP4

4.2.1 Filtering Repositories

You can also filter out groups of repositories using the Repository Filter text box. Enter the desiredfilter term and click Filter to see only the matching entries. To cancel the current filter anddisplay all repositories, clear the Repository Filter eld and click Filter.

FIGURE 4.2: REPOSITORY FILTER

4.2.2 Mirroring Repositories

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

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. This enables theoption in the Mirroring column of the selected repository. If the repository was alreadyselected for mirroring, clicking the Toggle Mirroring button disables the mirroring.

4. Hit the Mirror Now button to mirror the repository.

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

6. Click OK to refresh the list of repositories.

30 Filtering Repositories SLES 12 SP4

FIGURE 4.3: STATUS OF MIRRORING PROCESS

4.3 Staging Repositories

After the mirroring is finished, you can stage the mirrored repositories. In SMT, staging is aprocess 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 themavailable in a production environment. To make repositories available for staging, follow thesteps below.

1. From the repository list, select the line containing the name of the repository you wantto manage.

2. Click the selected line to highlight it.

3. Click the Toggle Staging button next to the Toggle Mirroring button. This enables the optionin the Staging column of the selected repository. If the repository was already selected forstaging before, clicking the Toggle Staging button disables staging.

4. Repeat steps 1 to 3 for all directories you want to stage.

31 Staging Repositories SLES 12 SP4

Important: Toggle Staging Button Not ActiveYou can only stage the repositories that were previously selected for mirroring. Otherwise,the Toggle Staging button will disabled.

After you have mirrored the repositories and made them available for staging, click the Stagingtab. In the upper-left part of the window, you will nd the Repository Name drop-down boxcontaining all repositories available for staging. The repository names there have the name of theattached staging group. Select the group you want to stage, and you should see a list of packagesin this repository. For each patch, there is information about the patch name, its version andcategory, testing and production ags, and a short summary.

Next to the Repository Name drop-down box, there is a Patch Category filter. It can be used forlisting only the patches that belong to one of the predefined categories.

If the selected repository allows for patch filtering, you can toggle the status ag for individualpatches. This is done by clicking the Toggle Patch Status button.

Before creating a repository of packages that are available in the production environment, youneed to create and test the testing repository. Select the From Full Mirror to Testing item from theCreate Snapshot drop-down list. A small pop-up window appears informing you about the stagingprocess. After the testing repository snapshot has been created, you should see the appropriateoptions enabled in the Testing column.

FIGURE 4.4: TESTING CREATED SNAPSHOT

32 Staging Repositories SLES 12 SP4

Important: Creating a Production SnapshotAfter you have enabled staging for an update repository, you need to create its productionsnapshot to make it available to the clients. Otherwise, the clients cannot nd the updaterepository.

Select the From Testing to Production item from the Create Snapshot drop-down box. A small pop-up window appears informing you about linking the testing repository to the production one.After the production snapshot has been created, you should see the appropriate options enabledin the Production column. Also, a green check mark appears in the Repository Name drop-downbox.

4.4 Jobs and Client Status MonitoringFor each client that is registered against the SMT server, SMT creates a job queue. To use thejob queue, you need to install the smt-client package on the client. During the installationof the smt-client package, a cron job is created that runs the client executable /usr/sbin/smt-agent every three hours. The agent then asks the server if it has any jobs in the queuebelonging to this client and executes these jobs. When there are no more jobs in the queue, theagent terminates completely. It is important to understand that jobs are not pushed directly tothe clients when they get created. They are not executed until the client asks for them at theintervals specified in the cron job. Therefore, from the time a job is created on the server untilit is executed on the client, a delay of several hours may occur.

Every job can have a parent job. This means that the child job only runs after the parent jobhas successfully finished. It is also possible to configure advanced timing and recurrence andpersistence of jobs. You can nd 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 GUIDparameter. Although the -g parameter can be specified multiple times in a single command,you cannot use wild cards to assign a job to all clients.

Currently, the following types of jobs are available:

Execute

Run commands on the client

Eject

Open, close, or toggle the CD tray of the client

33 Jobs and Client Status Monitoring SLES 12 SP4

Patchstatus

Report the status of installed patches

Reboot

Reboot the client

Softwarepush

Install packages

Update

Install available updates

Tip: Default Job TypesBy default only softwarepush , patchstatus , and update jobs are allowed. To allowmore types of jobs, append the job type to the ALLOWED_AGENTS list in /etc/syscon-fig/smt-client .

All clients that register against the SMT server automatically get a persistent patchstatus jobadded to their job queue. This is also the case for clients without the smt-clients package(SUSE Linux Enterprise 10 and older, or non-SUSE based distributions). These clients appearwith the Unknown patchstatus in the client lists. The patchstatus jobs for such clients arenot required, and clients can safely be deleted to clean up the output of smt-job . Keep inmind that if you update a machine to SUSE Linux Enterprise 11 or later, you need to create thepatchstatus job manually.

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

Security

Package Manager

Recommended

Optional

34 Jobs and Client Status Monitoring SLES 12 SP4

Tip: The --agreelicense OptionTo install a package and its dependencies, the job type softwarepush is used. Whencreating this type of job, it is a good idea to use the --agreelicense option. If a packagedisplays a license agreement and expects it to be accepted, the job will skip the package if--agreelicense is not specified. The smt-client command forwards the installationprocess to zypper , which does not consider a failed acceptance of a license agreementto be an error. This results in the job being completed successfully, even if the packageis not installed. Using the --agreelicense option prevents this from happening.

4.4.1 Checking the Client Status with YaST

The Clients Status section of the SMT Management window provides the status information aboutall the clients that use the repositories on your SMT server. This information consists of twomain parts: the list of the clients and the detailed information.

You can see the client's host name, the date and time of the last network contact with the SMTserver, 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 optionalor recommended

Critical

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

Detailed information about the selected client is available in the lower part of the window. Thisusually includes extended status information and detailed information about the number andtypes of available updates.

35 Checking the Client Status with YaST SLES 12 SP4

FIGURE 4.5: CLIENTS STATUS

The date and time in the Last Contact column is the last time contact of the server—even if itonly ran the regular registration update script. This date is not the date of the last 'patchstatus'report. The smt-client command-line tool prints the correct date and calls it Patch StatusDate . The smt-client -v command prints both dates: the patchstatus date and the lastcontact of the client system.

Note: Hidden PatchesSome patches may not be visible if they are required by other patches that are only shownas available after the package manager patch or patches have been installed.

36 Checking the Client Status with YaST SLES 12 SP4

5 Managing Client Machines with SMT

SMT lets you register and manage client machines on SUSE Customer Center. Client machinesmust be configured to use SMT. For information about configuring clients to use SMT, see Chap-

ter 8, Configuring Clients to Use SMT.

5.1 Listing Registered Clients

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

5.2 Deleting Registrations

To delete a registration from SMT and SUSE Customer Center, use the following command:

smt-delete-registration -gClient_ID

To delete multiple registrations, the option -g can be used several times.

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

5.3 Manual Registration of Clients at SUSE CustomerCenter

The smt-register command registers clients at SUSE Customer Center. This registers all un-registered clients and clients with data that changed since the last registration.

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

37 Listing Registered Clients SLES 12 SP4

5.4 Scheduling Periodic Registrations of Clients atSUSE Customer Center

SMT module allows for the easy scheduling of client registrations. By default, registrations arescheduled to run every 15 minutes. To create or modify a new registration schedule, follow thesteps below.

1. Start YaST SMT Configuration module ( yast2 smt-server ).

2. Go to the Scheduled SMT Job.

3. Select any SCC Registration job and click Edit to change its schedule.To create a new registration schedule, click Add and select SCC Registration as Job to Run.

4. Choose the Frequency of the scheduled SMT job. You can perform jobs Daily, Weekly,Monthly, or Periodically (every n-th hour or every m-th minute).Set the Job Start Time by entering the Hour and Minute or appropriate time periods. Forweekly and monthly schedules, select the Day of the Week or the Day of the Month themirroring should occur.

Note: Lowest Registration FrequencyDo not set the frequency lower than 10 minutes, because the maximum value ofthe rndRegister is 450 (7.5 minutes). If the frequency is lower, it may happenthat the started process is still sleeping when the next process starts. This causesthe second request to exit.

5. Click OK or Add and Finish.

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 youprefer not to use YaST, you can use cron directly.

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

38 Scheduling Periodic Registrations of Clients at SUSE Customer Center SLES 12 SP4

5.5 Compliance MonitoringTo assist customers in monitoring their license compliance, SMT generates a weekly report basedon data from SMT and SUSE Customer Center. This report contains information about statisticsof the registered machines, products used, and of the active, expiring or missing license sub-scriptions. If subscriptions are about to expire and/or more SUSE Linux Enterprise machines areregistered than you have purchased licenses for, the report contains relevant warnings.

To calculate the compliance, the smt-report tool by default downloads information about thesubscriptions and registrations (this can be disabled).

You can configure the recipient addresses for the reports in the Database and Reporting sectionof the YaST Subscription Management Tool configuration module. All of the e-mail configurationoptions 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 pa-rameters to use with the cron jobs are in the REPORT_PARAMS section of /etc/smt.d/smt-cron.conf .

Describing the content of the reports is beyond the scope of this section, but a set of reportscan be split into ve individual parts. By default, these reports are attached as individual lesto the mail on the weekly report run. The alerts report is a normal text le while the othersare 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 as CSV les based on local data and to display them in the standardoutput, run the following command:

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

Tip: Directory for ReportsThe example stores the reports in the /root directory. You can change it to any otherwritable directory.

The command generates the following les:

/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

39 Compliance Monitoring SLES 12 SP4

/root/smt-local-rep-product_subscription_summary.csv

Note: Multiple SMT ServersIf you have multiple SMT servers, the reports may not include all SMT servers or machinesin your environment. For the complete statistics of all your registered machines, refer tothe information provided by SUSE Customer Center.

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

Reports.

40 Compliance Monitoring SLES 12 SP4

6 SMT Reports

This chapter explains how to generate reports using the data from the SMT and SUSE CustomerCenter. These reports contain statistics of all the registered machines, products used and allactive, expiring or missing subscriptions.

Note: Assignment of ReportsIf you are using more than one SMT server, generated reports may not include all SMTservers or machines in your environment. For the complete statistics of all your registeredmachines, refer to the information in the SUSE Customer Center.

6.1 Report Schedule and Recipients

Generated SMT reports can be periodically sent to a list of specified e-mail addresses. To createor 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 covered in Section 2.5, “Setting the SMT Job Schedule

with YaST”.

The list can also be edited manually in the reportEmail part of the /etc/smt.conf configu-ration le. For more information about manually editing the list of addresses, see Section 7.2.1.6,

“[REPORT] Section of /etc/smt.conf”. To set the frequency of reports manually, you can edit thesmt-gen-report lines of the crontab in /etc/cron.d/novell.com-smt . For more informa-tion about the crontab format, see man 5 crontab .

Reports, including those generated as a scheduled SMT job, are created by the smt-reportcommand. This command supports various parameters. To edit parameters used with scheduledcommands, edit the /etc/smt.d/smt-cron.conf configuration le. For more information, seeSection 7.2.2, “/etc/smt.d/smt-cron.conf”.

41 Report Schedule and Recipients SLES 12 SP4

6.2 Report Output Formats and Targets

SMT reports can be printed to the standard output, exported to one or multiple les (in the CSVformat), and mailed to a specified list of e-mail addresses. The following parameters can be usedwith the smt-report command:

--quiet or -q

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

--file or -F

Export the report to one or several les. By default, the report is written to a single le, withthe results formatted as tables. Optionally, the le name or whole path may be specifiedafter the parameter: --file FILENAME . If no le name is specified, the default le namecontaining a time stamp is used. However, SMT will not check if the le or les alreadyexist.In the CSV (Comma-Separated Value) mode, the report is written to multiple les, thereforethe specified le name expands to [PATH/]FILENAME-reportname.extension for everyreport.

--csv or -c

The report is exported to multiple les in the CSV format. The rst line of each *.csv leconsists of the column names. It is recommended to use the --csv parameter togetherwith the --file parameter. If the specified le name contains a .csv extension, thereport format will be CSV (as if the --csv parameter was used).

--mail or -m

Send the report to the addresses configured using the YaST SMT Configuration module andstored in /etc/smt.conf . The report is rendered as tables.

--attach or -a

Attach the report to the mails in the CSV format. This option should only be used in com-bination with the --mail option.

--pdf

The report is exported to multiple les in the PDF format.

--xml

The report is exported to multiple les in the XML format.

42 Report Output Formats and Targets SLES 12 SP4

Note: Disabling Sending AttachmentsTo disable sending CSV attachments with report mails, edit the /etc/smt.d/smt-cron.conf configuration le as follows: remove the --attach option from the RE-PORT_PARAMS value. The default line reads: REPORT_PARAMS="--mail --attach -

L /var/log/smt-report.log" . To disable CSV attachments, change it to: RE-

PORT_PARAMS="--mail -L /var/log/smt-report.log" .

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

43 Report Output Formats and Targets SLES 12 SP4

7 SMT Tools and Configuration Files

This chapter describes the most important scripts, configuration les and certificates shippedwith SMT.

7.1 Important Scripts and Tools

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

7.1.1 SMT JobQueue

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

To enable JobQueue, the smt-client package needs to be installed on the SMT client. Theclient then pulls jobs from the server via a cron job (every 3 hours by default). The list of jobs ismaintained on the server. Jobs are not pushed directly to the clients and processed immediately:instead, 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 theparent job successfully finished. Job timing is also possible: a job can have a start time and anexpiration time to define its earliest execution time or the time the job will expire. A job mayalso be persistent. It is run repeatedly with a delay. For example, a patch status job is a persistentjob that runs once a day. For each client, a patch status job is automatically generated after itregisters successfully against an SMT 11 server. The patchstatus information can be queriedwith the smt-client command. For already registered clients, you can add patchstatus jobsmanually with the smt-job command.

You can edit, list, create, and delete the jobs using the smt-job command-line tool. For moredetails on smt-job , see Section 7.1.2.3, “smt-job”.

44 Important Scripts and Tools SLES 12 SP4

Note: Overriding the Automatic Creation of Patch Status JobsWhen creating a software push or an update job, normally a non-persistent patch statusjob is added automatically. The parent ID is set to the ID of the new job. To disable thisbehavior, use the --no-autopatchstatus option.

SMT is not intended to be a system to directly access the clients or to immediately report theresults back. It is a long-term maintenance and monitoring system rather than a live interactiontool.

Note: Job Time Lag LimitationThe client normally processes one job at a time, reports back the result, and then asks forthe next job. If you create a persistent job with a time offset of only a few seconds, it willbe repeated forever and will block other jobs. Therefore, adding jobs with a time offsetshorter than one minute is not supported.

7.1.2 /usr/sbin/smt Commands

The key command to manage the SMT is smt ( /usr/sbin/smt ). The smt command should beused together with various sub-commands described in this section. If the smt command is usedalone, 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

45 /usr/sbin/smt Commands SLES 12 SP4

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: smt followed by a sub-com-mand or a single command consisting of smt followed by the dash and the desired sub-com-mand. For example, it is possible to use either smt mirror or smt-mirror , as both have thesame meaning.

Note: Conflicting CommandsDepending 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 ). Ei-ther use the absolute path /usr/sbin/smt , create an alias, or set your $PATH accord-ingly.

Another solution is to always use the smt- SUBCOMMAND syntax.

7.1.2.1 smt-client

The smt-client command shows information about registered clients. The information in-cludes the following:

guid

host name

patch status

time stamps of the patch status

last contact with the SMT server


The smt-client supports the following options:

--verbose or -v

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

--debug or -d

Enables debugging mode.

--logfile or -L with the parameter LOGFILE

Specifies the le the log will be written to.

--hostname or -h with the parameter HOSTNAME

Lists the entries whose host name begins with HOSTNAME .

--guid or -g with the parameter ID

Lists the entries whose GUID is ID .

--severity or -s with the parameter LEVEL

Filters the result by the patch status information. The value level can be one of pack-agemanager , security , recommended or optional .

7.1.2.2 smt-delete-registration

The smt-delete-registration command deletes one or more registrations from SMT andSUSE Customer Center. It unregisters machines from the system. The following options are avail-able:


Deletes the machine with the guid ID from the system. You can use this option multipletimes.

--debug or -d


7.1.2.3 smt-job

The smt-job script manages jobs for individual SMT clients. You can this command to list,create, edit, and delete jobs. The following options are available:

--list or -l

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


--verbose or -v with the parameter LEVEL

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

--create or -c

Creates a new job.

--edit or -e

Edits an existing job.

--delete or -d

Deletes an existing job.


Specifies the client's guid. This parameter can be used multiple times to create a job formore than one client.

--jobid or -j with the parameter ID

Specifies the job ID. You need to specify job ID and client's guid when editing or deletinga job, as the same job for multiple clients has the same job ID.

--deleteall or -A id

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

--type or -t with the parameter TYPE

Specifies the job type. The type can be one of patchstatus , softwarepush , update ,execute , reboot , wait , eject . On the client, only the following job types are enabledby default: patchstatus , softwarepush and update .

--description DESCRIPTION

Specifies a job description.

--parent ID

Specifies the job ID of the parent job. Use it to define a dependency. A job will not beprocessed until its parent has successfully finished.

--name or -n with the parameter NAME

Specifies a job name.


--persistent

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

--finished

Search option for finished jobs.

--targeted time

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

--expires time

Defines when the job will no longer be executed anymore.

--timelag time

Defines the time interval for persistent jobs.

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

7.1.2.3.1 Examples

List all finished jobs:

smt-job --list --finished

Create a softwarepush job that installs xterm and bash on client 12345 and 67890:

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

Change the timing for a persistent job with job ID 42 and guid 12345 to run every 6 hours:

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

Delete all jobs with job ID 42:

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


7.1.2.4 smt-list-products

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

--used or -u

Shows only used products.

--catstat or -c

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

7.1.2.5 smt-list-registrations

The smt-list-registrations script lists all registrations. There are two options available forthis command:

--verbose or -v

Shows detailed information about the registered devices.

--format or -f with the parameter FORMAT

Formats the output in the asciitable or csv formats.

7.1.2.6 smt-mirror

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

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

--clean or -c

Removes all les no longer mentioned in the metadata from the mirror. No mirroringoccurs before cleanup.

--debug or -d

Enables the debugging mode.

--deepverify

Turns on verifying of all package checksums.

--hardlink SIZE

Searches for duplicate les with a size greater than the size specified in kilobytes. Createshard links for them.


--directory PATH

Defines the directory to work on. When using this option, the default value configured inthe smt.conf configuration le is ignored.

--dbreplfile FILE

Defines a path to the *.xml le to use as database replacement. You can create this lewith the smt-scc command.

--logfile or -L with the parameter FILE

Specifies the path to a log le.

7.1.2.7 smt-sync

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

For SUSE Linux Enterprise 11 clients, this script automatically determines whether Novell Cus-tomer Center or SUSE Customer Center should be used. Then smt-ncc-sync or smt-scc-syncis called. For SUSE Linux Enterprise 12 clients, only smt-scc-sync is supported.

7.1.2.8 smt-scc-sync

The smt scc-sync command obtains data from the SUSE Customer Center and updates thelocal SMT database. It can also save SUSE Customer Center data to a directory instead of theSMT database, or read SUSE Customer Center data from a directory instead of downloading itfrom SUSE Customer Center.

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

--fromdir DIRECTORY

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

--todir DIRECTORY

Writes SUSE Customer Center data to the specified directory without updating the SMTdatabase.


Tip: SUSE Manager's Subscription Matching FeatureThis data can be used by the subscription matching feature of SUSEManager, which gives you a detailed overview of your subscrip-tion usage. For more information on the subscription matching feature,see https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-refer-

ence/html/

book.suma.reference.manual/ref.webui.audit.html#ref.webui.audit.subscription .

--createdbreplacementfile

Creates a database replacement le for using smt-mirror without database.



--debug


7.1.2.9 smt-register

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

The following options are available:



--debug


7.1.2.10 smt-report

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


https://www.suse.com/documentation/suse-manager-3/3.2/susemanager-reference/html/book.suma.reference.manual/ref.webui.audit.html#ref.webui.audit.subscription



The following options are available:

--mail or -m

Activates mailing the report to the addresses configured with the SMT Server and writtenin /etc/smt.conf . The report is formatted as tables.

--attach or -a

Appends the report to the e-mails in CSV format. This option should only be used in com-bination with the --mail option.

--quiet or -q

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

--csv or -c

Exports the report to multiple les in the CSV format. The rst line of each *.csv leconsists of the column names. The --csv parameter should only be used in combinationwith the --file parameter. If the specified le name has the .csv extension, the reportis formatted as CSV (as if the --csv parameter was used).

--pdf or -p

Exports the report in the PDF format. Use it only in combination with the -file option.

--xml

Exports the report in the XML format. Use it only in combination with the -file option.For a detailed description of the XML format, see the manual page of the smt-reportcommand.

--file or -F

Exports the report to one or several les. By default, the report is written to a single leformatted as tables. Optionally, the le name or whole path may be specified after the --file filename parameter. If no le name is specified, a default le name containing atime stamp is used. However, SMT does not check if the le or les already exist.In the CSV mode the report is written to multiple les, therefore the specified le nameexpands to [PATH/]FILENAME-reportname.extension for every report.


Specifies path to a log le.

--debug



7.1.2.11 smt-repos

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

--enable-mirror or -e

Enables repository mirroring.

--disable-mirror or -d

Disables repository mirroring.

--enable-by-prod or -p

Enables repository mirroring by giving product data in the following format: Produc-t[,Version[,Architecture[,Release]]] .

--disable-by-prod or -P

Disables repository mirroring by giving product data in the following format: Produc-t[,Version[,Architecture[,Release]]] .

--enable-staging or -s

Enables repository staging.

--disable-staging or -S

Disables repository staging.

--only-mirrorable or -m

Lists only repositories that can be mirrored.

--only-enabled or -o

Lists only enabled repositories.

--delete

Lists repositories and deletes them from disk.

--namespace DIRNAME

Deletes the repository in the specified name space.

--verbose or -v

Shows detailed repository information.


7.1.2.12 smt-setup-custom-repos

The smt-setup-custom-repos and smt setup-custom-repos script are designed for settingup custom repositories (repositories not present in the download server) for use with SMT. Youcan use this script to add a new repository to the SMT database or to delete a repository fromthe database. The script supports the following options:

--productid PRODUCT_ID

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 NAME

The name of the custom repository.

--description DESCRIPTION

The description of the custom repository.

--exturl URL

The URL for the repository to be mirrored from. Only HTTP and HTTPS protocols aresupported.

--delete ID

Removes 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 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 ID

For example:

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


7.1.2.13 smt-staging

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

The rst argument of smt-staging is always the command . It must be followed by a repos-itory . The repository can be specified by Name and Target from the table scheme returnedby the smt-repos command. Alternatively, it can be specified by its Repository ID whichcan be obtained by running the command smt-repos -v . The smt-staging script supportsthe following commands:

listupdates

Lists available patches and their allowed and forbidden status.

allow/forbid

Allows or forbids specified patches.

createrepo

Generates both testing and production repository with allowed patches.

status

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

listgroups

Lists staging groups.There is always one group available with the name “default”. The default group has thepath repo/full , repo/testing and repo . New paths can be specified when creatinga new group.

creategroup

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

removegroup

Removes a staging group. The group name parameter is required.

The following options apply to any smt-staging command:

--logfile or -L file path

Writes log information to the specified le. It is created if it does not already exist.


--debug or -d

Turns on the debugging output and log.

--verbose or -v

Turns more detailed output on.

The following options apply to specific smt-staging commands:

--patch PATCH_ID

Specifies a patch by its ID. You can get a list of available patches with the listupatescommand. This option can be used multiple times. Use it with the allow , forbid , andlistupdates commands. When used with listupdates , the command prints detailedinformation about the specified patches.

--category CATEGORY

Specifies the patch category. The following categories are available: security , recom-mended and optional . Use it in combination with the allow , forbid , and listup-dates commands.

--all

Allows or forbids all patches in the allow or forbid commands.

--individually

Allows or forbids multiple patches (for example by category) one by one similar to the --patch option used with each of the patches.

--testing

Generates a repository for testing when used in combination with the createrepo com-mand. The repository is generated from the full unfiltered local mirror of the remote repos-itory. It is written into the <MirrorTo>/repo/testing directory, where MirrorTo is thevalue obtained from smt.conf .

--production

Generates a repository for production when used in combination with the createrepocommand. The repository is generated from the testing repository. It is written into the<MirrorTo>/repo directory, where MirrorTo is the value obtained from smt.conf . Ifthe testing repository does not exist, the production repository is generated from the fullunfiltered local mirror of the remote repository.


--group GROUP

Specifies on which group the command should work. The default for --group is the namedefault .

--nohardlink

Prevents creating hard links instead of copying les when creating a repository with thecreaterepo command. If not specified, hard links are created instead.

--nodesc

Skips patch descriptions and summaries—to save some screen space and make the outputmore readable.

--sort-by-version

Sorts the listupdates table by patch version. The higher the version, the newer the patchshould be.

--sort-by-category

Sorts the listupdates table by patch category.

7.1.2.14 smt-support

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

--incoming or -i with the parameter DIRECTORY

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

--list or -l

Lists the uploaded supportconfig archives in the incoming directory.

--remove or -r with the parameter ARCHIVE

Deletes the specified archive.

--empty or -R

Deletes all archives in the incoming directory.


--upload or -u with the parameter ARCHIVE

Uploads 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

Uploads all archives in the incoming directory to SUSE.

--srnum or -s with the parameter SR_NUMBER

Specifies the Novell Service Request 12-digit number.

--name or -n with the parameter NAME

Specifies the rst and last name of the contact, in quotes.

--company or -c with the parameter COMPANY

Specifies the company name.

--storeid or -d with the parameter ID

Specifies the store ID, if applicable.

--terminalid or -t with the parameter ID

Specifies the terminal ID, if applicable.

--phone or -p with the parameter PHONE

Specifies the phone number of the contact person.

--email or -e with the parameter E-MAIL_ADDRESS

Specifies the e-mail address of the contact.

7.1.3 SMT systemd Commands

You can manage SMT-related services with the standard systemd commands:

systemctl start smt.target

Starts the SMT services.

systemctl stop smt.target

Stops the SMT services.

systemctl status smt.target

Checks the status of the SMT services. Checks whether httpd, Maria DB, and cron arerunning.

59 SMT systemd Commands SLES 12 SP4

systemctl restart smt.target

Restarts the SMT services.

systemctl try-restart smt.target

Checks whether the SMT services are enabled and if so, restarts them.

You can enable and disable SMT with the YaST SMT Server module.

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

7.2.1 /etc/smt.conf

The /etc/smt.conf le has several sections. The [NU] section contains the update credentialsand 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 config-uration of SMT reports.

Warning: Passwords in Clear TextThe /etc/smt.conf le contains passwords in clear text. Its default permissions (640,root, wwwrun) make its content easily accessible with scripts running on the Apacheserver. Be careful with running other software on the SMT Apache server. The best policyis to use this server only for SMT.

7.2.1.1 [NU] Section of /etc/smt.conf

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.

60 SMT Configuration Files SLES 12 SP4

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 gettingorganization credentials, see Section 3.1, “Mirroring Credentials”. You can set this value withthe SMT Server.

NUPass

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

ApiType

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

7.2.1.2 [DB] Section of /etc/smt.conf

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 rst parameter of the DBI->connect Perl method used for connection to the Maria DBdatabase. 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 databaseserver.

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

61 /etc/smt.conf SLES 12 SP4

7.2.1.3 [LOCAL] Section of /etc/smt.conf

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 avail-able on the server. This value should be set by YaST automatically during installation. Theformat of this option should be: https://server.domain.tld/ .You can change the URL manually. For example, the administrator may choose to use thehttp:// scheme instead of https:// for performance reasons. Another reason may beusing 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 administratorcan 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 thatcan be mirrored to be mirrored (DOMIRROR ag).

MirrorSRC

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

Note: Default Value Changed with SMT 11 SP2With SMT 11 SP2, the preset default value was changed to false . If you also wantSMT 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 reg-istered at Novell Customer Center, too. This option does not work with SUSE CustomerCenter yet.


rndRegister

Specify a delay in seconds before the clients are registered at SUSE Customer Center. Thevalue 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 Centerserver 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 itslock.

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 HTTPconnection 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 con-figured in /etc/syconfig/proxy are used. You can configure the global proxy settingswith the YaST Proxy module.

HTTPSProxy

If you do not want to use global proxy settings, specify the proxy to be used for HTTPSconnection here. Use the form: https://PROXY.example.com:3128 .If the proxy settings are not configured in /etc/smt.conf , the global proxy settings con-figured in /etc/syconfig/proxy are used. You can configure the global proxy settingswith the YaST Proxy module.

ProxyUser

If your proxy requires authentication, specify a user name and password here, using theUSERNAME:PASSWORD format.If the proxy settings are not configured in /etc/smt.conf , the global proxy settings con-figured in /etc/syconfig/proxy are used. You can configure the global proxy settingswith the YaST Proxy module.


Tip: Global User Authentication SettingIf you configure the global proxy settings with YaST, manually copy /root/.curl-rc to the home directory of the smt . Adjust the permissions with the followingcommands 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 repos-itories.

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 undersmtUser needs to have access to the key. If this option is not set, the modified repositorieswill be unsigned.

7.2.1.4 [REST] Section of /etc/smt.conf

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 emptypassword is invalid.


7.2.1.5 [JOBQUEUE] Section of /etc/smt.conf

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 suc-cessful. For more information about possible status IDs, see smt-job --help . Leavingthis option empty is interpreted as default (1,4).

7.2.1.6 [REPORT] Section of /etc/smt.conf

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 thislist with the YaST SMT Server module.

reportEmailFrom

From eld of report e-mails. If not set, the default [email protected] will beused.

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

EXAMPLE 7.1: SMT.CONF

[NU]NUUrl=https://updates.suse.com/


NURegUrl=https://scc.suse.com/connectNUUser = exampleuserNUPass = examplepasswordApiType = SCC

[DB]config = dbi:mysql:database=smt;host=localhostuser = smtpass = smt

[LOCAL]# Default should be http://server.domain.top/url = http://smt.example.com/# This email address is used for registration at SCCnccEmail = [email protected] = /srv/www/htdocsMirrorAll = falseMirrorSRC = falseforwardRegistration = truerndRegister = 127# The hook script that should be called before the smt-mirror script removes its lockmirror_preunlock_hook =# The hook script that should be called after the smt-mirror script removed its lockmirror_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:3128HTTPProxy =# specify which proxy you want to use for HTTPS connection# in the form http://proxy.example.com:3128HTTPSProxy =# specify username and password if your proxy requires authentication# in the form username:passwordProxyUser =## 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: 0enableRESTAdminAccess = 0# Define the username the REST-Admin uses for login# default: RESTrootRESTAdminUser = 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: 8maxFinishedJobAge = 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,6jobStatusIsSuccess = 1,4

[REPORT]


# comma separated list of eMail addresses where the status reports will be sent toreportEmail = [email protected]# from field of report mails - if empty it defaults to "root@<hostname>.<domainname>"reportEmailFrom =# relay mail server - leave empty if mail should be sent directlymailServer =mailServerPort =# mail server authentication - leave empty if not requiredmailServerUser =mailServerPassword =

7.2.2 /etc/smt.d/smt-cron.conf

The /etc/smt.d/smt-cron.conf configuration le contains options of the SMT commandslaunched as SMT scheduled jobs set with YaST (see Section 2.5, “Setting the SMT Job Schedule with

YaST”). Cron is used to launch these scheduled jobs. The cron table is located in the /etc/cron.d/novell.com-smt le.

SCC_SYNC_PARAMS

Contains parameters of the smt scc-sync command, if called as part of an SMT scheduledjob via cron. The default value is "-L /var/log/smt/smt-sync.log --mail" .

MIRROR_PARAMS

Contains parameters of the smt mirror command, if called as part of an SMT scheduledjob via cron. The default value is "-L /var/log/smt/smt-mirror.log --mail" .

REGISTER_PARAMS

Contains parameters of the smt register command, if called as part of an SMT scheduledjob via cron. The default value is "-r -L /var/log/smt/smt-register.log --mail" .

REPORT_PARAMS

Contains parameters of the smt report command, if called as part of an SMT sched-uled job via cron. The default value is "--mail --attach -L /var/log/smt/smt-re-port.log" .

JOBQUEUECLEANUP_PARAMS

Contains parameters for smt jobqueue cleanup, if called as a part of an SMT scheduled jobvia cron. The default value is "--mail -L /var/log/smt/smt-jobqueuecleanup.log" .

68 /etc/smt.d/smt-cron.conf SLES 12 SP4

7.3 Server CertificatesFor communication between the SMT server and client machines, the encrypted HTTPS protocolis used, requiring a server certificate. If the certificate is not available, or if clients are notconfigured 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 author-ity) certificate that signed the server certificate. Therefore, the SMT server provides a copyof the CA at /srv/www/htdocs/smt.crt . This CA can be downloaded from every client viathe URL http://FQDN/smt.crt . The copy is created by the /usr/lib/SMT/bin/smt-mainte-nance script. Whenever SMT is started with systemctl start smt.target , it checks the cer-tificate. If a new CA certificate exists, it is copied again. Therefore, whenever the CA certificateis missing or changed, restart SMT using the systemctl restart smt.target command.

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

7.3.1 Certificate Expiration

The common server certificate SMT uses is valid for one year. After that time, a new certificateis needed. Either generate a new certificate using YaST CA Management module or import anew certificate using the YaST Common Server Certificate module. Both options are describedin the following sections.

As long as the same CA certificate is used, there is no need to update certificates on the clientmachines. The generated CA certificate is valid for 10 years.

7.3.2 Creating a New Common Server Certificate

To create a new common server certificate with YaST, proceed as follows:

1. Start YaST and select Security and Users CA Management. Alternatively, start the YaST CAManagement module from a command line by entering yast2 ca_mgm as root .

2. Select the required CA and click Enter CA.

3. Enter the password if entering a CA for the rst time. YaST displays the CA key informationin the Description tab.

69 Server Certificates SLES 12 SP4

4. Click the Certificates tab (see Figure 7.1, “Certificates of a CA”) and select Add Add ServerCertificate.

FIGURE 7.1: CERTIFICATES OF A CA

5. Enter the fully qualified domain name of the server as Common Name. Add a valid e-mailaddress of the server administrator. Other elds, such as Organization, Organizational Unit,Locality, and State are optional. Click Next to proceed.

Important: Host Name in Server CertificateThe server certificate must contain the correct host name. If the client requestsserver https://some.hostname/ , then some.hostname must be part of the cer-tificate. The host name must either be used as the Common Name, see Step 5, or as theSubject Alternative Name, see Step 7: DNS:some.hostname and IP:<ipaddress> .

6. Enter a Password for the private key of the certificate and re-enter it in the next eld toverify it.

7. If you want to define a Subject Alternative Name, click Advanced Options, select SubjectAlternative Name from the list and click Add.

70 Creating a New Common Server Certificate SLES 12 SP4

Important: Subject Alternative NameIf Subject Alternative Name is in the server certificate, then it needs to contain theDNS entry. If Subject Alternative Name is present, the Common Name (CN) is notchecked anymore.

8. If you want to keep the default values for the other options, like Key Length and ValidPeriod, click Next. An overview of the certificate to be created is shown.

9. Click Create to generate the certificate.

10. To export the new certificate as the common server certificate, select it in the Certificatestab and select Export Export as Common Server Certificate.

11. After having created a new certificate, restart SMT using the systemctl restartsmt.target command. Restarting SMT ensures that the new certificate is copied from/etc/ssl/certs/YaST-CA.pem to /srv/www/htdocs/smt.crt , the copy SMT uses.Restarting SMT also restarts the Web server.

For detailed information about managing certification and further usage of the YaST CA Man-agement module and the Common Server Certificate module, refer to the Security Guide. It isavailable from https://www.suse.com/documentation/sles-12 .

7.3.3 Importing a Common Server Certificate

You can import an own common server certificate from a le. The certificate to be importedneeds to be in the PKCS12 format with CA chain. Common server certificates can be importedwith the YaST Common Server Certificate module.

To import an own certificate with YaST, proceed as follows:

1. Start YaST and select Security and Users Common Server Certificate. Alternatively, startthe YaST Common Server Certificate module from the command line by entering yast2common_cert as root .The description of the currently used common server certificate is shown in the dialogthat opens.

2. Click Import and select the le containing the certificate to be imported. Specify the cer-tificate password in the Password eld.

71 Importing a Common Server Certificate SLES 12 SP4

https://www.suse.com/documentation/sles-12

3. Click Next. If the certificate is successfully imported, close YaST with Finish.

4. After having created a new certificate, restart SMT using the systemctl restartsmt.target command. Restarting SMT ensures that the new certificate is copied from/etc/ssl/certs/YaST-CA.pem to /srv/www/htdocs/smt.crt , the copy SMT uses.Restarting SMT also restarts the Web server.

7.3.4 Synchronizing Time between SMT Server and Clients

The synchronization of time between the SMT server and clients is highly recommended. Eachserver certificate has a validity period. If the client happens to be set to a time outside of thisperiod, the certificate validation on the client side fails.

Therefore, it is advisable to keep the time on the server and clients synchronized. You can easilysynchronize the time using NTP (network time protocol). Use yast2 ntp-client to configurean NTP client. Find detailed information about NTP in the Administration Guide.

72 Synchronizing Time between SMT Server and Clients SLES 12 SP4

8 Configuring Clients to Use SMT

Any machine running SUSE Linux Enterprise 10 SP4, 11 SP1 or later, or any version of SUSELinux Enterprise 12 can be configured to register against SMT and download software updatesfrom there, instead of communicating directly with SUSE Customer Center or Novell CustomerCenter.

If your network includes an SMT server to provide a local update source, you need to equip theclient with the server's URL. As client and server communicate via the HTTPS protocol duringregistration, you also need to make sure the client trusts the server's certificate. In case you setup your SMT server to use the default server certificate, the CA certificate will be available onthe SMT server at http://FQDN/smt.crt .

If the certificate is not issued by a well-trusted authority, the registration process will import thecertificate from the URL specified as regcert parameter (SUSE Linux Enterprise Server 10 and11). For SLE 12, the certificate will be downloaded automatically from SMT. In this case, theclient displays the new certificate details (its fingerprint), and you need to accept the certificate.

There are several ways to provide the registration information and to configure the client ma-chine to use SMT:

1. Provide the required information via kernel parameters at boot time (Section 8.1, “Using

Kernel Parameters to Access an SMT Server”).

2. Configure the clients using an AutoYaST profile (Section 8.2, “Configuring Clients with AutoYaST

Profile”).

3. Use the clientSetup4SMT.sh script (Section 8.3, “Configuring Clients with the clientSet-

up4SMT.sh Script in SLE 11 and 12”). This script can be run on a client to make it registeragainst a specified SMT server.

4. In SUSE Linux Enterprise 11 and 12, you can set the SMT server URL with the YaST regis-tration module during installation (Section 8.4, “Configuring Clients with YaST”).

These methods are described in the following sections.

73 SLES 12 SP4

8.1 Using Kernel Parameters to Access an SMT Server

Important: regcert Parameter SupportNote that the regcert kernel boot parameter is supported for SLE 10 and 11. It is notsupported from SLE 12.

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

Warning: Beware of Typing ErrorsMake 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 tothe certificate. In case regcert is not specified, it will default to http://FQDN/smt.crtwith FQDN being the name of the SMT server.

regurl

URL of the SMT server.For SLE 11 and older clients, the URL needs to be in the following format: https://FQDN/center/regsvc/ with FQDN being the fully qualified host name of the SMT server. It mustbe identical to the FQDN of the server certificate used on the SMT server. Example:

regurl=https://smt.example.com/center/regsvc/

For SLE 12 clients, the URL needs to be in the following format: https://FQDN with FQDNbeing the fully qualified host name of the SMT server. It must be identical to the FQDN ofthe server certificate used on the SMT server. Example:

regurl=https://smt.example.com/

74 Using Kernel Parameters to Access an SMT Server SLES 12 SP4

regcert

Location of the SMT server's CA certificate. Specify one of the following locations:

URL

Remote location (HTTP, HTTPS, or FTP) from which the certificate can be down-loaded. Example:

regcert=http://smt.example.com/smt.crt

Floppy

Specifies a location on a floppy. The floppy needs to be inserted at boot time—youwill not be prompted to insert it if it is missing. The value needs to start with thestring floppy , followed by the path to the certificate. Example:

regcert=floppy/smt/smt-ca.crt

Local Path

Absolute path to the certificate on the local machine. Example:

regcert=/data/inst/smt/smt-ca.cert

Interactive

Use ask to open a pop-up menu during installation where you can specify the pathto the certificate. Do not use this option with AutoYaST. Example:

regcert=ask

Deactivate Certificate Installation

Use done if either the certificate will be installed by an add-on product, or if youare using a certificate issued by an official certificate authority. Example:

regcert=done

Warning: Change of SMT Server CertificateIf the SMT server gets a new certificate from an untrusted CA, the clients need to retrievethe new CA certificate le.

On SLE 10 and 11, this is done automatically with the registration process in the followingcases:

If a URL was used at installation time to retrieve the certificate.

If the regcert parameter was omitted and thus the default URL is used.

75 Using Kernel Parameters to Access an SMT Server SLES 12 SP4

If the certificate was loaded using any other method, such as floppy or local path, theCA certificate will not be updated.

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

8.2 Configuring Clients with AutoYaST ProfileClients can be configured to register with SMT server via AutoYaST profile. For general infor-mation about creating AutoYaST profiles and preparing automatic installation, refer to the Au-toYaST Guide. In this section, only SMT specific configuration is described.

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

8.2.1 Configuring SUSE Linux Enterprise 11 Clients

1. As root , start YaST and select Miscellaneous Autoinstallation to start the graphical Au-toYaST front-end.From a command line, you can start the graphical AutoYaST front-end with the yast2autoyast command.

2. Open an existing profile using File Open, create a profile based on the current system'sconfiguration using Tools Create Reference Profile, or work with an empty profile.

3. Select Software Novell Customer Center Configuration. An overview of the current config-uration is shown.

4. Click Configure.

5. Set the URL of the SMT Server and, optionally, the location of the SMT Certificate. Thepossible values are the same as for the kernel parameters regurl and regcert (seeSection 8.1, “Using Kernel Parameters to Access an SMT Server”). The only exception is that theask value for regcert does not work in AutoYaST, because it requires user interaction.If using it, the registration process will be skipped.

6. Perform all other configuration needed for the systems to be deployed.

76 Configuring Clients with AutoYaST Profile SLES 12 SP4

7. Select File Save As and enter a le name for the profile, such as autoinst.xml .

8.2.2 Configuring SUSE Linux Enterprise 12 Clients

1. As root , start YaST and select Miscellaneous Autoinstallation to start the graphical Au-toYaST front-end.From a command line, you can start the graphical AutoYaST front-end with the yast2autoyast command.

2. Open an existing profile using File Open, create a profile based on the current system'sconfiguration using Tools Create Reference Profile, or work with an empty profile.

3. Select Software Product Registration. An overview of the current configuration is shown.

4. Click Edit.

5. Check Register the Product, set the URL of the SMT server in Use Specific Server URL Insteadof the Default, and you can set the Optional SSL Server Certificate URL. The possible valuesfor the server URL are the same as for the kernel parameter regurl . For the SSL certificatelocation, you can use either HTTP or HTTPS based URLs.

6. Perform all other configuration needed for the systems to be deployed, then click Finishto return to the main screen.

7. Select File Save As and enter a le name for the profile, such as autoinst.xml .

8.3 Configuring Clients with the clientSetup4SMT.shScript in SLE 11 and 12In SLE 11 and 12, the /usr/share/doc/packages/smt/clientSetup4SMT.sh script is provid-ed 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 wgetThe script clientSetup4SMT.sh itself uses wget , so wget must be installed on theclient.

77 Configuring SUSE Linux Enterprise 12 Clients SLES 12 SP4

Important: Upgrade clientSetup4SMT.shIf you migrated your client OS from an older SUSE Linux Enterprise, check if the versionof the clientSetup4SMT.sh script on your host is up to date. clientSetup4SMT.shfrom older versions of SMT cannot manage SMT 12 clients. If you apply software patch-es regularly on your SMT server, you can always nd the latest version of clientSet-up4SMT.sh at <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh .

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

1. Copy the clientSetup4SMT.sh script from your SMT server to the client machine. Thescript is available at <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh and /srv/www/htdocs/repo/tools/clientSetup4SMT.sh . You can download it with a browser,using wget , or by another means, such as with scp .

2. As root , execute the script on the client machine. The script can be executed in two ways.In the rst case, the script name is followed by the registration URL. For example:

./clientSetup4SMT.sh https://smt.example.com/center/regsvc/

In the second case, the script uses the --host option followed by the host name of theSMT server, and --regcert followed by the URL of the SSL certificate; for example:

./clientSetup4SMT.sh --host smt.example.com \ --regcert http://smt.example.com/smt.crt

In this case, without any “namespace” specified, the client will be configured to use thedefault production repositories. If --namespace GROUPNAME is specified, the client willuse that staging group.

3. The script downloads the server's CA certificate. Accept it by pressing Y .

4. The script performs all necessary modifications on the client. However, the registrationitself is not performed by the script.

5. The script downloads and asks to accept additional GPG keys to sign repositories with.

6. On SLE 11, perform the registration by executing suse_register or running the yast2inst_suse_register module on the client.

78 Configuring Clients with the clientSetup4SMT.sh Script in SLE 11 and 12 SLES 12 SP4

On SLE 12, perform the registration by executing

SUSEConnect -p PRODUCT_NAME --url https://smt.example.org

or running the yast2 registration (SUSE Linux Enterprise Server 12 SP1 and newer)or yast2 scc (SUSE Linux Enterprise Server 12) module on the client.

The clientSetup4SMT.sh script works with SUSE Linux Enterprise 10 SP2 and later ServicePacks, 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 LinuxEnterprise 12When registering an existing system against SMT 12—both on the command line andusing YaST—you need to register additional extensions and modules separately, one byone. This applies both to already installed extensions and to extensions that you plan toinstall.

8.3.1 Problems Downloading GPG Keys from the Server

The apache2-example-pages package includes a robots.txt le. The le is installed intothe Apache2 document root directory, and controls how clients can access les from the Webserver. If this package is installed on the server, clientSetup4SMT.sh fails to download thekeys stored under /repo/keys .

You can solve this problem by either editing robots.txt , or uninstalling the apache2-exam-ple-pages package.

If you choose to edit the robots.txt le, add before the Disallow: / statement:

Allow: /repo/keys

79 Problems Downloading GPG Keys from the Server SLES 12 SP4

8.4 Configuring Clients with YaST

8.4.1 Configuring Clients with YaST in SLE 11

To configure a client to perform the registration against an SMT server use the YaST registrationmodule ( yast2 inst_suse_register ).

Click Advanced Local Registration Server and enter the name of the SMT server plus the path tothe registration internals ( /center/regsvc/ ), for example:

https://smt.example.com/center/regsvc/

After confirmation the certificate is loaded and the user is asked to accept it. Then continue.

Warning: Staging Groups RegistrationIf a staging group is used, make sure that settings in /etc/suseRegister.conf are doneaccordingly. If not already done, modify the register= parameter and append &name-space=NAMESPACE . For more information about staging groups, see Section 4.3, “Staging

Repositories”.

Alternatively, use the clientSetup4SMT.sh script (see Section 8.3, “Configuring Clients with

the clientSetup4SMT.sh Script in SLE 11 and 12”).

8.4.2 Configuring Clients with YaST in SLE 12

To configure a client to perform the registration against an SMT server use the YaST ProductRegistration module yast2 registration (SUSE Linux Enterprise Server 12 SP1 or newer) oryast2 scc (SUSE Linux Enterprise Server 12).

On the client, the credentials are not necessary and you may leave the relevant elds empty.Click Local Registration Server and enter its URL. Then click Next until the exit from the module.

80 Configuring Clients with YaST SLES 12 SP4

8.5 Registering SLE11 Clients against SMT TestEnvironmentTo configure a client to register against the test environment instead of the production environ-ment, 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”.

8.6 Registering SLE12 Clients against SMT TestEnvironmentTo configure a client to register against the test environment instead of the production environ-ment, 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”.

8.7 Listing Accessible RepositoriesTo retrieve the accessible repositories for a client, download repo/repoindex.xml from theSMT server with the client's credentials. The credentials are stored in /etc/zypp/credential-s.d/SCCcredentials (SUSE Linux Enterprise Server 12) or /etc/zypp/credentials.d/NCC-credentials (SUSE Linux Enterprise Server 11) on the client machine. Using wget , the com-mand for testing could be as follows:

wget https://USER:[email protected]/repo/repoindex.xml

repoindex.xml returns the complete repository list as they come from the vendor. If a repos-itory is marked for staging, repoindex.xml lists the repository in the full namespace ( re-pos/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 .

81 Registering SLE11 Clients against SMT Test Environment SLES 12 SP4

8.8 Online Migration of SUSE Linux Enterprise ClientsSUSE Linux Enterprise clients registered against SMT can be migrated online to the latest servicepack of the same major release the same way as clients registered against SUSE Customer Centeror Novell Customer Center. Before starting the migration, make sure that SMT is configured toprovide 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 19 “Upgrading SUSE Linux Enterprise” for SUSE Linux Enterprise 12clients.

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

Note: SUSE Linux Enterprise Server 10Configuring RHEL client with Subscription Management Tool for SUSE Linux Enterprise(SMT 1.0) running SUSE Linux Enterprise Server 10 is slightly different. For more infor-mation, see How to update Red Hat Enterprise Linux with SMT. (http://www.novell.com/sup-

port/search.do?usemicrosite=true&searchString=7001751)

8.9.1 How to Prepare SMT Server for Mirroring and PublishingUpdates for RHEL

1. Install SUSE Linux Enterprise Server (SLES) with the SMT packages as per the documen-tation on the respective products.

2. During SMT setup, use organization credentials that have access to Novell-provided RHELupdate repositories.

82 Online Migration of SUSE Linux Enterprise Clients SLES 12 SP4



http://www.suse.com/products/expandedsupport/

http://www.novell.com/support/search.do?usemicrosite=true&searchString=7001751

http://www.novell.com/support/search.do?usemicrosite=true&searchString=7001751

3. Verify that the organization credentials have access to download updates for the Red Hatproducts with

smt-repos -m | grep RES

4. Enable mirroring of the RHEL update repositories for the desired architecture(s):

smt-repos -e REPO-NAME ARCHITECTURE

5. Mirror the updates and log verbose output:

smt-mirror -d -L /var/log/smt/smt-mirror.log

The updates for RHEL will also be mirrored automatically as part of the default nightlySMT mirroring cron job. When the mirror process of the repositories for your RHEL prod-ucts has completed, the updates are available via

http://smt-server.your-domain.top/repo/$RCE/REPOSITORY_NAME/ARCHITECTURE/

6. To enable GPG checking of the repositories, the key used to sign the repositories needs tobe made available to the RHEL clients. This key is now available in the res-signingkeyspackage, which is included in the SMT 11 installation source.

Install the res-signingkeys package with the command

zypper in -y res-signingkeys

The installation of the package stores the key le as /srv/www/htdocs/repo/keys/res-signingkeys.key .

Now the key is available to the clients and can be imported into their RPM databaseas described later.

8.9.2 How to Configure the YUM Client on RHEL 5.2 to ReceiveUpdates from SMT

1. Import the repository signing key downloaded above into the local RPM database with

rpm --import http://smt.example.com/repo/keys/res-signingkeys.key

2. Create a le in /etc/yum.repos.d/ and name it RES5.repo .

83 How to Configure the YUM Client on RHEL 5.2 to Receive Updates from SMT SLES 12 SP4

3. Edit the le and enter the repository data, and point to the repository on the SMT serveras follows:

[smt]name=SMT repositorybaseurl=http://smt.example.com/repo/$RCE/REPOSITORY_NAME/ARCHITECTURE/enabled=1gpgcheck=1

Example of base URL:

http://smt.mycompany.com/repo/$RCE/RES5/i386/

4. Save the le.

5. Disable standard Red Hat repositories by setting

enabled=0

in the repository entries in other les in /etc/yum.repos.d/ (if any are enabled).Both YUM and the update notification applet should work correctly now and notify ofavailable updates when applicable. You may need to restart the applet.

8.9.3 How to Configure the UP2DATE Client on RHEL 3.9 and 4.7 toReceive Updates from SMT

1. Import the repository signing key downloaded above into the local RPM database with

rpm --import http://smt.example.com/repo/keys/res-signingkeys.key

2. Edit the le /etc/sysconfig/rhn/sources and make the following changes:

3. Comment out any lines starting with up2date .Normally, there will be a line that says "up2date default".

4. Add an entry pointing to the SMT repository (all in one line):

yum REPO_NAME http://smt.example.com/repo/$RCE/REPOSITORY_NAME/ARCHITECTURE/

where repo-name should be set to RES3 for 3.9 and RES4 for 4.7.

5. Save the le.

84

How to Configure the UP2DATE Client on RHEL 3.9 and 4.7 to Receive Updates from

SMT SLES 12 SP4

Both up2date and the update notification applet should work correctly now, pointing to the SMTrepository and indicating updates when available. In case of trouble, try to restart the applet.

To ensure correct reporting of the Red Hat Enterprise systems in SUSE Customer Center, theyneed to be registered against your SMT server. For this a special suseRegisterRES package isprovided through the RES* repositories and it should be installed, configured and executed asdescribed below.

8.9.4 How to Register RHEL 5.2 against SMT

1. Install the suseRegisterRES package.

yum install suseRegisterRES

Note: Additional PackagesYou may need to install the perl-Crypt-SSLeay and perl-XML-Parser packagesfrom the original RHEL media.

2. Copy the SMT certificate to the system:

wget http://smt.example.com/smt.crt

cat smt.crt >> /etc/pki/tls/cert.pem

3. Edit /etc/suseRegister.conf to point to SMT by changing the URL value to

url: https://smt.example.com/center/regsvc/

4. Register the system:

suse_register

8.9.5 How to Register RHEL 4.7 and RHEL 3.9 against SMT

1. Install the suseRegisterRES package:

up2date --get suseRegisterRESup2date --get perl-XML-Writer

85 How to Register RHEL 5.2 against SMT SLES 12 SP4

rpm -ivh /var/spool/up2date/suseRegisterRES*.rpm /var/spool/up2date/perl-XML-Writer-0*.rpm

Note: Additional PackagesYou may need to install the perl-Crypt-SSLeay and perl-XML-Parser packagesfrom the original RHEL media.

2. Copy the SMT certificate to the system:

wget http://smt.example.com/smt.crt

cat smt.crt >> /usr/share/ssl/cert.pem

3. Edit /etc/suseRegister.conf to point to SMT by changing the URL value to

url = https://smt.example.com/center/regsvc/

or (for SUSE Customer Center)

url = https://smt.example.com

4. Register the system:

suse_register

86 How to Register RHEL 4.7 and RHEL 3.9 against SMT SLES 12 SP4

9 Advanced Topics

This chapter covers usage scenarios beyond the regular workflow to give you more control overyour SMT server.

9.1 Backup of the SMT ServerCreating backups of the SMT server regularly can help restore it quickly and reliably if theserver fails.

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

Configuration les

Package repositories

The database

9.1.1 Configuration Files and Repositories

The SMT server configuration is stored in the /etc/smt.conf le and les in the /etc/smt.ddirectory.

As SMT depends on the services provided by the Apache Web server and Maria DB databaseengine, you need to back up their configuration les as well. Apache configuration les arelocated in the /etc/apache2 directory, while configuration of Maria DB is stored in /etc/my.cnf , /etc/mysqlaccess.conf , and les in the /etc/my.cnf.d directory.

Package repositories are stored in the /srv/www/htdocs/repo directory. While you can nor-mally mirror the repositories on the restored server from the update server as well, the downloadcan take a long time. Therefore backing up the repositories can save you time and bandwidth.Moreover, backing up the repositories is necessary if you are using repository staging and wantto restore the snapshots of the repositories (see Section 3.6, “Testing and Filtering Update Repositories

with Staging”).

Warning: Size of the RepositoriesThe software repositories can be significant in size, and you will need to transfer themfrom the update server.

87 Backup of the SMT Server SLES 12 SP4

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

9.1.2 The Database

SMT uses the Maria DB database to store information about clients, registrations, machine data,which repositories are enabled for mirroring, and custom repositories. Unlike the configurationles and repositories, the database information cannot be recovered without a valid backup.

To back up the SMT database, you can for example create a cron job that performs an SQL dumpinto a plain text le:

mysqldump -u root -p SMT_DB_PASSWORD smt > /BACKUP_DIR/smt-db-backup.sql

Then add the resulting le to your regular backup jobs.

9.2 Disconnected SMT ServersIn some restricted environments it is not possible for SMT servers to access the Internet becausethey are located on disconnected or isolated networks. In this case, you can back up the relevantdata on an external storage device using special parameters with the SMT commands.

You need an external SMT server that mirrors the repositories from SUSE Customer Center.Then you can transfer these repositories to the SMT servers on the isolated network using theexternal storage device.

FIGURE 9.1: SMT DISCONNECTED SETUP

88 The Database SLES 12 SP4

Although the initial setup of this solution requires additional configuration, the regular updatesynchronization with SUSE Customer Center and distribution to isolated servers is simple. Thesteps required during the initial setup are as follows:

Installing and configuring the external SMT server

Installing the internal server

Editing /etc/smt.conf and setting up a cron job on the internal SMT server

Transferring the SUSE Customer Center data from the external SMT server to the internalserver

Enabling and disabling repositories on the internal server

Creating an SMT database replacement le on the internal server—when performing mir-ror jobs, this le can be used instead of the normal Maria DB database

Day-to-day operation requires the following actions:

Running the smt-mirror job on the external server

Synchronizing the mirrored repositories from the external storage device to the internalSMT server

Below is a detailed description of the individual steps.

PROCEDURE 9.1: EXTERNAL SMT SERVER CONFIGURATION FOR THE DISCONNECTED SETUP

1. Install and configure SMT as described in Chapter 1, SMT Installation.

2. Enable the repositories for use by the internal SMT servers.

3. Perform a standard repository mirroring from SUSE Customer Center with smt-mirror .

4. Attach a removable storage device to the server and mount it.

5. Export the required SUSE Customer Center data to a directory on the mounted storagedevice:

a. Create a directory with correct permissions for storing the data. Because the smtcommands run as the smt user (whose numeric UID can differ between the servers),you need to make permissions for the directories on the external storage device lessrestrictive:

chmod o+w /path/to/scc/dir/on/storage/device

89 Disconnected SMT Servers SLES 12 SP4

b. Export the SUSE Customer Center data:

smt-sync --todir /path/to/scc/dir/on/storage/device

6. Create a directory with correct permissions:

mkdir /path/to/repository/on/storage/devicechmod o+w /path/to/repository/on/storage/device

7. Unmount and detach the storage device.

PROCEDURE 9.2: INTERNAL SMT SERVER CONFIGURATION FOR THE DISCONNECTED SETUP

1. Ensure you have a working SUSE Linux Enterprise Server installation source.

2. Install SMT the same way as on the external server with the following exceptions:

a. Start the SMT Wizard:

tux > sudo yast2 smt-wizard

The rst step of the wizard shows the Customer Center Configuration.

b. In the User and Password text boxes, enter random strings (the boxes must not beleft empty).

c. Set up the database, SSL certificate and everything else as you would normally do.

d. Finish the SUSE Customer Center Configuration wizard.

e. In the final step of the wizard, Writing SMT Configuration, ignore the following errormessage:

Running the synchronization script failed

3. Re-launch the YaST Subscription Management Tool Server Configuration module ( yast2smt-server ) and go to the Scheduled SMT Jobs tab.

4. Delete SCC Registration and Synchronization of Updates jobs.

5. Click OK to finish the wizard, provide the SMT user password, and acknowledge the syn-chronization error again.

6. Prevent registration data upstream synchronization to SUSE Customer Center by setting


forwardRegistration = false

in /etc/smt.conf .

7. Connect an external storage device and mount it.

8. Populate the SMT database with the previously created SUSE Customer Center data:

smt-sync --fromdir /path/to/scc/dir/on/mobile/disk

9. Enable mirroring of the desired repositories using the smt-repos -e command.

10. Create a database replacement le on the external storage device:

smt-sync --createdbreplacementfile /path/to/dbrepl/file/on/mobile/disk

11. Unmount and detach the storage device.

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

PROCEDURE 9.3: DAILY EXTERNAL SMT SERVER OPERATION

1. Connect an external storage device and mount it.

2. Perform a mirror to a directory on the storage device based on the le stored on it:

smt-mirror --dbreplfile /path/to/dbrepl/file/on/storage/device \ --fromlocalsmt --directory /path/to/repository/on/storage/device \ -L /var/log/smt/smt-mirror-example.log

3. Update the database on the storage device with the product and subscription info fromSUSE Customer Center:

smt-sync --todir /path/to/scc/dir/on/storage/device

4. Optionally, scan the storage device for viruses and other unwanted content.

5. Unmount and disconnect the storage device.

PROCEDURE 9.4: DAILY INTERNAL SMT SERVER OPERATION

1. Connect a storage device and mount it.


2. Update the SUSE Customer Center data on the server:

smt-sync --fromdir /path/to/scc/dir/on/storage/device

3. Mirror from the storage device to the server:

smt-mirror --fromdir /path/to/repository/on/storage/device

4. Update the SUSE Customer Center data on the storage device with local changes in themirror status since the last synchronization:

smt-sync --createdbreplacementfile /path/to/dbrepl/file/on/storage/device

5. Unmount and disconnect the storage device.


A SMT REST API

The SMT REST interface is meant for communication with SMT clients and integration intoother Web services. The base URI for all the following REST calls is https://YOURSMTSERV-ER/=/1 . The SMT server responds with XML data described for each call by an RNC snippetwith comments.

Quick Reference

Note: API for authenticating SMT clients.Used internally in the smt-client package. Not intended for general administra-tive use!

GET /jobs get list of all jobs for clientGET /job/@next get the next job for clientGET /job/<jobid> get job with jobid for client. Note: this marks the job as retrievedPUT /job/<jobid> update job having <jobid> using XML data. Note: updates only retrieved jobs

For backward compatibility reasons, the following are also available:

GET /jobs/@next same as GET /job/@nextGET /jobs/<jobid> same as GET /job/<jobid>PUT /jobs/<jobid> same as PUT /job/<jobid>

API for general access (this needs authentication using credentials from the [REST] sectionof smt.conf ).

GET /client get data of all clientsGET /client/<GUID> get data of client with specified GUIDGET /client/<GUID>/jobs get client's job dataGET /client/<GUID>/patchstatus get client's patch statusGET /client/<GUID>/job/@next get client's next jobGET /client/<GUID>/job/<jobid> get specified client job dataGET /client/@all/jobs get job data of all clientsGET /client/@all/patchstatus get patch status of all clientsGET /repo get all repositories known to SMTGET /repo/<repoid> get details of repository with <repoid>GET /repo/<repoid>/patches get repository's patches

93 SLES 12 SP4

GET /patch/<patchid> get patch <patchid> detailsGET /product get list of all products known to SMTGET /product/<productid> get details of product with <productid>GET /product/<productid>/repos get list of product's repositories

For backward compatibility reasons, plural forms are also available; for example:

GET /clients same as GET /clientGET /repos same as GET /repoGET /product same as GET /product

Detailed Description

API for authenticating clients:

GET /jobs

Get list of all jobs for an authenticating client. When getting the jobs via this paththey will not be set to the status retrieved.Example:

<jobs> <job name="Patchstatus Job" created="2010-06-18 16:34:38" description="Patchstatus Job for Client 456" exitcode="" expires="" finished="" guid="456" guid_id="30" id="31" message="" parent_id="" persistent="1" retrieved="" status="0" stderr="" stdout="" targeted="" timelag="23:00:00" type="1" verbose="0"> <arguments></arguments> </job> <job name="Software Push" created="2010-06-18 16:37:59" description="Software Push: mmv, whois" exitcode="" expires="" finished="" guid="456" guid_id="30" id="32" message="" parent_id="" persistent="0" retrieved="" status="0" stderr="" stdout="" targeted="" timelag="" type="2" verbose="0"> <arguments> <packages> <package>mmv</package> <package>whois</package> </packages> </arguments> </job> <job name="Update Job" created="2010-06-18 16:38:39" description="Update Job" exitcode="" expires="" finished="" guid="456" guid_id="30" id="34" message="" parent_id="" persistent="0" retrieved="" status="0" stderr="" stdout="" targeted="" timelag="" type="3" verbose="0"> <arguments></arguments> </job> <job name="Execute" created="2010-06-18 17:40:10" description="Execute custom command" exitcode="0" expires="" finished="2010-06-18 17:40:14"

94 SLES 12 SP4

guid="456" guid_id="30" id="41" message="execute successfully finished" parent_id="" persistent="0" retrieved="2010-06-18 17:40:14" status="1" stderr="man:x:13:62:Manual pages viewer:/var/cache/man:/bin/bash" stdout="" targeted="" timelag="" type="4" verbose="1"> <arguments command="grep man /etc/passwd" /> </job> <job name="Reboot" created="2010-06-18 16:40:28" description="Reboot now" exitcode="" expires="2011-06-12 15:15:15" finished="" guid="456" guid_id="30" id="37" message="" parent_id="" persistent="0" retrieved="" status="0" stderr="" stdout="" targeted="2010-06-12 15:15:15" timelag="" type="5" verbose="0"> <arguments></arguments> </job> <job name="Wait 5 sec. for exit 0." created="2010-06-18 16:40:59" description="Wait for 5 seconds and return with value 0." exitcode="" expires="" finished="" guid="456" guid_id="30" id="38" message="" parent_id="" persistent="0" retrieved="" status="0" stderr="" stdout="" targeted="" timelag="" type="7" verbose="0"> <arguments exitcode="0" waittime="5" /> </job> <job name="Eject job" created="2010-06-18 16:42:00" description="Job to eject the CD/DVD drawer" exitcode="" expires="" finished="" guid="456" guid_id="30" id="39" message="" parent_id="" persistent="0" retrieved="" status="0" stderr="" stdout="" targeted="" timelag="" type="8" verbose="0"> <arguments action="toggle" /> </job></jobs>

GET /jobs/@next

Get the next job for an authenticating client. The job will not be set to the retrievedstatus.Example:

<job id="31" guid="456" type="patchstatus" verbose="false"> <arguments></arguments></job>

GET /jobs/<jobid>

Get a job with the specified jobid for an authenticating client. The job will be set tothe retrieved status.When the client retrieves a job, not all the metadata is part of the XML response.However, it can be the full set of metadata, as smt-client only picks the data thatis relevant. But a job retrieval should only contain the minimal set of data that isrequired to fulfill it.

95 SLES 12 SP4

RNC:

start = element job { attribute id {xsd:integer}, # the job ID. A job id alone is not unique. # A job is only uniquely identified with # guid and id. The same jobs for multiple # clients have the same job id. attribute parent_id {xsd:integer}?, # ID of the job on which this job depends attribute guid {xsd:string}, attribute guid_id {xsd:integer}?, # internal database ID of the client # (for compatibility reasons, if third # party application talks to SMT REST # service). attribute type { # job type ID string. Must be unique and # equal to the name of the Perl module on # the client. "softwarepush", "patchstatus", "<custom>" # add your own job types }, attribute name {xsd:string}, # short custom name of the job, user-defined attribute description {xsd:string}, # custom description of what the job does attribute created {xsd:string}, # time stamp of creation attribute expires {xsd:string}, # expiration time stamp; the job expires # if not retrieved by then attribute finished {xsd:string}, # time stamp of job completion attribute retrieved {xsd:string}, # time stamp of retrieval of the job attribute persistent {xsd:boolean}?, # defines whether the job is a persistent # (repetitive) job attribute verbose {xsd:boolean}, # if true, output of job commands is # attached to the result attribute exitcode {xsd:integer}, # the last exit code of the system command # executed to complete the job attribute message {xsd:string}, # custom human-readable message the client # sends back as a result attribute status { # logical status of the job 0, # not yet worked on: The job may be already retrieved but no # result was sent back yet. 1, # success: The job was retrieved, processed and the client sent # back a success response. 2, # failed: The job was retrieved, processed and the client sent # back a failure response.

96 SLES 12 SP4

3}, # denied by client: The job was retrieved but could not be # processed as the client denied to process this job type # (a client needs to allow all job types that should be processed, # any other will be denied). attribute stderr {text}, # standard error output of jobs's system # commands (filled if verbose) attribute stdout {text}, # standard output of jobs's system # commands (filled if verbose) attribute targeted {xsd:string}, # time stamp when this job will be # delivered at the earliest attribute timelag {xsd:string}?, # interval time of a persistent job in # the format "HH:MM:SS" (HH can be # bigger than 23) element-arguments # job-type-specific XML data}

Example (minimal job definition for a 'softwarepush' job):

<job id="32" guid="456" type="softwarepush" verbose="false"> <arguments> <packages> <package>mmv</package> <package>whois</package> </packages> </arguments></job>

PUT /job/<jobid>

Update a job for an authenticating client using XML data.A client can only send job results for jobs properly retrieved previously. The jobswill be set to status done (except for persistent jobs, in which case a new target timewill be computed).Examples:

Example for a successful patchstatus job:

<job id="31" guid="abc123" exitcode="0" message="0:0:0:0 # PackageManager=0 Security=0 Recommended=0 Optional=0" status="1" stderr="" stdout="" />

Example for a failed softwarepush:

<job id="32" guid="abc123" exitcode="104" message="softwarepush failed" status="2" stderr="" stdout="" />

97 SLES 12 SP4

Example for a successful update:

<job id="34" guid="abc123" exitcode="0" message="update successfully finished" status="1" stderr="" stdout="" />

Example for a successful reboot job:

<job id="37" guid="abc123" exitcode="0" message="reboot triggered" status="1" stderr="" stdout="" />

Execute for a successful wait job:

<job id="38" guid="abc123" exitcode="0" message="wait successfully finished" status="1" stderr="" stdout="" />

Example for a successful eject job:

<job id="39" guid="abc123" exitcode="0" message="eject successfully finished" status="1" stderr="" stdout="" />

Example for a successful execute job:

<job id="41" guid="abc123" exitcode="0" message="execute successfully finished" status="1" stderr="man:x:13:62:Manual pages viewer:/var/cache/man:/bin/bash" stdout="" />

API for general access:

GET /repo/<repoid>

Returns detailed information about the specified repository. The <repoid> can beobtained using the /repos or /products/<productid>/repos/ call.RNC:

start = element repo { # repository attribute id {xsd:integer}, # SMT ID of the repository attribute name {xsd:string}, # repository's Unix name attribute target {xsd:string}, # repository's target product attribute type {"nu" | "yum" | "zypp" | "pum"}, # type of repository element description {xsd:string}, # description of the repository element localpath {xsd:string}, # path to local SMT mirror of the # repository element url {xsd:anyURI}, # original URL of the repository element mirrored { attribute date {xsd:integer} # timestamp of the last successful

98 SLES 12 SP4

# mirror (empty if not mirrored yet) }}

Example:

<repo name="SLES10-SP2-Updates" id="226" target="sles-10-i586" type="nu"> <description>SLES10-SP2-Updates for sles-10-i586</description> <localpath>/local/htdocs/repo/$RCE/SLES10-SP2-Updates/sles-10-i586</localpath> <mirrored date="1283523440"/> <url>https://nu.novell.com/repo/$RCE/SLES10-SP2-Updates/sles-10-i586/</url></repo>

GET /repo/<repoid>/patches

Returns a list of all patches in the specified software repository. The repoid can beobtained using the /repos or /products/<productid>/repos/ call.RNC:

start = element patches { element patch { attribute id {xsd:integer}, # SMT ID of the patch attribute name {xsd:string}, # patch's Unix name attribute version {xsd:integer} # patch's version number attribute category { # patch importance category "security", "recommended", "optional", "mandatory"} }*}

Example:

<patches> <patch name="slesp2-krb5" category="security" id="1471" version="6775"/> <patch name="slesp2-heartbeat" category="recommended" id="1524" version="5857"/> <patch name="slesp2-curl" category="security" id="1409" version="6402"/> ...</patches>

GET /repos

Returns a list of all software repositories known to SMT. Those which are currentlymirrored on SMT have non-empty mirror time stamp in the mirrored attribute.

99 SLES 12 SP4

RNC:

start = element repos { element repo { attribute id {xsd:integer}, # SMT ID of the repository attribute name {xsd:string}, # repository's Unix name attribute target {xsd:string}, # repository's target product attribute mirrored {xsd:integer} # time stamp of the last successful mirror # (empty if not mirrored yet) }*}

Example:

<repos> <repo name="SLE10-SDK-Updates" id="1" mirrored="" target="sles-10-x86_64"/> <repo name="SLE10-SDK-SP3-Pool" id="2" mirrored="" target="sles-10-ppc"/> <repo name="SLES10-SP2-Updates" id="226" mirrored="1283523440" target="sles-10-i586"/> ...</repo>

GET /patch/<patchid>

Returns detailed information about the specified patch. The patchid can be obtainedvia the /repo/<repoid>/patches call.RNC:

start = element patch { attribute id {xsd:integer}, # SMT ID of the patch attribute name {xsd:string}, # patch's Unix name attribute version {xsd:integer}, # patch's version number attribute category { # patch importance category "security", "recommended", "optional", "mandatory"}, element title {xsd:string}, # title of the patch element description {text}, # description of issues fixed by the patch element issued { attribute date {xsd:integer} # patch release time stamp }, element packages { # packages which need update as part # of this patch element package { # individual RPM package data

100 SLES 12 SP4

attribute name {xsd:string}, # package name attribute epoch {xsd:integer}, # epoch number attribute version {xsd:string}, # version string attribute release {xsd:string}, # release string attribute arch {xsd:string}, # architecture string element origlocation {xsd:anyURI}, # URL of the RPM package in the # original repository element smtlocation {xsd:anyURI} # URL of the RPM package at the SMT server }* }, element references { # references to issues fixed by this # patch element reference { # individual reference details attribute id, # ID number of the issue (bugzilla # or CVE number) attribute title {xsd:string}, # issue title attribute type {"bugzilla","cve"}, # type of the issue attribute href {xsd:anyURI} # URL of the issue in its issue # tracking system }* }}

Example:

<patch name="slesp2-krb5" category="security" id="1471" version="6775"> <description> Specially crafted AES and RC4 packets could allow unauthenticated remote attackers to trigger an integer overflow leads to heap memory corruption (CVE-2009-4212). This has been fixed. Specially crafted AES and RC4 packets could allow unauthenticated remote attackers to trigger an integer overflow leads to heap memory corruption (CVE-2009-4212). </description> <issued date="1263343020"/> <packages> <package name="krb5" arch="i586" epoch="" release="19.43.2" version="1.4.3"> <origlocation>https://nu.novell.com/repo/$RCE/SLES10-SP2-Updates/sles-10-i586/rpm/i586/krb5-1.4.3-19.43.2.i586.rpm</origlocation> <smtlocation>http://kompost.suse.cz/repo/$RCE/SLES10-SP2-Updates/sles-10-i586/rpm/i586/krb5-1.4.3-19.43.2.i586.rpm</smtlocation> </package> <package name="krb5-apps-servers" arch="i586" epoch="" release="19.43.2" version="1.4.3"> <origlocation>https://nu.novell.com/repo/$RCE/SLES10-SP2-Updates/sles-10-i586/rpm/i586/krb5-apps-servers-1.4.3-19.43.2.i586.rpm</origlocation>

101 SLES 12 SP4

<smtlocation>http://kompost.suse.cz/repo/$RCE/SLES10-SP2-Updates/sles-10-i586/rpm/i586/krb5-apps-servers-1.4.3-19.43.2.i586.rpm</smtlocation> </package> ... </packages> <references> <reference id="535943" href="https://bugzilla.suse.com/show_bug.cgi?id=535943" title="bug number 535943" type="bugzilla"/> <reference id="CVE-2009-4212" href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4212" title="CVE-2009-4212" type="cve"/> </references> <title>Security update for Kerberos 5</title></patch>

GET /products

Returns list of all products known to SMT.RNC:

start element products { element product { attribute id {xsd:integer}, # SMT ID of the product attribute name {xsd:string}, # Unix name of the product attribute version {xsd:string}, # version string attribute rel {xsd:string}, # release string attribute arch {xsd:string}, # target machine architecture string attribute uiname {xsd:string} # name of the product to be # displayed to users }*}

Example:

<products> <product name="SUSE_SLED" arch="x86_64" id="1824" rel="" uiname="SUSE Linux Enterprise Desktop 11 SP1" version="11.1"/> <product name="SUSE_SLES" arch="i686" id="1825" rel="" uiname="SUSE Linux Enterprise Server 11 SP1" version="11.1"/> <product name="sle-hae" arch="i686" id="1880" rel="" uiname="SUSE Linux Enterprise High Availability Extension 11 SP1" version="11.1"/> <product name="SUSE-Linux-Enterprise-Thin-Client" arch="" id="940" rel="SP1" uiname="SUSE Linux Enterprise 10 Thin Client SP1" version="10"/> ...</products>

GET /product/<productid>

Returns information about the specified product. The productid can be obtained fromdata returned by the /products call.

102 SLES 12 SP4

RNC:

start = element product { attribute id {xsd:integer}, # SMT ID of the product attribute name {xsd:string}, # Unix name of the product attribute version {xsd:string}, # version string attribute rel {xsd:string}, # release string attribute arch {xsd:string}, # target machine architecture string attribute uiname {xsd:string} # name of the product to be displayed # to users}

Example:

<product name="SUSE_SLED" arch="x86_64" id="1824" rel="" uiname="SUSE Linux Enterprise Server 11 SP1" version="11.1"/>

GET /product/<productid>/repos

Returns the list of all software repositories for the specified product. The productidcan be obtained from the data returned by the /products call.RNC:See the /repos call.Example:

<repos> <repo name="SLED11-SP1-Updates" id="143" mirrored="" target="sle-11-x86_64"/> <repo name="SLE11-SP1-Debuginfo-Pool" id="400" mirrored="" target="sle-11-x86_64"/> <repo name="SLED11-Extras" id="417" mirrored="" target="sle-11-x86_64"/> <repo name="SLED11-SP1-Pool" id="215" mirrored="" target="sle-11-x86_64"/> <repo name="nVidia-Driver-SLE11-SP1" id="469" mirrored="" target=""/> <repo name="ATI-Driver-SLE11-SP1" id="411" mirrored="" target=""/> <repo name="SLE11-SP1-Debuginfo-Updates" id="6" mirrored="" target="sle-11-x86_64"/></repos>

103 SLES 12 SP4

B Documentation Updates

This chapter lists content changes for this document.

This manual was updated on the following dates:

Section B.1, “October 2018 (Documentation Maintenance Update for SUSE Linux Enterprise Server

12 SP3)”

Section B.2, “September 2017 (Initial Release of SUSE Linux Enterprise Server 12 SP3)”

Section B.3, “April 2017 (Documentation Maintenance Update for SUSE Linux Enterprise Server 12

SP2)”

Section B.4, “November 2016 (Initial Release of SUSE Linux Enterprise Server 12 SP2)”

Section B.5, “March 2016 (Documentation Maintenance Update for SUSE Linux Enterprise Server 12

SP1)”

Section B.6, “December 2015 (Initial Release of SUSE Linux Enterprise Server 12 SP1)”

B.1 October 2018 (Documentation MaintenanceUpdate for SUSE Linux Enterprise Server 12 SP3)

Bugfixes

Corrected the path to the testing environment in Section 3.5, “Using the Test Environment”

(https://bugzilla.suse.com/show_bug.cgi?id=1108068 ).

Corrected the path to the registration server in Section 8.3, “Configuring Clients with

the clientSetup4SMT.sh Script in SLE 11 and 12” (https://bugzilla.suse.com/show_bug.c-

gi?id=1107314 ).

Corrected the path to smt.crt in Section 8.3, “Configuring Clients with the

clientSetup4SMT.sh Script in SLE 11 and 12” (https://bugzilla.suse.com/show_bug.c-

gi?id=1107305 ).

In Section 3.2, “Managing Software Repositories with SMT Command Line Tools”,corrected the command for setting up custom repositories (https://bugzil-

la.suse.com/show_bug.cgi?id=1094404 ).

104

October 2018 (Documentation Maintenance Update for SUSE Linux Enterprise Server 12

SP3) SLES 12 SP4

https://bugzilla.suse.com/show_bug.cgi?id=1108068







In Section 9.2, “Disconnected SMT Servers”, updated some steps in the proce-dure Internal SMT Server Configuration for the Disconnected Setup (https://bugzil-


The /connect/ path is not required when connecting to an SMT server. For details,see Chapter 8, Configuring Clients to Use SMT.

B.2 September 2017 (Initial Release of SUSE LinuxEnterprise Server 12 SP3)

General

Numerous small fixes and additions to the documentation, based on technical feed-back.

Removed all references to the faillog package, which is no longer shipped (https://

bugzilla.suse.com/show_bug.cgi?id=710788 ).

B.3 April 2017 (Documentation Maintenance Updatefor SUSE Linux Enterprise Server 12 SP2)

Bugfixes

smt.crt is generated by systemctl restart smt.service in Section 7.3, “Server

Certificates” (https://bugzilla.suse.com/show_bug.cgi?id=1084715 ).

Specified how to enable the installer self-update repository (https://bugzil-


105 September 2017 (Initial Release of SUSE Linux Enterprise Server 12 SP3) SLES 12 SP4








B.4 November 2016 (Initial Release of SUSE LinuxEnterprise Server 12 SP2)

General

The e-mail address for documentation feedback has changed to doc-

[email protected] .

The documentation for Docker Open Source Engine has been enhanced and renamedto Docker Guide.

General Updates to this Guide

Added a new chapter Chapter 9, Advanced Topics with sections Section 9.1, “Backup of

the SMT Server” and Section 9.2, “Disconnected SMT Servers”.

Updated options for some commands.

About This Guide

Replaced the introductory text with a more descriptive one, plus added a schema.

Chapter 1, SMT Installation

Added Section 1.2.1, “Upgrade from SMT 12 SP1”.

Chapter 3, Mirroring Repositories on the SMT Server

Added Section 3.7, “Repository Preloading”.

Added schema in Section 3.6, “Testing and Filtering Update Repositories with Staging”.

Chapter 4, Managing Repositories with YaST SMT Server Management

Added Section 4.4, “Jobs and Client Status Monitoring” enhancing Section 4.4.1, “Checking

the Client Status with YaST”.

Updated repository list filtering in Section 4.2.1, “Filtering Repositories” (Fate #319777).

106 November 2016 (Initial Release of SUSE Linux Enterprise Server 12 SP2) SLES 12 SP4

Chapter 5, Managing Client Machines with SMT

Added Section 5.5, “Compliance Monitoring”.

Chapter 7, SMT Tools and Configuration Files

Added a tip on SUSE Manager's subscription matching feature in Section 7.1.2.8, “smt-

scc-sync” (Fate #320646).

Bugfixes

Added Section 9.1, “Backup of the SMT Server” (https://bugzilla.suse.com/show_bug.c-

gi?id=954874 ).

It is important to add the DNS entry when setting the Server Alternative Name valuein a server certificate in Step 7 (https://bugzilla.suse.com/show_bug.cgi?id=908189 ).

Added a recommendation to check if clientSetup4SMT.sh is up to date afterOS migration in Section 8.3, “Configuring Clients with the clientSetup4SMT.sh Script in

SLE 11 and 12” and Book “Deployment Guide”, Chapter 19 “Upgrading SUSE Linux Enter-

prise”, Section 19.3.8 “Adjust Your SMT Client Setup” (https://bugzilla.suse.com/show_bug.c-

gi?id=944342 ).

Stressed the need for one-by-one extension installation in Section 8.3, “Con-

figuring Clients with the clientSetup4SMT.sh Script in SLE 11 and 12” (https://bugzil-


B.5 March 2016 (Documentation MaintenanceUpdate for SUSE Linux Enterprise Server 12 SP1)


Fixed typos: my.conf.rpmnew to my.cnf.rpmnew and my.conf to my.cnf (https://bugzil-


107

March 2016 (Documentation Maintenance Update for SUSE Linux Enterprise Server 12

SP1) SLES 12 SP4










B.6 December 2015 (Initial Release of SUSE LinuxEnterprise Server 12 SP1)

General

SMT Guide is now part of the documentation for SUSE Linux Enterprise Server.

Add-ons provided by SUSE have been renamed as modules and extensions. The man-uals have been updated to reflect this change.

Numerous small fixes and additions to the documentation, based on technical feed-back.

The registration service has been changed from Novell Customer Center to SUSECustomer Center.

In YaST, you will now reach Network Settings via the System group. Network Devicesis gone (https://bugzilla.suse.com/show_bug.cgi?id=867809 ).


Rewrote and simplified the whole installation procedure as SMT is now part of SUSELinux Enterprise Server.

Updated Section 1.2, “Upgrading from Previous Versions of SMT” to describe ways to up-grade to version 12 SP1, including migration to SUSE Customer Center.

Chapter 3, Mirroring Repositories on the SMT Server

Updated suseRegister to SUSEConnect and introduced new namespace option in Sec-

tion 3.5, “Using the Test Environment” and Section 3.6, “Testing and Filtering Update Reposi-

tories with Staging”.

Removed SUSE Linux Enterprise Server 9 references and informed about droppedsupport.

108 December 2015 (Initial Release of SUSE Linux Enterprise Server 12 SP1) SLES 12 SP4


Chapter 7, SMT Tools and Configuration Files

Added jobStatusIsSuccess , mirror_preunlock_hook , and mirror_postun-

lock_hook options in Section 7.2.1, “/etc/smt.conf”.

Removed the redundant smt-scc-sync command description from Section 7.1.2, “/

usr/sbin/smt Commands”.

Removed SUSE Linux Enterprise Server 9 references and xed command names anda log le name.

Chapter 8, Configuring Clients to Use SMT

Updated the way the client accepts untrusted certificate from SMT in the introductionto Chapter 8, Configuring Clients to Use SMT.

Added Section 8.8, “Online Migration of SUSE Linux Enterprise Clients”.

Added SUSE Linux Enterprise 12 support to Section 8.3, “Configuring Clients with the

clientSetup4SMT.sh Script in SLE 11 and 12”.

Added Section 8.2.2, “Configuring SUSE Linux Enterprise 12 Clients”.

Added Section 8.6, “Registering SLE12 Clients against SMT Test Environment”.

Bugfixes

Rephrased the paragraph and updated contact e-mails in Tip: Merging Multiple Organi-

zation Site Credentials (https://bugzilla.suse.com/show_bug.cgi?id=866936 ).

109 December 2015 (Initial Release of SUSE Linux Enterprise Server 12 SP1) SLES 12 SP4


subscription management tool for sles 12 sp4 - suse linux ... · 4 managing repositories with yast...

Documents