Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to Subscription Management Tool 11.3

7 SMT Tools and Configuration Files

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 rcsmt script is used for starting, stopping, restarting SMT services, 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 the already registered clients, you can add the 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
Note: Overriding the Automatic Creation of Patch Status Job

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 rather a longtime maintenance and monitoring system than a live interaction tool.

Note
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 out 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-ncc-sync

  • smt-register

  • smt-report

  • smt-repos

  • smt-scc-sync

  • smt-setup-custom-repos

  • smt-staging

  • smt-support

  • smt-sync

  • smt-mirror-sle9

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 choice). For example, it is possible to use either smt mirror or smt-mirror, as both have the same meaning.

Note
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

  • hostname

  • patch status

  • timestamps 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 -L file

Specify the file the log will be written to.

--hostname or -h name

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

--guid or -g guid

Only the entries whose GUID is guid will be listed.

--severity or -s level

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 Novell Customer Center. It will deregister machines from the system. The following options are available:

--guid ID or -g ID

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 -v level

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 -g guid

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

--jobid or -j id

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 -A id

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

--type or -t type

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.

--parent id

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.

--targeted time

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.

--expires time

Define when the job will no longer be executed anymore.

--timelag time

Define the time interval for persistent jobs.

For a complete list of possible options and their explanation, see the manual page of 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 -f format

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 sync-ncc command.

--logfile file or -L file

Specify the path to a logfile.

7.1.2.7 smt-sync

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

When using this command, it is automatically decided whether Novell Customer Center or SUSE Customer Center should be used. Then smt-ncc-sync or smt-scc-sync is called as appropriate.

7.1.2.8 smt-ncc-sync

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

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

--fromdir directory

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

--todir directory

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

--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-scc-sync

The smt-ccc-sync or 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 such 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.

--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.10 smt-register

The smt-register or smt-register command registers all currently unregistered clients at the Novell 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.11 smt-report

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

The following options are available:

--local

Force the creation of a report based on a local calculation without accessing Novell Customer Center data.

--ncc

Force the creation of a report based on Novell Customer Center data.

--nonccsync

Disable synchronizing with Novell Customer Center before creating the report.

--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, the data starts on line two. The --csv parameter should only be used together with the --file parameter. If the specified filename 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 filename or whole path may be specified after the parameter: --file filename. If no filename is specified, a default filename containing a timestamp 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 filename will expand to [path/]filename-reportname.extension for every report.

--logfile filename or -L filename

Specify path to a logfile.

--debug

Enable debugging mode.

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

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

--disable-mirror or -d

Disable repository mirroring.

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

--verbose or -v

Show detailed repository information.

