Applies to SUSE Linux Enterprise Server 12 SP5

8 SMT Tools and Configuration Files #

Revision History: SUSE Linux Enterprise Server 文档

This chapter describes the most important scripts, configuration files and certificates shipped with SMT.

8.1 Important Scripts and Tools #

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

8.1.1 SMT JobQueue #

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

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

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

Note: Overriding the Automatic Creation of Patch Status Jobs

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

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

Note: Job Time Lag Limitation

The client normally processes one job at a time, reports back the result, and then asks for the next job. If you create a persistent job with a time offset of only a few seconds, it is repeated forever and blocks other jobs. Therefore, adding jobs with a time offset shorter than one minute is not supported.

8.1.2 /usr/sbin/smt Commands #

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

The following sub-commands are available:

smt-client
smt-delete-registration
smt-job
smt-list-products
smt-list-registrations
smt-mirror
smt-scc-sync
smt-register
smt-report
smt-repos
smt-setup-custom-repos
smt-staging
smt-support
smt-sync

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

Note: Conflicting Commands

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

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

8.1.2.1 smt-client #

The smt-client command shows information about registered clients. The information includes 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 file to write the log messages 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 packagemanager, security, recommended or optional.

8.1.2.2 smt-delete-registration #

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

--guid or -g with the parameter ID: Deletes the machine with the guid ID from the system. You can use this option multiple times.
--debug or -d: Enables debugging mode.

8.1.2.3 smt-job #

The smt-job script manages jobs for individual SMT clients. You can use 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 a number 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.
--guid or -g with the parameter ID: Specifies the client's guid. This parameter can be used multiple times to create a job for more 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 deleting a job, as the same job for multiple clients has the same job ID.
--deleteall or -Aid: Omit either the client's GUID or the job ID in the delete operation. The missing parameter matches 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 enabled by default: patchstatus, softwarepush and update.
--description DESCRIPTION: Specifies a job description.
--parentID: Specifies the job ID of the parent job. Use it to define a dependency. A job is not processed 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 persistent jobs are processed again and again. Use --timelag to define the time that elapses until the next run.
--finished: Search option for finished jobs.
--targetedtime: Specifies the earliest execution time of a job. The job does not run exactly at that time, but a few minutes or hours after. The reason is that the client polls in a fixed interval for jobs.
--expirestime: Defines the time after which the job is no longer executed.
--timelagtime: 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).

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

8.1.2.4 smt-list-products #

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

--used or -u: Shows only used products.
--catstat or -c: Shows whether all repositories needed for a product are locally mirrored.

8.1.2.5 smt-list-registrations #

The smt-list-registrations script lists all registrations. There are two options available for this 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.

8.1.2.6 smt-mirror #

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

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

--clean or -c: Removes all files no longer mentioned in the metadata from the mirror. No mirroring occurs before cleanup.
--debug or -d: Enables the debugging mode.
--deepverify: Turns on verifying of all package checksums.
--hardlink SIZE: Searches for duplicate files with a size greater than the size specified in kilobytes. Creates hard links for them.
--directory PATH: Defines the directory to work on. When using this option, the default value configured in the smt.conf configuration file is ignored.
--dbreplfile FILE: Defines a path to the *.xml file to use as database replacement. You can create this file with the smt-scc command.
--logfile or -L with the parameter FILE: Specifies the path to a log file.

8.1.2.7 smt-sync #

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

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

8.1.2.8 smt-scc-sync #

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

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 SUSE Customer Center.
--todir DIRECTORY: Writes SUSE Customer Center data to the specified directory without updating the SMT database.
Tip: SUSE Manager's Subscription Matching Feature
This data can be used by the subscription matching feature of SUSE Manager, which gives you a detailed overview of your subscription usage. For more information on the subscription matching feature, see https://documentation.suse.com/external-tree/en-us/suma/3.2/susemanager-reference/html/book.suma.reference.manual/ref.webui.audit.html#ref.webui.audit.subscription.
--createdbreplacementfile: Creates a database replacement file for using smt-mirror without database.
--logfile or -L LOGFILE: Specifies the path to a log file.
--debug or -d: Enables debugging mode.
--verboselevel or -v BITMASK: Specifies the verbosity level of log messages. Accepts a decimal number that represents a binary bitmask of one of seven verbosity levels. For example, the --debug option described above corresponds to the bitmask of 00111111, which is 63 in decimal. To achieve even more verbosity, use 127, which relates to the bitmask of 01111111.
Important
The --debug and --mail options are mutually exclusive with the --verboselevel option.

8.1.2.9 smt-register #

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

The following options are available:

