Dokumentace systému SUSE Linux Enterprise Desktop › SMT Guide › SMT Tools and Configuration Files

Subscription Management Tool for SLES 12 SP2

Navigation←→

Applies to SUSE Linux Enterprise Desktop 12 SP2

7 SMT Tools and Configuration Files

7.1 Important Scripts and Tools
7.2 SMT Configuration Files
7.3 Server Certificates

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

7.1 Important Scripts and Tools #

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

7.1.1 SMT JobQueue #

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

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

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

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

Note: Overriding the Automatic Creation of Patch Status Jobs

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

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

Note: Job Time Lag Limitation

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

7.1.2 /usr/sbin/smt Commands #

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

The following sub-commands are available:

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

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

Note: Conflicting Commands

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

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

7.1.2.1 smt-client #

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

guid
host name
patch status
time stamps of the patch status
last contact with the SMT server

The smt-client understands the following options:

--verbose or -v: Show detailed information about the client. The last contact date is shown as well.
--debug or -d: Enable debugging mode.
--logfile or -Lfile: Specify the file the log will be written to.
--hostname or -hname: Only the entries whose host name begins with name will be listed.
--guid or -gguid: Only the entries whose GUID is guid will be listed.
--severity or -slevel: Filter the result by the patch status information. The value level can be one of 'packagemanager', 'security', 'recommended' or 'optional'. Only those entries are listed which have patches of the respective level.

7.1.2.2 smt-delete-registration #

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

--guid ID or -gID: Delete the machine with the guid ID from the system. You can use this option multiple times.
--debug or -d: Enable debugging mode.

7.1.2.3 smt-job #

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

--list or -l: List all client jobs. This is the default if the operation mode switch is omitted.
--verbose or -vlevel: Show detailed information about a job or jobs in a list mode. The level value can be a number from 0 to 3. The bigger the value, the more verbose the command is.
--create or -c: Create a new job.
--edit or -e: Edit an existing job.
--delete or -d: Delete an existing job.
--guid or -gguid: Specify the client's guid. This parameter can be used multiple times to create a job for more than one client.
--jobid or -jid: Specify the job ID. You need to specify job ID and client's guid when editing or deleting a job, because the same job for multiple clients has the same job ID.
--deleteall or -Aid: Omit either the client's guid or the job ID in this delete operation. The missing parameter will match all respective jobs.
--type or -ttype: Specify the job type. The type can be one of 'patchstatus', 'softwarepush', 'update', 'execute', 'reboot', 'wait', 'eject'. On the client, only 'patchstatus', 'softwarepush' and 'update' are enabled by default.
--description description: Specify a job description.
--parentid: Specify the job ID of the parent job. Use it to describe a dependency. A job will not be processed until its parent has successfully finished.
--name or -n name: Specify a job name.
--persistent: Specify if a job is persistent. Non-persistent jobs are processed only once, while persistent jobs are processed again and again. Use --timelag to define the time that elapses until the next run.
--finished: Search option for finished jobs.
--targetedtime: Specify the earliest execution time of a job. Note that the job most likely will not run exactly at that point in time, but probably some minutes or hours after. The reason is that the client polls in a fixed interval for jobs.
--expirestime: Define when the job will no longer be executed anymore.
--timelagtime: Define the time interval for persistent jobs.

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

7.1.2.3.1 Examples #

To list all finished jobs, enter the following:

smt-job --list --finished

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

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

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

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

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

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

7.1.2.4 smt-list-products #

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

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

7.1.2.5 smt-list-registrations #

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

--verbose or -v: Show detailed information about the registered devices.
--format or -fformat: Format the output. Possible types of formats are asciitable and csv.

7.1.2.6 smt-mirror #

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

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

--clean or -c: Remove all files no longer mentioned in the metadata from the mirror. No mirroring occurs before cleanup.
--debug or -d: Enable the debugging mode.
--deepverify: Turn on verifying of all package checksums.
--hardlink size: Search for duplicate files with a size greater than the size specified in kilobytes. Creates hard links for them.
--directory path: Define the directory to work on. If you use this option, the default value configured in the smt.conf configuration file is ignored.
--dbreplfile file: Define the path to the *.xml file to use as database replacement. You can create such a file with the smt-scc command.
--logfile file or -L file: Specify the path to a log file.