7.1.2.13 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 NU) 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.14 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, or 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 forbids 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 -L file 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 (e.g. 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 <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 <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 on. 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.15 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 -i directory

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 -r archive

Delete the specified archive.

--empty or -R

Delete all archives in the incoming directory.

--upload or -u archive

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 -s SR number

Accept the Novell Service Request 11 digit number.

--name or -n name

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

--company or -c company

Enter the company name.

--storeid or -d id

Enter the store ID, if applicable.

--terminalid or -t id

Enter the terminal ID, if applicable.

--phone or -p phone

Enter the phone number of the contact person.

--email or -e email

Enter the email address of the contact.

7.1.3 rcsmt Init Script

The rcsmt script starts, restarts, or stops SMT services. If used without any sub-commands, it returns a help text. The rcsmt script can be used with the following sub-commands:

rcsmt start

Start the SMT services.

rcsmt stop

Stop the SMT services.

rcsmt status

Check the status of the SMT services. Checks whether httpd, MySQL, and cron are running.

rcsmt restart

Restart the SMT services.

rcsmt try-restart

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 MySQL database for SMT. The [LOCAL] section includes other configuration data. The [REPORT] section contains the configuration of SMT reports. You can find the configuration for the smt-mirror-sle9 command in the YOU9-* sections.

Warning
Warning

The /etc/smt.conf 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. In most cases, it should contain the https://nu.novell.com/ URL.

NURegUrl

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

NUUser

NUUser should contain the username 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 the service SMT uses, it can be either NCC for Novell Customer Center or SCC for SUSE Customer Center.

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

config

The first parameter of the DBI->connect Perl method used for connection to the MySQL 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 hostname 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 hostname of the server, for example http://smt.domain.tld/ instead of http://server1.domain.tld/.

nccEmail

E-mail address used for registration at the Novell 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
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

Determine if the clients registered at SMT should be registered at Novell Customer Center, too. If the forwardRegistration option is set to true, client registrations will be forwarded to Novell Customer Center. If the forwardRegistration option is set to false, no client registrations will be sent to Novell Customer Center. forwardRegistration does not work with SUSE Customer Center yet.

rndRegister

Specify a delay in seconds before registration of clients at Novell 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 Novell Customer Center server that would occur if all smt-register cron jobs connected at the same time.

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.

The HTTPProxy also applies to the smt-mirror-sle9 script.

HTTPSProxy

If you do not want to use global proxy settings, specify the proxy to be used for HTTPS connection here. Use the 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.

The HTTPSProxy also applies to the smt-mirror-sle9 script.

ProxyUser

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

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

Tip
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

Neither the ProxyUser value nor the global proxy authentication settings apply to the smt-mirror-sle9 script. For user authentication in smt-mirror-sle9 write the following in the $HOME/.wgetrc file: proxy_user=username proxy_password=password.

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 username 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 which the REST-Admin uses to login. 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.

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 smt-mirror-sle9 Sections of /etc/smt.conf

Each product to be mirrored by the smt-mirror-sle9 command has a separate predefined YOU9-* section in the /etc/smt.conf configuration file. /etc/smt.conf is not configured via the SMT database like the smt-mirror command, all configuration is contained in /etc/smt.conf.

mirror_prod

A product to be mirrored. For example Novell-Linux-Desktop.

mirror_archs

Comma-separated list of architectures to be mirrored. For example i386,x86_64. Remove any architectures that do not need to be mirrored.

mirror_version

The version of the product to be mirrored, for example 9.

mirror

If you want to mirror this product, set mirror to true.

credentials

If you want to mirror this product, provide credentials in the user:password format. Note that these credentials differ from the mirroring credentials used for SLES 10 and 11. You need to use the NCC login credentials here.

7.2.1.8 Example /etc/smt.conf

Example 7.1: smt.conf
[NU]
NUUrl = https://nu.novell.com/
NURegUrl = https://secure-www.novell.com/center/regsvc/
NUUser = exampleuser
NUPass = examplepassword
ApiType = NCC

[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 NCC
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 send 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 =

[YOU9-SLES-SDK]
mirror_prod = SLES-SDK
mirror_archs = i386,ia64,ppc,s390,s390x,x86_64
mirror_version = 9
mirror = false
credentials =

[YOU9-SUSE-CORE]
mirror_prod = SUSE-CORE
mirror_archs = i386,ia64,ppc,s390,s390x,x86_64
mirror_version = 9
mirror = false
credentials =

[YOU9-SUSE-SLES]
mirror_prod = SUSE-SLES
mirror_archs = i386,ia64,ppc,s390,s390x,x86_64
mirror_version = 9
mirror = false
credentials =

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.

NCC_SYNC_PARAMS

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

MIRROR_PARAMS

Contains parameters of the smt mirror command, if called as a 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 a 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 a 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 which 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 the rcsmt init script, 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 rcsmt restart 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 at 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:

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

  2. Select the required CA and click Enter CA.

  3. Enter the password if entering a CA for the first time. YaST displays the CA key information in the Description tab.

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

    Certificates of a CA
    Figure 7.1: Certificates of a CA
  5. Enter the fully qualified domain name of the server as Common Name. Add a valid e-mail address of the server administrator. Other fields, as Organization, Organizational Unit, Locality, and State are optional. Click Next to proceed.

    Important
    Important: Hostname in Server Certificate

    The server certificate must contain the correct hostname. If the client requests server https://some.hostname/, then some.hostname must be part of the certificate. The hostname 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>.

  6. Enter a Password for the private key of the certificate and reenter it in the next field to verify it.

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

    Important
    Important: Subject Alternative Name

    If Subject Alternative Name is present in the server certificate, than it needs contain the DNS entry. If Subject Alternative Name is present, the Common Name (CN) is not checked anymore.

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

  9. Click Create to generate the certificate.

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

  11. After having created a new certificate, restart SMT using the rcsmt restart 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 Sever 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 has 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:

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

  2. Click Import and select the file containing the certificate to be imported. Specify the certificate password in the Password field.

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

  4. After having created a new certificate, restart SMT using the rcsmt restart 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