Keep your SUSE Linux Desktops, Servers and OES Servers Updated with Subscription Management Tool for SUSE Linux Enterprise | SUSE Communities

Keep your SUSE Linux Desktops, Servers and OES Servers Updated with Subscription Management Tool for SUSE Linux Enterprise

  • You don’t want to let/have all your machines connect to Novell Customer Center to register and retrieve updates for bandwidth and / or security reasons.
  • You have servers or desktops in isolated networks that are difficult to update without having to invent your own update management solutions.
  • You are using the the “yup” (Yum Update Proxy) package from the SLE 10 Software Development Kit (SLE 10 SDK) to mirror updates to work around the problems above, but are concerned that yup is not an integrated, supported solution.
  • You would like to have one tool to mirror both SLE 9 and SLE 10 updates (and maybe miss the SLES 9 YOU server on SLES 10).
  • You have additional software update repositories (either external or internal) that need to be available to your clients.

Then your prayers might have been answered with Subscription Management Tool for SUSE Linux Enterprise.

NEW : This document ONLY applies to SMT 1.0 running on SLES 10.
For SMT 1.1 – that includes a number of cool new features – an official deployment guide (also written by me) is available here
A very useful document to bookmark is TID 7005002 – Subscription Management Tool master TID.

Besides an overview this article will cover the following subjects:

This article is targeted against medium experienced SUSE Linux Enterprise administrators.
The current document is v. 1.9 – refer to the changelog at the end of it for information about changes.
A PDF version can be downloaded here.

Overview of Subscription Management Tool (SMT) for SUSE Linux Enterprise.

With the release of the SUSE Linux Enterprise 10 platform Novell introduced a new mechanism for keeping systems up to date. By registering each individual host with Novell Customer Center (NCC) during or after installation, the machine regularly queries the update services and catalogs to see if new updates have been released.

While this process can potentially consume considerable internet bandwidth it can also make it difficult to enforce security policies at firewall level. Also in many customer installations there are SLE hosts, that do not have internet access at all.

The yup package from the SLE 10 SDK has been able to create mirrors of the update repositories for SLE 10 that the clients can add as update services and catalogs. However it does not act as a proxy for the registration process invoked by launching the Novell Customer Center Configuration module in YaST and the clients will still lead to contact the service even though yup is being used to mirror the updates.

SMT addresses the above issues and the reporting feature provides means for license tracking across large deployments as well as effective measurement of subscription to ease determining how many entitlements are in need of renewal at the end of a billing cycle.

Illustration of a typical SMT setup:

(fig-1 : SMT overview)

Click to view.

SMT supports SLE 10 SP2 and later based products and for a six months period after its release it also supports SLE 10 SP1. Besides this SMT also supports the SLE 9 based products.
So at the time of writing it is able to mirror the following products:

SUSE Linux Enterprise 10:

  • SUSE Linux Enterprise Server 10
  • SUSE Linux Enterprise Desktop 10
  • SUSE Linux Enterprise 10 Software Development Kit
  • Open Enterprise Server 2

SUSE Linux Enterprise 9:

  • SUSE Linux Enterprise Server 9
  • Novell Linux Desktop 9
  • SUSE Linux Enterprise 9 Software Development Kit
  • Novell Linux Point of Service
  • Open Enterprise Server

Furthermore you can configure mirroring of custom catalogs like hardware driver updates, own update repositories etc.

Depending on workload a single server scales up to handling 1000+ clients, although it may require some minor tuning efforts (discussed in a later section).

The product is mostly written in perl and plain shell scripts, creates a mysql database and publishes its repositories via apache. It communicates with NCC in https and the clients are served via https (registration process) and http (update retrieval).

(fig-2 : SMT components)

Click to view.

Installation and basic configuration

SMT must be installed on SUSE Linux Enterprise Server 10 SP2 – (active SLE maintenance subscription required) and in addition to the normal system requirements for SLES 10 SP2 the server must have a valid DNS host name such as This name must be resolvable to the clients for the certificates involved to work. Finally a rough estimate of 10 GB storage space per product to be mirrored is recommended (more if the sources are also to be mirrored).

SMT is provided as an add-on product to SLES 10. While it can also be installed during the initial SLES installation phase (see section 1.1 in the SMT guide) this article will discuss installing it on top of an already installed system.

The installation ISO image can be downloaded from

Before starting the installation, you should have the mirroring credentials to use available. How to find them is described in section 3.1 of the SMT guide. Until SMT has been installed, the guide is unfortunately only available in an rpm package on the SMT installation medium (CD1/suse/noarch/sle-smt_en-10.1-0.4.noarch.rpm). During installation this package installs the guide as PDF and HTML in /usr/share/doc/manual/sle-smt_en/. It has been requested to be put on the Novell online documentation web site.

The installation is described in section 1.2 and 1.3 of the SMT guide and flows as follows:

  • Start it by invoking the Add-on module in the Software group in the YaST Control Center (yast2 add-on).
  • Select the SMT medium you have downloaded as installation source and start the installation.
  • Accept the GPL licence prompt
  • The software management dialog appears. If selecting Patterns from the Filter drop-down menu and then selecting the SMT: Subscription Management Tool for SLE pattern at the bottom of the list, the three packages that constitute SMT will be shown as marked for installation.

(fig-3 : YaST Software management dialog)