--logfile or -L with the parameter LOGFILE: Specifies the path to a log file.
--debug: Enables debugging mode.

8.1.2.10 smt-report #

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

The following options are available:

--mail or -m

Activates mailing the report to the addresses configured with the SMT Server and written in /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 combination 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 files in the CSV format. The first line of each *.csv file consists of the column names. The --csv parameter should only be used in combination with the --file parameter. If the specified file name has the .csv extension, the report is 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-report command.

--file or -F

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

In the CSV mode the report is written to multiple files, therefore the specified file name expands to [PATH/]FILENAME-reportname.extension for every report.

--logfile or -L with the parameter LOGFILE

Specifies path to a log file.

--debug

Enables debugging mode.

8.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: Product[,Version[,Architecture[,Release]]].
--disable-by-prod or -P: Disables repository mirroring by giving product data in the following format: Product[,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.

8.1.2.12 smt-setup-custom-repos #

The smt-setup-custom-repos and smt setup-custom-repos script are designed for setting up custom repositories (repositories not present in the download server) for use with SMT. You can use this script to add a new repository to the SMT database or to delete a repository from the database. The script 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 are supported.
--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

8.1.2.13 smt-staging #

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

The first argument of smt-staging is always the command. It must be followed by a repository. The repository can be specified by Name and Target from the table scheme returned by the smt-repos command. Alternatively, it can be specified by its Repository ID which can be obtained by running the command smt-repos -v. The smt-staging script supports the 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 the path repo/full, repo/testing and repo. New paths can be specified when creating a 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 -Lfile path: Writes log information to the specified file. 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 listupates command. This option can be used multiple times. Use it with the allow, forbid, and listupdates commands. When used with listupdates, the command prints detailed information about the specified patches.
--category CATEGORY: Specifies the patch category. The following categories are available: security, recommended and optional. Use it in combination with the allow, forbid, and listupdates 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 command. The repository is generated from the full unfiltered local mirror of the remote repository. It is written into the <MirrorTo>/repo/testing directory, where MirrorTo is the value obtained from smt.conf.
--production: Generates a repository for production when used in combination with the createrepo command. 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. If the testing repository does not exist, the production repository is generated from the full unfiltered local mirror of the remote repository.
--group GROUP: Specifies on which group the command should work. The default for --group is the name default.
--nohardlink: Prevents creating hard links instead of copying files when creating a repository with the createrepo command. If not specified, hard links are created instead.
--nodesc: Skips patch descriptions and summaries—to save certain screen space and make the output more readable.
--sort-by-version: Sorts the listupdates table by patch version. The higher the version, the newer the patch should be.
--sort-by-category: Sorts the listupdates table by patch category.

8.1.2.14 smt-support #

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

--incoming or -i with the parameter DIRECTORY: Specifies the directory where the supportconfig archives are uploaded. You can also set this option with the SMT_INCOMING environment variable. The default SMT_INCOMING directory is /var/spool/smt-support.
--list or -l: 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 first 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.

8.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, MariaDB, and cron are running.
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.

8.2 SMT Configuration Files #

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

8.2.1 /etc/smt.conf #

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

Warning: Passwords in Clear Text

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

8.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.
NURegUrl: URL of the update registration service. It is used by smt-sync. If this option is missing, the URL from /etc/SUSEConnect is used as a fallback.
NUUser: NUUser should contain the user name for update service. For information about getting organization credentials, see Section 4.1, “Mirroring Credentials”. You can set this value with the SMT Server.
NUPass: NUPass is the password for the user defined in NUUser. For information about getting organization credentials, see Section 4.1, “Mirroring Credentials”. You can set this value with the SMT Server.
ApiType: ApiType is the type of service SMT uses; it can be either NCC for Novell Customer Center or SCC for SUSE Customer Center. The only supported value for SMT 12 is SCC.

8.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 MariaDB is supported by SMT.

config

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

dbi:mysql:database=SMT;host=LOCALHOST

where SMT is the name of the database and LOCALHOST is the host name of the database server.

user

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

pass

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

8.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 available on the server. This value should be set by YaST automatically during installation. The format of this option should be: https://server.domain.tld/.

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

nccEmail

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

MirrorTo

Determines the path to mirror to.

MirrorAll

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

MirrorSRC

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

Note: Default Value Changed with SMT 11 SP2

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

Upgraded systems are not affected.

forwardRegistration

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

rndRegister

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

mirror_preunlock_hook

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

mirror_postunlock_hook

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

HTTPProxy

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

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

HTTPSProxy

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

ProxyUser

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

Tip: Global User Authentication Setting

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

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

requiredAuthType

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

none - no authentication is required. This is the default value.
lazy - only user name and password are checked. A valid user can access all repositories.
strict - checks also if the user has access to the repository.

smtUser

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

signingKeyID

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

8.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 empty password is invalid.

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

8.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 this list with the YaST SMT Server module.
reportEmailFrom: From field of report e-mails. If not set, the default root@HOSTNAME.DOMAINNAME will be used.
mailServer: Relay mail server. If empty, e-mails are sent directly.
mailServerPort: Port of the relay mail server set in mailServer.
mailServerUser: User name for authentication to the mail server set in mailServer.
mailServerPassword: Password for authentication to the mail server set in mailServer.

8.2.1.7 Example /etc/smt.conf #

Example 8.1: smt.conf #

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

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

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

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

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

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

8.2.2 /etc/smt.d/smt-cron.conf #

The /etc/smt.d/smt-cron.conf configuration file contains options of the SMT commands launched as SMT scheduled jobs set with YaST (see Section 3.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 file.

SCC_SYNC_PARAMS: Contains parameters of the smt scc-sync command, if called as part of an SMT scheduled job 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 scheduled job 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 scheduled job 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 scheduled job via cron. The default value is "--mail --attach -L /var/log/smt/smt-report.log".
JOBQUEUECLEANUP_PARAMS: Contains parameters for smt jobqueue cleanup, if called as a part of an SMT scheduled job via cron. The default value is "--mail -L /var/log/smt/smt-jobqueuecleanup.log".

8.3 Server Certificates #

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

Every client must be able to verify the server certificate by trusting the CA (certificate authority) certificate that signed the server certificate. Therefore, the SMT server provides a copy of the CA at /srv/www/htdocs/smt.crt. This CA can be downloaded from every client via the URL http://FQDN/smt.crt. The copy is created by the /usr/lib/SMT/bin/smt-maintenance script. Whenever SMT is started with systemctl start smt.target, it checks the certificate. If a new CA certificate exists, it is copied again. Therefore, whenever the CA certificate is 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 the common server certificate. If the certificate does not exist, YaST asks whether the certificate should be created. If the user confirms, the YaST CA Management module is started.

8.3.1 Certificate Expiration #

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

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

8.3.2 Creating a New Common Server Certificate #

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

Start YaST and select Security and Users › CA Management. Alternatively, start the YaST CA Management module from a command line by entering yast2 ca_mgm as root.
Select the required CA and click Enter CA.
Enter the password if entering a CA for the first time. YaST displays the CA key information in the Description tab.
Click the Certificates tab (see Figure 8.1, “Certificates of a CA”) and select Add › Add Server Certificate.
Figure 8.1: Certificates of a CA #
Enter the fully qualified domain name of the server as Common Name. Add a valid e-mail address of the server administrator. Other fields, such as Organization, Organizational Unit, Locality, and State are optional. Click Next to proceed.
Important: Host Name in Server Certificate
The server certificate must contain the correct host name. If the client requests server https://some.hostname/, then some.hostname must be part of the certificate. The host name must either be used as the Common Name, see Step 5, or as the Subject Alternative Name, see Step 7: DNS:some.hostname and IP:<ipaddress>.
Enter a Password for the private key of the certificate and re-enter it in the next field to verify it.
If you want to define a Subject Alternative Name, click Advanced Options, select Subject Alternative Name from the list and click Add.
Important: Subject Alternative Name
If Subject Alternative Name is in the server certificate, then it needs to contain the DNS entry. If Subject Alternative Name is present, the Common Name (CN) is not checked anymore.
If you want to keep the default values for the other options, like Key Length and Valid Period, click Next. An overview of the certificate to be created is shown.
Click Create to generate the certificate.
To export the new certificate as the common server certificate, select it in the Certificates tab and select Export › Export as Common Server Certificate.
After having created a new certificate, restart SMT using the systemctl restart smt.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 Management module and the Common Server Certificate module, refer to the Security and Hardening Guide. It is available from https://documentation.suse.com/sles/.

8.3.3 Importing a Common Server Certificate #

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

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

Start YaST and select Security and Users › Common Server Certificate. Alternatively, start the YaST Common Server Certificate module from the command line by entering yast2 common_cert as root.
The description of the currently used common server certificate is shown in the dialog that opens.
Click Import and select the file containing the certificate to be imported. Specify the certificate password in the Password field.
Click Next. If the certificate is successfully imported, close YaST with Finish.
After having created a new certificate, restart SMT using the systemctl restart smt.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.

8.3.4 Synchronizing Time between SMT Server and Clients #

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

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