7.1.2.7 smt-sync #

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

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

7.1.2.8 smt-scc-sync #

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

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

--fromdir directory: Read SUSE Customer Center data from a directory instead of downloading it from SUSE Customer Center.
--todir directory: Write SUSE Customer Center data to the specified directory without updating the SMT database.
Tip: SUSE Manager's Subscription Matching Feature
This data can be consumed by the subscription matching feature of SUSE Manager, which gives you a detailed overview of your subscription usage. For more information on the subscription matching feature, see https://www.suse.com/documentation/suse-manager-3/book_suma_reference_manual/data/ref_webui_audit_subscription.html
--createdbreplacementfile: Create a database replacement file for using smt-mirror without database.
--logfile file or -L file: Specify the path to a log file.
--debug: Enable debugging mode.

7.1.2.9 smt-register #

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

The following options are available:

--logfile file or -L file: Specify the path to a log file.
--debug: Enable debugging mode.

7.1.2.10 smt-report #

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

The following options are available:

--mail or -m

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

--attach or -a

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

--quiet or -q

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

--csv or -c

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

--pdf or -p

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

--xml

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

--file or -F

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

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

--logfile filename or -L filename

Specify path to a log file.

--debug

Enable debugging mode.

7.1.2.11 smt-repos #

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

--enable-mirror or -e: Enable repository mirroring.
--disable-mirror or -d: Disable repository mirroring.
--enable-by-prod or -p: Enable repository mirroring by giving product data in the following format: Product[,Version[,Architecture[,Release]]].
--disable-by-prod or -P: Disable repository mirroring by giving product data in the following format: Product[,Version[,Architecture[,Release]]].
--enable-staging or -s: Enable repository staging.
--disable-staging or -S: Disable repository staging.
--only-mirrorable or -m: List only repositories that can be mirrored.
--only-enabled or -o: List only enabled repositories.
--delete: List repositories and delete them from disk.
--namespace dirname: Delete the repository in the specified name space.
--verbose or -v: Show detailed repository information.

7.1.2.12 smt-setup-custom-repos #

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

--productid: ID of a product the repository belongs to. If a repository should belong to multiple products, use this option multiple times to assign the repository to all relevant products.
--name: The name of the custom repository.
--description: The description of the custom repository.
--exturl: The URL where this repository can be mirrored from. Only HTTP and HTTPS protocols are supported (no directory, file, or FTP).
--delete: Remove a custom repository with a given ID from the SMT database.

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

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

For example:

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

To remove a configured repository, use the following command:

smt-setup-custom-repos --delete Catalog_ID

For example:

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

7.1.2.13 smt-staging #

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

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

listupdates

List available patches and their allowed/forbidden status.

allow/forbid

Allow or forbid specified patches.

createrepo

Generate both testing and production repository with allowed patches.

status

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

listgroups

List staging groups.

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

creategroup

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

removegroup

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

The following options apply to any smt-staging command:

--logfile or -Lfile path: Write log information to the specified file. If it does not exist, it is created.
--debug or -d: Turn on the debugging output and log.
--verbose or -v: Turn more detailed output on.

The following options apply to specific smt-staging commands:

--patch: Specify a patch by its ID. You can get a list of available patches with the listupates command. This option can be used multiple times. Use it with the allow, forbid, and listupdates commands. If used with listupdates, the command will print detailed information about the specified patches.
--category: Specify the patch category. The following categories are available: 'security', 'recommended' and 'optional'. Use it with the allow, forbid, and listupdates commands.
--all: Allow or forbid all patches in the allow or forbid commands.
--individually: Allow or forbid multiple patches (for example by category) one by one, that is, as if the --patch option had been used on each of the patches.
--testing: Use with the createrepo command to generate a repository for testing. The repository will be generated from the full unfiltered local mirror of the remote repository. It will be written into the <MirrorTo>/repo/testing directory, where MirrorTo is the value taken from smt.conf.
--production: Use with the createrepo command to generate a repository for production use. The repository will be generated from the testing repository. It will be written into the <MirrorTo>/repo directory, where MirrorTo is the value taken from smt.conf. If the testing repository does not exist, the production repository will be generated from the full unfiltered local mirror of the remote repository.
--group: Specify on which group the command should work. The default for --group is the name default.
--nohardlink: During the repository creation with the createrepo command, avoid creating hard links instead of copying files. If not specified, hard links are created instead.
--nodesc: Do not print patch descriptions and summaries—to save some screen space and make the output more readable.
--sort-by-version: Sort the listupdates table by patch version. The higher the version, the newer the patch should be.
--sort-by-category: Sort the listupdates table by patch category.

