Keep your SUSE Linux Desktops, Servers and OES Servers Updated

with Subscription Management Tool for SUSE Linux Enterprise.

Novell AppNote by Andreas Taschner - ataschner@novell.com

---
Teaser :
● 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.
---
Besides an overview this article will cover the following subjects :
● Installation and basic configuration
● Important files and directories
● Commands and tools
● Configuring clients
● Registration data synchronization with Novell Customer Center
● Using the test environment
● SMT reports
● Mirroring SLE 9
● Mirroring updates for Red Hat Enterprise Linux
● Custom catalogs
● Preloading repositories
● Server tuning
● Disconnected SMT servers
● Backup of SMT server

This article is targeted against medium experienced SUSE Linux Enterprise administrators.
The current document is v. 1.4 - refer to the changelog at the end of it for information about
changes.

SMT AppNote v 1.4 20081121 Page 1 of 20

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 nu.novell.com 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 nu.novell.com 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)

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

SMT AppNote v 1.4 20081121 Page 2 of 20

 ● 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)

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 smt.mycompany.com. This name must be resolvable to the clients for

SMT AppNote v 1.4 20081121 Page 3 of 20

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 http://download.novell.com/
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.

SMT AppNote v 1.4 20081121 Page 4 of 20

(fig-3 : YaST Software management dialog)
● 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)

● 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

SMT AppNote v 1.4 20081121 Page 5 of 20

(fig-5 : SMT configuration wizard-2/2)
● 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.

SMT AppNote v 1.4 20081121 Page 6 of 20

(fig-6 : Writing SMT configuration)

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/novell.com-smt 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

SMT AppNote v 1.4 20081121 Page 7 of 20

/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/clientSetup4SMT.sh 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 the article 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
or
# 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

SMT AppNote v 1.4 20081121 Page 8 of 20

Examples :

● 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 \
'http://download.videolan.org/pub/videolan/vlc/SuSE/10.1' \
--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 nu.novell.com
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=https://smt2.nts.com/center/regsvc/
regcert can be used to specify the location of the SMT server's CA certificate in case you are

SMT AppNote v 1.4 20081121 Page 9 of 20

 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 :
<customer_center>
<do_registration config:type="boolean">true</do_registration>
<reg_server>https://smt2.nts.com/center/regsvc</reg_server>
<reg_server_cert></reg_server_cert>
<register_regularly config:type="boolean">false</register_regularly>
<registration_data/>
<submit_hwdata config:type="boolean">false</submit_hwdata>
<submit_optional config:type="boolean">false</submit_optional>
</customer_center>
Adapt the reg_server and reg_server_cert as the corresponding kernel parameters
described above.

3. The clientSetup4SMT.sh script

SMT includes the /usr/share/doc/packages/smt/clientSetup4SMT.sh 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).
clientSetup4SMT.sh should be executed as root and takes the SMT server hostname or the
full registration URL as parameter like this :
# ./clientSetup4SMT.sh --host smt_server_FQDN
or
# ./clientSetup4SMT.sh 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 clientSetup4SMT.sh 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 :
#!/bin/bash
wget -O /tmp/clientSetup4SMT.sh smt2.nts.com/repo/clientSetup4SMT.sh
bash /tmp/clientSetup4SMT.sh --host smt2.nts.com<<EOF
Y
EOF
suse_register
rm /tmp/clientSetup4SMT.sh

SMT AppNote v 1.4 20081121 Page 10 of 20

The only way to configure SLE 10 SP1 (and earlier) based products to use SMT is using the
clientSetup4SMT.sh 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/novell.com-smt 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/novell.com-smt 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

SMT AppNote v 1.4 20081121 Page 11 of 20

 and
# 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/novell.com-smt 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
Generates
/tmp/smt-local-rep-product_subscription_active.csv
/tmp/smt-local-rep-product_subscription_alerts.txt
/tmp/smt-local-rep-product_subscription_expired.csv
/tmp/smt-local-rep-product_subscription_expiresoon.csv
/tmp/smt-local-rep-product_subscription_summary.csv

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

SMT AppNote v 1.4 20081121 Page 12 of 20

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 https://you.novell.com/update/ 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/
/x86_64/update/SUSE-CORE/9/images (irrelevant)
/x86_64/update/SUSE-CORE/9/patches
/x86_64/update/SUSE-CORE/9/patches.obsolete (irrelevant)
/x86_64/update/SUSE-CORE/9/rpm
/x86_64/update/SUSE-CORE/9/scripts
/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-
CORE/9/images,/update/x86_64/update/SUSE-
CORE/9/patches.obsolete,/update/x86_64/update/SUSE-SLES/9/sources
Another difference between the mirroring of SLE 10 and SLE 9 updates is that while the SLE 10
updates reside on the nu.novell.com servers, which are globally mirrored by an external IP
application accellerator, the SLE 9 servers get downloaded from you.novell.com. 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 :

SMT AppNote v 1.4 20081121 Page 13 of 20

 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/novell.com-smt :
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.
http://smtsrv.your.domain/repo/YOU9

Mirroring updates for Red Hat Enterprise Linux

Customers who have purchased SUSE Linux Enterprise Server Subscription with Expanded Support
(see http://www.novell.com/products/server/expandedsupport/offering_summary.html for details)
are entitled to mirror updates for Red Hat 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

SMT AppNote v 1.4 20081121 Page 14 of 20

# /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 "http://download.my.company/SLES10-SP2" \
--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 \ 657e1ad399d8cf69a8f7202baeb05db8c8835c93

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 nu.novell.com 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 AppNote v 1.4 20081121 Page 15 of 20

 # smt-mirror -d --dryrun -L /var/log/smt-mirror.log
This will - using the catalog above and the default MirrorTo - create :
/srv/www/htdocs/repo/repoindex.xml
/srv/www/htdocs/repo/$RCE/SLES10-SP2-Online/sles-10-i586/*
● 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 nu.novell.com and downloads the updates for each of them. The scenario could be
illustrated like this :

SMT AppNote v 1.4 20081121 Page 16 of 20

(fig-7 : Isolated SMT setup)
The initial setup of this special solution requires some extra configuration, but the regular update
synchronization with nu.novell.com 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

SMT AppNote v 1.4 20081121 Page 17 of 20

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 nu.novell.com
○ 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

SMT AppNote v 1.4 20081121 Page 18 of 20

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 /
nu.novell.com, 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 7001350 - How to configure isolated SMT servers for updating.

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.

References :
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
20081120 v. 1.4 :
Added references to article "Creating a YUM repository and publishing it with SMT", TID 1001751 -

SMT AppNote v 1.4 20081121 Page 19 of 20

How to update Red Hat Enterprise Linux with SMT and online SMT guide.
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.

SMT AppNote v 1.4 20081121 Page 20 of 20