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 script is used for starting, stopping, restarting SMT services, and for checking their status.
Since SUSE Linux Enterprise version 12, 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.
NOTE:Install mf-smt-client rpm bundled in Micro Focus SMT Media/ISO. This package is only supported for OES 2018 or later.
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 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 smt-job.
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: 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.
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-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 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).
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:
Show detailed information about the client. The last contact date is shown as well.
Enable debugging mode.
Specify the file the log will be written to.
Only the entries whose hostname begins with name will be listed.
Only the entries whose GUID is guid will be listed.
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.
The smt-delete-registration command deletes one or more registrations from SMT and Micro Focus Customer Center. It will deregister machines from the system. The following options are available:
Delete the machine with the guid ID from the system. You can use this option multiple times.
Enable debugging mode.
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 all client jobs. This is the default if the operation mode switch is omitted.
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 a new job.
Edit an existing job.
Delete an existing job.
Specify the client's guid. This parameter can be used multiple times to create a job for more than one client.
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.
Omit either the client's guid or the job ID in this delete operation. The missing parameter will match all clients respective jobs.
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.
Specify a job description.
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.
Specify a job name.
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.
Search option for finished jobs.
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.
Define when the job will no longer be executed anymore.
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).
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
The smt-list-products script lists all software products in the SMT database. The following options are available:
Show only used products.
Show whether all repositories needed for a product are locally mirrored.
The smt-list-registrations script lists all registrations. There are two options available for this command.
Show detailed information about the registered devices.
Format the output. Possible types of formats are asciitable and csv
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:
Remove all files no longer mentioned in the metadata from the mirror. No mirroring occurs before cleanup.
Enable the debugging mode.
Turn on verifying of all package checksums.
Search for duplicate files with a size greater than the size specified in kilobytes. Creates hard links for them.
Define the directory to work on. If you use this option, the default value configured in the smt.conf configuration file is ignored.
Define the path to the *.xml file to use as database replacement. You can create such a file with the sync-ncc command.
Specify the path to a logfile.
The smt-sync or smt sync command gets data from the Micro Focus Customer Center and updates the local SMT database. It can also save Micro Focus Customer Center data to a directory instead of the SMT database, or read the data from such a directory instead of downloading it from Micro Focus Customer Center.
The smt-ncc-sync or smt ncc-sync command gets data from the Micro Focus Customer Center and updates the local SMT database. It can also save Micro Focus Customer Center data to a directory instead of the SMT database, or read Micro Focus Customer Center data from such a directory instead of downloading it from Micro Focus Customer Center itself.
You can run the smt-ncc-sync with the following options:
Read Micro Focus Customer Center data from a directory instead of downloading it from Micro Focus Customer Center.
Write Micro Focus Customer Center data to the specified directory without updating the SMT database.
Create a database replacement file for using smt-mirror without database.
Specify the path to a log file.
Enable debugging mode.
The smt-register or smt-register command registers all currently unregistered clients at the Micro Focus Customer Center. It also registers all clients whose data has changed since the last registration.
The following options are available:
Specify the path to a log file.
Enable debugging mode.
The smt-report or smt report command generates a subscription report based on local calculation or Micro Focus Customer Center registrations.
The following options are available:
Force the creation of a report based on a local calculation without accessing Micro Focus Customer Center data.
Force the creation of a report based on Micro Focus Customer Center data.
Disable synchronizing with Micro Focus Customer Center before creating the report.
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.
Append the report to the e-mails in CSV format. This option should only be used together with the --mail option.
Suppress output to STDOUT and runs smt-report in quiet mode.
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).
The report will be exported in PDF format. Use it only together with the -file option.
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.
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.
Specify path to a logfile.
Enable debugging mode.
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 repository mirroring.
Enable repository mirroring by giving product data in the following format: Product[,Version[,Architecture[,Release]]].
Disable repository mirroring by giving product data in the following format: Product[,Version[,Architecture[,Release]]].
Enable repository staging.
Disable repository staging.
Disable repository mirroring.
List only repositories that can be mirrored.
List only enabled repositories.
List repositories and delete them from disk.
Delete the repository in the specified namespace.
Show detailed repository information.
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:
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.
The name of the custom repository.
The description of the custom repository.
The URL where this repository can be mirrored from. Only HTTP and HTTPS protocols are supported (no directory, file, or FTP).
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
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:
List available patches and their allowed/forbidden status.
Allow or forbids specified patches.
Generate both testing and production repository with allowed patches.
Give information about both testing and production snapshots, and patch counts.
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.
Create a staging group. Required parameters are: group name, testing directory name, and production directory name.
Remove a staging group. Required parameter is: group name.
The following options apply to any smt-staging command:
Write log information to the specified file. If it does not exist, it is created.
Turn on the debugging output and log.
Turn more detailed output on.
The following options apply to specific smt-staging commands:
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.
Specify the patch category. The following categories are available: 'security', 'recommended' and 'optional'. Use it with the allow, forbid, and listupdates commands.
Allow or forbid all patches in the allow or forbid commands.
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.
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.
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.
Specify on which group the command should work on. The default for --group is the name default.
During the repository creation with the createrepo command, avoid creating hard links instead of copying files. If not specified, hard links are created instead.
Do not print patch descriptions and summaries to save some screen space and make the output more readable.
Sort the listupdates table by patch version. The higher the version, the newer the patch should be.
Sort the listupdates table by patch category.
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:
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 the uploaded supportconfig archives in the incoming directory.
Delete the specified archive.
Delete all archives in the incoming directory.
Upload the specified archive to SUSE. If you specify -s, -n, -c, -p, and -e options, the archive is repackaged with contact information.
Upload all archives in the incoming directory to SUSE.
Accept the Novell Service Request 11 digit number.
Enter the first and last name of the contact, in quotes.
Enter the company name.
Enter the store ID, if applicable.
Enter the terminal ID, if applicable.
Enter the phone number of the contact person.
Enter the email address of the contact.
You can manage SMT related services with the standard systemd commands:
Start the SMT services.
Stop the SMT services.
Check the status of the SMT services. Checks whether httpd, MySQL, Maria DB and cron are running.
Restart the SMT services.
Check whether the SMT services are enabled and if so, restart them.
You can enable and disable SMT with the YaST SMT Server module.