7.1.2.14 smt-support #

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

--incoming or -idirectory: Specify the directory where the supportconfig archives are uploaded. You can also set this option with the SMT_INCOMING environment variable. The default SMT_INCOMING directory is /var/spool/smt-support.
--list or -l: List the uploaded supportconfig archives in the incoming directory.
--remove or -rarchive: Delete the specified archive.
--empty or -R: Delete all archives in the incoming directory.
--upload or -uarchive: Upload the specified archive to SUSE. If you specify -s, -n, -c, -p, and -e options, the archive is repackaged with contact information.
--uploadall or -U: Upload all archives in the incoming directory to SUSE.
--srnum or -sSR number: Accept the Novell Service Request 11-digit number.
--name or -nname: Enter the first and last name of the contact, in quotes.
--company or -ccompany: Enter the company name.
--storeid or -did: Enter the store ID, if applicable.
--terminalid or -tid: Enter the terminal ID, if applicable.
--phone or -pphone: Enter the phone number of the contact person.
--email or -eemail: Enter the e-mail address of the contact.

7.1.3 SMT `systemd` Commands #

You can operate SMT related services with the standard systemd commands:

systemctl start smt.target: Start the SMT services.
systemctl stop smt.target: Stop the SMT services.
systemctl status smt.target: Check the status of the SMT services. Checks whether httpd, Maria DB, and cron are running.
systemctl restart smt.target: Restart the SMT services.
systemctl try-restart smt.target: Check whether the SMT services are enabled and if so, restart them.

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

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

7.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 Maria DB database for SMT. The [LOCAL] section includes other configuration data. The [REPORT] section contains the configuration of SMT reports.

Warning: Passwords in Clear Text

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

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

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

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

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

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

config

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

dbi:mysql:database=smt;host=localhost

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

user

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

pass

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

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

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 and adjust the permissions with the following commands as root:

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

requiredAuthType

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

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

smtUser

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

signingKeyID

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

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

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

enableRESTAdminAccess: If set to 1, turns administrative access to the SMT RESTService on. Default value is 0.
RESTAdminUser: Specify the user name that the REST-Admin uses to log in. Default value is RESTroot.
RESTAdminPassword: Specify the password for the REST-Admin user. The option has no default value. An empty password is invalid.

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

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

maxFinishedJobAge: Specify the maximum age of finished non-persistent jobs in days. Default value is 8.
jobStatusIsSuccess: Specify a comma separated list of JobQueue status IDs that should be interpreted as successful. For more information about possible status IDs, see smt-job --help. Leaving this option empty is interpreted as default (1,4).

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

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

reportEmail: A comma separated list of e-mail addresses to send SMT status reports to. You can set this list with the YaST SMT Server module.
reportEmailFrom: From field of report e-mails. If not set, the default root@hostname.domainname will be used.
mailServer: Relay mail server. If empty, e-mails are sent directly.
mailServerPort: Port of the relay mail server set in mailServer.
mailServerUser: User name for authentication to the mail server set in mailServer.
mailServerPassword: Password for authentication to the mail server set in mailServer.

7.2.1.7 Example /etc/smt.conf #

Example 7.1: smt.conf #

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

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

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

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

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

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

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

7.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 when YaST writes the SMT configuration. Whenever SMT is started with systemctl start smt.target, it checks the certificate. If a new CA certificate exists, it is copied again. Therefore, whenever the CA certificate is changed, restart SMT using the systemctl restart smt.target command.

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

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

7.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 7.1, “Certificates of a CA”) and select Add › Add Server Certificate.
Figure 7.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 present 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 Guide coming with the base system.

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

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

Print this page