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:
- 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.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 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
- 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 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.
(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
(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.
(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:
|/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|
|/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/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 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
- 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 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.
- 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.
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.
- 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.
- 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
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
- # 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/.
- 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
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
/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 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 ?
- 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
- (Optional) Create the file /root/.wgetrc to exclude undesired directories as described above.
- 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
- 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.
- 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 http://www.novell.com/products/server/expandedsupport/offering_summary.html 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.
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 "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.
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-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.”
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:
(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
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
- Insert “–nonccsync” at the beginning of the REPORT_PARAMS list in /etc/smt.d/smt-cron.conf
- # smt-ncc-sync –todir /path-to-dir-on-mobile-disk
- Connect the disk and populate the SMT database with the NCC data just created
- # smt-ncc-sync –fromdir /path-to-dir-on-mobile-disk
- smt-catalogs -e …
- # smt-ncc-sync –createdbreplacementfile /path-to-a-file-on-mobile-disk
- 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 \
- # 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 / 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 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.
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 clientSetup4SMT.sh
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.