Click to view.

  • When you select Accept YaST may install additional required packages to meet the prerequisites of SMT.
  • When the package installation has completed choose No to the “Install more packages” dialog.
  • After this the SMT configuration wizard (section 1.3 of the SMT guide) is launched.

(fig-4 : SMT configuration wizard-1/2)

Click to view.

  • In the first step of the wizard fill in NU user and NU password with your mirror credentials
  • Click the Test button to verify that the credentials entered are valid. It should result in a success message.
  • Enter the mail address that is registered in the Novell Customer Center and is linked to the mirror credentials.
  • Verify that Your SMT server URL points to the server (http://server-fq-dns-name)
  • Hit Next

(fig-5 : SMT configuration wizard-2/2)

Click to view.

  • In the second step of the wizard enter the desired password for the smt user that gets created in the mysql database configuration.
  • Here you can also add e-mail addresses that the SMT reports should be sent to.
  • Select Finish and enter the mysql root user password to set up the SMT database.

(fig-6 : Writing SMT configuration)

Click to view.

Now the configuration is written and an initial synchronization of products and entitlements from Novell Customer Center is performed in the background.

This may take a few minutes.

Important files and directories

The main configuration file is /etc/smt.conf. Since it is well documented in section 6.2.1 of the SMT guide we will not discuss it here except for a few parameters.

If source RPM packages are not relevant to your organization, then considerable time and disk space can be saved by disabling mirroring of these. This is done by changing the parameter MirrorSRC = true to MirrorSRC = false in the [LOCAL] section of /etc/smt.conf.

In case SMT should use different HTTP and HTTPS proxy servers than the globally settings, this can also be configured with parameters in the [LOCAL] section.

Besides /etc/smt.conf, other files and directories worth knowing about are:

File/Directory Description
/etc/smt.d/ Cron file – symlinked into /etc/cron.d/
/etc/smt.d/smt-cron.conf Parameters for cron jobs
/srv/www/htdocs/smt.crt Server certificate copied from /etc/ssl/certs/YaST-CA.pem
/srv/www/htdocs/repo THE update repository structure
/srv/www/htdocs/testing Sandbox for testing new updates
/usr/sbin/smt* Command line utilities to manage SMT
/usr/share/doc/manual/sle-smt_en/ Online documentation
/usr/share/doc/packages/smt/ Very useful other documentation
/usr/share/doc/packages/smt/ Script to import SMT server certificate and adapt /etc/suseRegister.conf
/var/log/smt* Log files from the scheduled smt commands. The /var/log/smt* get logrotated

In some scenarios it is not feasible to place the Subscription Management Tool (SMT) certificate and repository directories inside the apache2 DocumentRoot structure. It can for instance be security policies that prohibit even creating symbolic links to the SMT data within the DocumentRoot.
Check out How to clean SMT completely out of apache DocumentRoot for instructions on how to achieve such a setup.

Commands and tools

The main command line interface is /usr/sbin/smt, which takes subcommands and parameters for these. /usr/sbin/smt calls smt-subcommand executables in /usr/sbin/ which in turn then call tools in /usr/lib/perl5/vendor_perl/5.8.8/SMT/.

If the smt command is used alone, it prints out a list of all available subcommands (at the moment 10).

There are man pages for all smt-* commands and invoking
# smt help/-h subcommand
# smt-subcommand -h
also shows the syntax and options for the specific command.

In daily work one may find it handy to use smt-subcommand instead of smt subcommand since it enables tab-completion.

The smt subcommands are:

catalogs List available catalogs, enable/disable them for mirroring
delete-registrations Delete one or more registrations
list-products List all products in SMT database
list-registrations List all hosts registered with this SMT
mirror Perform the actual mirroring of SLE 10 based products
mirror-sle9 Mirroring of SLE 9 based products
ncc-sync Get data about products, targets, catalogs, subscriptions and registrations from NCC and updates SMT.
register Registers all currently unregistered and updated clients with NCC
report Generate an extensive report of the smt data. These can be in plain text or csv format, sent via mail
setup-custom-catalogs Enable and disable non-NU catalogs to be mirrored


  • List all sles-10-x86_64 based catalogs for that you are entitled to mirror

    # smt-catalogs -m ” sles-10-x86_64 (single quotes)
  • Enable mirroring of a catalog

    # smt-catalogs -e SLES10-SP2-Updates sles-10-x86_64
  • Show the catalogs that are marked for mirroring

    # smt-catalogs -o
  • Perform a mirror of the enabled SLE 10 catalogs with verbose output and logging

    # smt-mirror -d -L /var/log/smt-mirror.log
  • Perform mirroring of the SLE 9 products with verbose output and logging

    # smt-mirror-sle9 -d -L /var/log/smt-mirror-sle9.log
  • Create a report of SMT and NCC data based on information in the local datase.

    # smt-report –local
  • List the products in the database and their IDs

    # smt-list-products
  • Configure a non-Novell Update catalog for mirroring

    # smt-setup-custom-catalogs –productid 431 –name ‘VLC_SLED_10_SP1’ –exturl \
    ‘’ \

    –description ‘VideoLAN repository for SLED 10 SP1’

For information on which catalogs to enable for mirroring see TID 7001199 – Which software catalogs to mirror with Subscription Management Tool

Configuring clients to use SMT

SMT is primarily designed for products based on SLE 10 Support Pack 2 and later. However for a period of six months after its release Novell also provides technical support for SLE 10 SP 1 based products. All machines running SLE 10 SP2 or later can be configured to register with and download updates from SMT instead of having to communicate with the external NCC and servers.

Since the registration process against the SMT server uses https, the certificate of the server needs to be installed in the client certificate store as part of the configuration.

There are three different ways to configure SP2 clients to use SMT – all described in section 7 of the SMT guide.

  1. Kernel parameters
    Provide the regurl and optionally regcert kernel parameters during machine boot at installation time.
    regurl is the URL of the SMT server and must be specified in the following format:
    https://FQDN/center/regsvc/ with FQDN being the fully qualified hostname of the SMT server which again must match the FQDN of the SMT server certificate.
    Example: regurl=
    regcert can be used to specify the location of the SMT server’s CA certificate in case you are not using the default location of http://smt-server-FQDN/smt.crt.
  2. AutoYaST profile
    This method is much less error-prone and the preferred way for new clients to be installed.
    It is possible to use the Autoinstallation GUI frontend in YaST to create a customer_center section in an AutoYaST profile. Basically it creates an xml block like the following to include in the profiles used to install SP2 based clients:

        <do_registration config:type="boolean">true</do_registration>
        <register_regularly config:type="boolean">false</register_regularly>
        <submit_hwdata config:type="boolean">false</submit_hwdata>
        <submit_optional config:type="boolean">false</submit_optional>

    Adapt the reg_server and reg_server_cert as the corresponding kernel parameters described above.

  3. The script
    SMT includes the /usr/share/doc/packages/smt/ script, which can be used to configure a client machine to use an SMT server instead of Novell Customer Center or to reconfigure it to use a different SMT server than the already configured. Copy the script to the client machines – a suggestion could be to publish it in the MirrorTo/repo/ directory (by default /srv/www/htdocs/repo/) so that it is easily accessible to all clients via http. Keep in mind to make it executable to be displayed by apache (chmod 755). should be executed as root and takes the SMT server hostname or the full registration URL as parameter like this:

    # ./ --host smt_server_FQDN
    # ./ https://smt_server_FQDN/center/regsvc
    (pick your favorite)

    The script first downloads the SMT server’s CA certificate and prompts for acceptance of it before installing it in the certificate store. Then it modifies the url parameter in /etc/suseRegister.conf to point to the specified SMT server.

    Now the client is ready to register against the SMT server by running suse_register or the YaST Novell Customer Center Configuration module (yast2 inst_suse_register), but this task must be performed manually.

    I usually publish in the repo/ directory of my SMT servers and have created this tiny script to execute on the clients to perform all three steps with a single command:

    wget -O /tmp/
    bash /tmp/ --host<<EOF
    rm /tmp/

The only way to configure SLE 10 SP1 (and earlier) based products to use SMT is using the script. The parameters for the kernel and AutoYaST profiles are only implemented from SLE 10 SP2 and onwards.

Registration data synchronization with Novell Customer Center

By default information about registered clients are sent from SMT to NCC on a regular basis (every 15 minutes).

Some customers may be concerned about disclosing information about internal resources and for them we have solution.

Setting the parameter

	forwardRegistration = false 

in /etc/smt.conf will effectively disable this. The SMT tools take the setting of this parameter into account when communicating with NCC.

If you are really concerned – disable the “NCC registration” cron job in the YaST SMT Configuration module. This deletes the smt-repeated-register job from /etc/smt.d/ and since this file is marked as a configuration file, updates to SMT should not overwrite it. (Nevertheless it does not hurt to verify that /etc/smt.d/ has not been changed after applying updates to SMT).

Using the test environment

When new updates have been downloaded to your SMT repository, it might be useful to test them in a limited environment for potential “negative side effects” before making them generally available for other internal machines.

To save administrators from the hassle of inventing testing solutions SMT includes a documented (section 3.4), easy to use solutionUse this for testing of updates before “releasing” them to your registered clients.

During the installation the a $MirrorTo/testing/ structure (sibling to the production $MirrorTo/repo/ directory) gets created.

The scenario to use the testing environment looks like this:

  • Perform an smt-mirror to the $MirrorTo/testing/ structure:
  • Change MirrorTo to /srv/www/htdocs/testing in /etc/smt.conf and perform a normal smt-mirror
    or simply
  • # smt-mirror –directory /srv/www/htdocs/testing

    You can save time by pre-populating testing reposiroty with a copy of repo/ – e.g. with
  • # rsync -av /srv/www/htdocs/repo/* /srv/www/htdocs/testing/repo/.
  • Now reconfigure the test clients to use the test environment:
    • Change the register command in /etc/suseRegister.conf to:

      register = command=register&testenv=1
    • Run suse_register or yast2 inst_suse_register to register against the testing service/catalogs and verify that the testing service has been added and that the corresponding catalogs have been subscribed with e.g.

      # rug service-list


      # rug catalogs
    • The service name should have “/testing/” appended to the SMT server URL.

    Now testing can begin. Perform the desired level of testing and once you are done testing, deploy the contents of the testing environment. This could effectively be done with an rsync command like

    	# rsync -av /srv/www/htdocs/testing/repo/* to /srv/www/htdocs/repo/.
    • Then reconfigure the test clients to use the production environment by setting the register command back to default in /etc/suseRegister.conf:
    • 	register   = command=register
    • Run suse_register / yast inst_suse_register to register back against the production service/catalogs and verify that the service has changed back to normal with the same rug commands as above.

    SMT reports

    To assist customers in monitoring their license compliance SMT once a week generates a report based on SMT and Novell Customer Center data containing information about statistics of the registered machines, products used and of the active, expiring, or missing license subscriptions. In case subscriptions are about to expire and/or lack of licenses is observed (e.g. more SLES 10 machines are registered than you have purchased licenses for) the report contains warnings about this.

    In order to be able to calculate the compliance the smt-report tool by default downloads information about the subscriptions and registrations (this can be disabled).

    The addresses to send the reports to can be configured on the Database and Reporting tab of the YaST SMT Configuration module. All of the e-mail configuration options are located in the [REPORT] part of /etc/smt.conf and explained in section 6.2.1 of the SMT guide.

    The scheduling of the reports is configured in /etc/smt.d/ and the parameters to use with the cron jobs are set in REPORT_PARAMS in /etc/smt.d/smt-cron.conf file.

    The content of the reports is too comprehensive to cover in this article, but a set of reports can be broken down to five individual parts, which by default are attached as CSV files a single file to the mail on the weekly report run.

    To generate a set of reports in CSV files based on local data and display them on stdout, a command like this would work:

    # smt-report --local --csv --file /tmp/smt-local-rep



    Note that if you have multiple SMT servers deployed in your environment, the reports may not represent all of the SMT servers or machines in your environment. For the complete statistics of all your registered machines, refer to the information in the Novell Customer Center.

    The smt-report tool takes into consideration if forwarding of registration data to NCC has been disabled (forwardRegistration = false in /etc/smt.conf) and then sets the type of report to –local.

    For more information about types of reports, output formats and targets refer to section 5 of the SMT guide.

    Mirroring SLE 9

    Although SMT is primarily designed to manage SLE 10 based update repositories Novell has added basic functionality to enable mirroring of SLE 9 based products as well.

    It is not as slick as the SLES 9 YaST Online Update (YOU) Server, but the smt-mirror-sle9 tool creates a structure in $MirrorTo/repo/YOU9 that is similar to /var/lib/YaST2/you/mnt on a SLES 9 YOU server and stores the updates there.

    The catalogs to mirror are configured in /etc/smt.conf and by default it mirrors everything accessible on for each product.

    Noteworthy is that – since _all_ updates and sources for a product since it was released get mirrored – the repositories may consume up to 10+ times as much as what is needed by a freshly configured YOU server (e.g. 27G for SUSE-CORE 9 versus 2G respectively)

    For SUSE-CORE 9 this includes:

    /x86_64/update/SUSE-CORE/9/images	             	(irrelevant)
    /x86_64/update/SUSE-CORE/9/patches.obsolete     	(irrelevant)
    /x86_64/update/SUSE-CORE/9/sources	             	(relevant for some)
    And inconsistent index.html* files in all directories

    If one is annoyed by the irrelevant directories above, they can be excluded from download by creating the file /root/.wgetrc containg a line with comma-separated directories to omit – e.g.

    exclude_directories = /update/x86_64/update/SUSE-

    Another difference between the mirroring of SLE 10 and SLE 9 updates is that while the SLE 10 updates reside on the servers, which are globally mirrored by an external IP application accellerator, the SLE 9 servers get downloaded from This leads to considerably slower download rates (especially during the initial download of the repositories), but I guess that the users of smt-mirror-sle9 can survive that due to the excitement that it at all is possible to mirror SLE 9 updates with SMT 🙂

    So how do we get it to work ?

    1. Enable mirroring of the products and architectures desired to mirror in /etc/smt.conf. If we for example want the updates for SLES 9 i386 and x86_64 architectures, the following changes should be applied to both the Apply these changes to both the [YOU9-SUSE-CORE] and [YOU9-SUSE-SLES] sections:

           Change mirror = false to mirror = true

           Change mirror_archs to only reflect those you need – e.g.

           mirror_archs = i386,x86_64

           Set credentials to those in /var/lib/YaST2/you/password on your YOU server – e.g.

           credentials = my-ncc-account-name:password
    2. (Optional) Create the file /root/.wgetrc to exclude undesired directories as described above.
    3. Perform the actual mirror. To run it with verbose output and logging to a file that gets logrotated use a command like:

           smt-mirror-sle9 -d -L /var/log/smt-mirror-sle9.log
    4. Schedule regular execution of smt-mirror-sle9 by e.g. adding a line like this to /etc/smt.d/

           33 3 * * 1 root /usr/sbin/smt-mirror-sle9 -L /var/log/smt-mirror-sle9.log

      This executes it at 3:33 AM every day.
    5. Configure Online Update on the SLES 9 servers to point to your SMT server – e.g.


    Mirroring updates for Red Hat Enterprise Linux

    Customers who have purchased SUSE Linux Enterprise Server Subscription with Expanded Support (see for details) are entitled to mirror updates for Red Hat Enterprise Linux 3.9, 4.7 and 5.2 as described in the terms above.
    The support for this is enabled in version 1.0.7-0.3 and newer of the SMT package.
    How to configure the SMT server and the Red Hat clients to use SMT as their update source is described in TID 7001751 – How to update Red Hat Enterprise Linux with SMT.

    Custom catalogs

    SMT also includes functionality to mirror catalogs that are not available at the Novell Customer Center – custom catalogs. It might be your own in-house developed applications or third-party driver/software repositories like close-source hardware drivers that Novell for legal reasons are not shipping with their products.

    If you would like to create your own catalog with updates and publish it with SMT the article Creating a YUM repository and publishing it with SMT” explains you all the steps.

    When configuring custom catalogs to be mirrored with smt-mirror all catalogs must be associated to one or more Novell product IDs. This ID can be determined using the smt-list-products command:

    # smt-list-products | grep SUSE-Linux-Enterprise-Server-SP2 | grep x86
    |  824 | SUSE-Linux-Enterprise-Server-SP2            |      10 | x86_64       | -         |     5 |
    |  839 | SUSE-Linux-Enterprise-Server-SP2            |      10 | x86_64       | online    |     0 |
    |  809 | SUSE-Linux-Enterprise-Server-SP2-migration  |      10 | x86_64       | -         |     1 |

    As can be seen from the output above there can be multiple IDs for the same product depending on the release, which basically represents the way that the SLE product has been installed. Base is installed directly and online is an upgraded product – eg. a machine originally installed from SLES 10 SP1 medium and then online updated to SP2.

    To determine the release of a SLE 10 SP2 product execute:

    # /usr/lib/zypp/zypp-query-pool products @system
    i|product|SUSE_SLES_SP2|10.2-0|x86_64|SUSE-Linux-Enterprise-Server-SP2|10-SP2|base|SLES 10 SP2|SUSE Linux Enterprise Server 10 SP2

    The 8th field is the release
    base = “-” in smt-list-products
    online = online in smt-list-products
    So for the machine above the product ID would be 824.

    To associate a catalog with multiple product IDs, just add more –productid ID# parameters – e.g.:

    # smt-setup-custom-catalogs --productid 824 --productid 839 \
    --name "My_own_SLES10_SP2_APP_UPDATES" \
    --exturl "" \
    --description "Private SLES updates"

    If the custom catalog/repository is unsigned, the clients may fail to subscribe to them for the following reason. In its default configuration SUSE Linux Enterprise 10 does not allow the use of unsigned repositories. Therefore, if you want to mirror unsigned repositories and use them on client machines, you have to allow this explicitly by executing the following command on the client machines:

    #rug set security-level checksum

    This may or may not be a securiy concern of your company, but custom catalogs are beyond control of Novell and it is something that you need to work out how to deal with.

    When deleting a custom catalog, the ID to provide is the GUID. Find it with the smt-catalogs command:

    # smt-catalogs -v VLC_SLED10_SP2 |grep ID
    CatalogID: 657e1ad399d8cf69a8f7202baeb05db8c8835c93

    and then delete the catalog from the local SMT database with

    # smt-setup-custom-catalogs –delete \

    For more on setting up custom catalogs refer to smt-setup-custom-catalogs -h or section 2.5 in the SMT guide.

    Preloading repositories

    Although the servers are accellerated as mentioned previously and you may have lots of internet bandwidth, deploying multiple SMT servers may become time consuming if each new SMT server must mirror the same repositories.

    If you today are deploying the YUM Update Proxy package (yup) from the SUSE Linux Enterprise 10 Software Development Kit, you may already have most of the update repository packages and metadata in place.

    To save time when deploying new SMT servers, the catalogs can be preloaded from another server/disk instead.

    The steps involved in doing that are:

    • Enable the catalogs to be mirrored with SMT – e.g.:

      # smt-catalogs -e SLES10-SP2-Online sles-10-i586
    • Perform a dry-run of smt-mirror to get the repository directories created

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

      This will – using the catalog above and the default MirrorTo – create:


    • Now you can copy over the repositories – e.g. from your yup|$DEST_DIR – e.g.:

      # cp -va /SLE10_YOU/SLES10-SP2-Online/* /srv/www/htdocs/repo/\$RCE/SLES10-SP2-Online/
    • To get the repodata fixed up perform a normal smt-mirror like:

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

      Be prepared for errors like “repomd.xml is the same, but repo is not valid. Start mirroring.”

    Server tuning

    The /usr/share/doc/packages/smt/Server-Tuning.txt contains very useful tips on different ways of tuning SMT server performance.

    Here you will find tips on increasing number of clients for apache2, increasing mysqld connections and also how to speed up database connection by installing the perl-Apache-DBI module from the SUSE Linux Enterprise 10 Software Development Kit.

    Disconnected SMT servers

    In some restricted environments it is not possible for the SMT servers to have access the internet because the are located in disconnected or isolated networks.

    By using some special options on the SMT commands and a mobile disk it is possible to accommodate for this by having one SMT server that operates on behalf of the “isolated” SMT servers towards and downloads the updates for each of them. The scenario could be illustrated like this:

    (fig-7 : Isolated SMT setup)

    Click to view.

    The initial setup of this special solution requires some extra configuration, but the regular update synchronization with and distribution to isolated servers is relatively simple. While the details in the configuration are covered later a quick overview might be useful first.

    The steps required during the initial setup consist of:

    • Installation and configuration of the external SMT server “by the book”
    • Installation of the internal server
    • Modification of smt.conf and cron setup on internal server
    • Creation of a copy of the NCC data on the external SMT server and import of it on the internal SMT server
    • Enabling and disabling of catalogs as pleased on the internal server
    • Creation of an SMT database replacement file (which can be used instead of the normal mysql SMT database when performing the mirror jobs) on the internal server

    The daily operation includes:
    On the external server an smt-mirror based on the database replacement file and to the mobile disk
    Copying of the mirrored repositories from the mobile disk to the internal SMT server

    We will now describe the individual steps in detail considering the information discussed earler in this article.

    • Install and configure the external server “by the book”
    • Install and configure the internal server:
    • Ensure to have a working SLES 10 SP2 installation source
    • Ignore potential errors in the “Writing SMT Configuration” phase of the wizard
    • The synchronization check takes a long time every time the yast smt module wraps up because it can not reach
    • Abort the NCC Configuration wizard and then Abort installation
    • Re-launch the YaST SMT Configuration module and go to the “Scheduled SMT Jobs” tab
    • Delete “NCC Registration” and “Synchronization of Updates” jobs
  • Finish the wizard
  • Prevent registration data upstream sync to NCC
  • Set forwardRegistration = false in /etc/smt.conf
  • Prevent sync with NCC before creating reports
    • Insert “–nonccsync” at the beginning of the REPORT_PARAMS list in /etc/smt.d/smt-cron.conf
  • Connect the mobile disk to the external server and create a copy of the NCC data on it
    • # smt-ncc-sync –todir /path-to-dir-on-mobile-disk
  • On the internal server :
    • Connect the disk and populate the SMT database with the NCC data just created
    • # smt-ncc-sync –fromdir /path-to-dir-on-mobile-disk
  • Enable mirroring of the desired catalogs
    • smt-catalogs -e …
  • Create a database replacement file on the mobile hard disk
    • # smt-ncc-sync –createdbreplacementfile /path-to-a-file-on-mobile-disk
  • Now the configuration is complete, but the update repository is empty
  • After one iteration of the daily/normal operation, the internal server is ready to serve clients, since this synchronizes the update repositories
  • Daily operation:

    • Connect the mobile disk to the external server
    • Perform a mirror based on the file on the mobile disk and to a directory on the mobile disk
    • # smt-mirror –dbreplfile /path-to-dbrepl-file-on-mobile-disk \

      –directory /path-to-repository-on-mobile-disk \

      -L /var/log/smt-mirror-disconnected-01.log
  • Scan the mobile disk for virus and other if desired
  • Connect the mobile disk to the internal SMT server and copy/rsync the updated repository to the local disk/storage on the server – e.g.
    • # rsync -av /media/disk/smt-01/repo/. /srv/www/htdocs/repo

    If you are operating many isolated SMT servers much of the above can be automated by scripting and the daily update mirroring could be optimized.

    For instance let us say that we are operating 5 isolated SMT servers with the same catalogs and architecture targets. It would still be recommended to perform the initial setup and creation of databases on each of the isolated servers in order to maintain supportability. Each SMT server has its unique GUID (SMT ID – taken from /etc/zmd/deviceid) and this one is being used when downloading updates using smt-mirror with the –dbreplfile option as described above. In case of problems with downloading and assistance from Novell Technical Services is required, the SMT ID might be needed to perform troubleshooting.

    However for the daily (or whatever mirroring interval will be used for the isolated SMT servers) it would strictly spoken then only be necessary to perform the

    # smt-mirror --dbreplfile /path-to-dbrepl-file-on-mobile-disk \
    --directory /path-to-repository-on-mobile-disk

    once. The same repository could then be copied around to all of the 5 isolated SMT servers.

    Due to the fact that isolated SMT servers do not have a connection to Novell Customer Center /, they do not get subscribed to the SLES10-SP2-Updates and SLE10-SP2-SMT-Updates catalogs
    SMT is currently not designed to be able to update itself, but you can work around that by following the instructions in TID 7002607 – Configuring SMT 1.0 servers to use self-hosted repositories.

    Backup of SMT servers

    We all know that for many of us the last thing we think of is backups. In case of loss of an SMT server the update repositories can be re-mirrored, but the SMT mysql database will be gone and it is not possible to recover or synchronize it back from NCC.

    This database contains information about things like clients, registrations, machine data, which catalogs that are enabled for mirroring, custom catalogs.

    So it is highly recommended to include backup of at least your SMT database and possibly also the update repositories into your normal backup solution. Since the database is mysql based, the simplest way to produce a restoreable backup is to create a cron job that performs a simple mysqldump of it with a command like :

    	# mysqldump -uroot -p<smt-db-pwd> smt > /some-directory/smt-db-backup.sql

    and include the file in your normal backup jobs.

    Hopefully this article has helped demystify the Subscription Management Tool for SUSE Linux Enterprise and equipped you with some tips that can be useful when deploying SMT in your networks to keep your SUSE Linux Enterprise 10, OpenEnterpriseServer 2 and SUSE Linux Enterprise 9 based products up to date with updates from Novell Customer Center.


    Subscription Management Tool Guide – available online and in /usr/share/doc/manual/sle-smt_en/.
    Documents in /usr/share/doc/packages/smt/.
    Frequently Asked Questions for Subscription Management Tool for SUSE Linux Enterprise.

    Changelog :

    20100622 v. 1.9 :
    Update link to TID 7002607, added link to 7005002
    20100420 v. 1.8 :
    Clarified that this article only applies to SMT 1.0
    20091210 v. 1.7 :
    Fixed broken link to the SMT 11 deployment guide.
    20091209 v. 1.6 :
    Link to the SMT 11 deployment guide.
    20091009 v. 1.5 :
    Removed leading whitespaces in script to download and execute
    20081121 v. 1.4 :
    Added references to article “Creating a YUM repository and publishing it with SMT“, TID 1001751 – How to update Red Hat Enterprise Linux with SMT and online SMT guide.
    Published PDF version of this document.
    20080917 v. 1.3 :
    Added reference to TID 7001350 – How to configure isolated SMT servers for updating.Fixup of hyperlinks to open in new windows, links within document.

    (Visited 7 times, 1 visits today)


  • Avatar photo fpernet says:

    I am conducting many different tests with SMT and I must say that I am very happy with this product.

    The point now is to use SMT to receive updates for SLES9 and OES1 (or 9). I followed this appnote and it works only for SLES9 but not for OES (error : is Authorisation failed)… the credentials are the same for both products (ncc credentials as explained in the appnote).

    I would like to know if it still possible to receive updates for OES and/or if the link is wrong, etc…

    Any idea ? thx in advance

  • Avatar photo ataschner says:

    I have been asked about this in the past. It is most likely because your purchase of OES1 has not been registered correctly in the Novell Customer Center/system. Please contact the Novell office/partner, where you bought the licenses and have them follow it up.
    Just ran a mirror of OES1 and it (still) works.
    Hope this helps.
    Best regards

  • Avatar photo mouring says:

    However, in some environments we’d prefer not to run a mysql database and management system just for handling client updates. If we wished to go down this route we would have continued implementing ZLM.

    Please consider pulling out the “smt-mirror” tool and allowing it to be a standalone tool for those that don’t need the extra wieght of the mini-registration system.

    We were perfectly happy with “yup” until it became discounted for updates, and don’t really wish to continue to hack it to support newer version.

  • Avatar photo markuswiedner says:


    I was wondering if you had any experience with running SMT through a proxy with NTLM Authentication? I have trouble revceiving the catalogue infos when trying to sync SMT with NCC. More precisely, when I issue this command:
    smt-ncc-sync –debug –logfile

    …what I find in the resulting logfile is this pattern (and no catalogues are added):

    2009-08-18 09:49:03 SMT::Mirror::RegData – [error] Failed to POST ‘https://secu’
    2009-08-18 09:49:03 SMT::Mirror::RegData – [debug] proxy connect failed: PROXY ERROR HEADER, could be non-SSL URL:
    2009-08-18 09:49:03 SMT::Mirror::RegData – [debug] HTTP/1.1 407 Proxy Authentication Required

    However, proxy settings are configured in smt.conf (and in YaST->Proxy as well) and when I test the mirror credentials in YaST-SMT the test is successful, too. Testing the proxy settings also returns a success message. Still, I cannot seem to get the SMT working behind the proxy.

    Have you got any ideas on how to solve this? Thank you.

  • Avatar photo ataschner says:

    Hallo Markus
    Unfortunately I have not tried that. Have you tried if it works (just for testing) with SMT11 ?
    Besides this I would suggest that you run this by the or contact a Novell service provider.

  • Avatar photo markuswiedner says:

    Hello Andreas,

    thanks for your reply. I have a post in the forum but unfortunately not yet received answers pointing in the right direction. It might simply be that this constellation – SMT through NTLM proxy – does not work.
    However, I take your advice and will turn to Novell with a support query and I’ll have a look at SMT11, too.

    Thanks again,


  • Avatar photo fpernet says:


    In order to debug, please keep in mind that if you do not specify any proxy settings in smt conf file, it is supposed to read proxy setting in the general proxy configuration file (ie: /etc/sysconfig/proxy).
    So in a first step, remove any proxy setting in smt, then specify proxy settings in this general conf file and try a wget command in order to fully test the proxy.
    If it works, then try you smt commands without any proxy setting in the smt conf file…
    Just an idea …
    and continue this thread in the forum, it will be easier…

  • Avatar photo dhorsfall says:

    I just installed SMT on SLES 11. Works great except …

    I don’t see a choice for OES2 SP1 in my list of update sources.

    I’ve got things like Orchestrate, virtual machine driver packs, Zen Pulsar (ZCM I think?) but no OES anything.

    I’m a Gold partner and have about six OES2 SP1 boxes running in my local network, all registered and directly updating with no issues.

    So, how do I enable SMT to update my OES2 SP1 servers? Did I miss something?



  • Avatar photo fpernet says:

    Hi Don,

    I don’t know how far you’ve gone through the install but at a point, you need to ask smt to mirror the channels you want. Then they will be available for your SMT client machines.

    Did you follow the link ?:

  • In the available catalogs you can then subscribe to OES2 SP1 updates, then let you SMT download all patches. When it’s done, verify that patches are ready both with the log of smt, and by browsing the http smt repository under $RCE. If it’s ok, the rest in on the client side.

  • Avatar photo dhorsfall says:

    Yes, I did find the documentation on Novell support.

    Looks simple. Go to Yast | Network Services | SMT Server Management. Just pick OES2 SP1 from the list that’s presented and click the Toggle Mirroring button.

    That’s what I did for SLES 10 SP2 and the ati and nvidia drivers. Works as advertised.

    Unfortunately, there’s no OES2 SP1 choice in the list to choose. It’s just not there.

    If I could get it to show up in the list, I’d be fine. Once it’s in the list of available repositories, I can get it mirrored and staged and give my client machines access.

    What I don’t know is how to add a Novell repository, in this case OES2 SP1, to the list of available repositories for SMT.



  • Avatar photo caruthers says:

    Had to change the script that pulls to get it to work. Every time I ran it, I would see the certificate from my server and it would immediately say Aborted. Looking at the script, it appeared to be the answer to the question causing the problem. After removing the preceding white space on all the lines the script works fine.

  • Avatar photo ataschner says:

    You are right. I had missed that they had snuck in somewhere along the editing process.
    I have now corrected the article.
    Thanks for the feedback.

  • Avatar photo ataschner says:

    For those wondering why this article has not been updated with all the new cool stuff in SMT 11…
    I am in the final stages of an revamped article that will cover SMT 11 and hope that it will be released soon.
    Stay tuned.

  • Avatar photo tkdub says:


    i installed SMT on SLES10 SP2 to mirror SLES11 Update.
    The output of smt-mirror looks ok, but when I try to update a SLES11 with yast or zypper, it can’t find the delta patches.
    Any idea how to make it work ?


  • Avatar photo ataschner says:

    Hi Bernhard
    A few things to check.
    1) Make sure that you have updated SMT to the latest version. Correct delta RPM handling requires smt-1.0.11-0.3
    2) After the SLE 11 clients have registered, run the command
    # zypper ref -s
    on each of them (if they are registered from the command line)
    This is described in TID 7003779.
    3) Obviously mirror the appropriate SLES 11 repository for the right target/architecture (although you seem to have done that).

    Hope this helps.

  • Avatar photo tkdub says:


    on sunday afternoon I updated SMT to the newest version und started smt-mirror manually, but the delta patches didn’t arrive at my machine. But last night they finally arrived. It looks like smt-mirror only works once per day.

    Thank you for your help

  • Avatar photo ataschner says:

    Hi Bernhard
    smt-mirror does its job every time.
    What might explain your observation is that there were no new updates on Sunday afternoon, compared to the metadata (in the repodata on your SMT server) from the last time you successfully mirrored SLES11-Updates. This is regardless of the deltarpms.
    Only when the metadata is newer on than what you have in your catalog, it will trigger a mirror that checks for what files are already on your server, see that the deltarpms are missing and download them.
    For others running into this, just delete the files in $MirrorTo/$RCE/SLES11-Updates/$arch/repodata/ before kicking off the mirror. That will then force a complete check and pull down the deltarpms even if there are no new patches available for download.

  • Avatar photo mouskouyouss says:

    Hi Andreas,

    What’s the status of your new article about SMT 11 ?
    When do you think it will be ready ?

    thanks for any update…

  • Avatar photo ataschner says:

    It has been broken into two parts.
    One will be a teaser article in the Novell Connection Magazine December edition – hopefully available at the end of next week at It which will refer to the other part – a new official SMT Deployment guide on the Novell documentation site.
    The latter will be released at the same time as the Connection Magazine.

    I am sorry that it has taken so long, but once things turn official, they tend to take more time 🙂


  • Avatar photo peterhine says:

    Anyone know how to get rid of this curl error. i’ve tried adding the CA info from my SMT server to the client machine’s /usr/share/curl/curl-ca-bundle.crt, but no help.

    is there another file ?

    the script only creates a /etc/ssl/certs/registration-server.pem file, so doesn’t appear to address curl.

    is there a place to add the -k (curl param) that the registration scripts will look ?

    > suse_register
    Execute curl command failed with '60':
    curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
    error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
    More details here:

    curl performs SSL certificate verification by default, using a "bundle"
    of Certificate Authority (CA) public keys (CA certs). The default
    bundle is named curl-ca-bundle.crt; you can specify an alternate file
    using the --cacert option.
    If this HTTPS server uses a certificate signed by a CA represented in
    the bundle, the certificate verification probably failed due to a
    problem with the certificate (it might be expired, or the name might
    not match the domain name in the URL).
    If you'd like to turn off curl's verification of the certificate, use
    the -k (or --insecure) option.

  • Avatar photo mouskouyouss says:

    A colleague of mine got a similar error, but I’m not 100% sure.
    Try to put the cert in /etc/ssl/certs and run the c_rehash command:

    Hope it helps.

  • Avatar photo peterhine says:

    thanks, but that is what does, get’s the cert, puts it in the directory and runs the hash command.

    I’ve done some more investigation. It appear the problem lays with curl, it’s use of ssl or the ssl libraries. But this can’t be because the system works with, who has a cert signed by a real certifier. so is it the dummy YAST-CA cert that curl (or it’s libraries) doesn’t deal with ?

    anyway, i moved curl to curl.bin.
    created a bash script called curl in it’s place and had it call
    curl.bin -k $*

    the -k will now always be applied. Typical of Novell software. Never quite completing the job.


  • Avatar photo ataschner says:

    Hi guys

    First – this kind of discussions do not belong on this article. The place for that is in the forums.
    Going to and searching for “curl error 60”, returns TID 7002146 with suggestions for resolution.
    Searching for “curl error 60” in | SLES | Updates also immediately reveals a highly relevant thread with proven solution (included in the TID).


  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Avatar photo