Novell Home

Novell Connection Magazine Home

Subscription Prescription

Novell IS&T manages 1,500 SUSE Linux Enterprise Desktop desktop subscriptions with the
Subscription Management Tool for SUSE Linux Enterprise

  • Ready to buy a Novell product? Click here to jump to ShopNovell!
  • Request to talk to a Novell representative about a Novell product.

Step Three: Creating Custom Catalogs

The IS&T team also wanted the new update server to support several internal products and openSUSE RPMs. To do this, they first created a package repository from which to mirror (both YUM and ZYPP work well) using the Add-On Product module in YaST. Then they decided from which SUSE Linux Enterprise products these packages should be available.

“The smt-list-products command shows you all the products that Subscription Management Tool knows about,” Crute explained. “Depending on your subscriptions to Novell Customer Center, you’ll see quite a few different versions of SUSE Linux Enterprise Desktop, and you need the product ID to set up a custom catalog. So, for instance, if you’re in a country where VideoLAN is legal, you can instruct Subscription Management Tool to mirror it by entering the following command:

smt-setup-custom-catalogs --productid 431 \--name 'VLC_SLED_10_SP1' --exturl \ '' \ --description 'VideoLAN repository for SLED 10 SP1 do not use in USA or EU countries'

“If you’ve created a custom repository you want to mirror, simply enter the URL. If you’re not sure the IP address will be stable over time, you may want to create a separate Apache vhost on the Subscription Management Tool server and copy the repository contents there from the build location.”

To sign a repository before importing it into Subscription Management Tool, run the following commands from the repository directory:

gpg –default-key [keyid] -a --detach-sign repodata/repomd.xml
gpg -a –export [keyid] > repodata/repomd.xml.key

To get the public key into the client, either import it with a post-install script or modify the installation boot media.

Step Four: Creating a Staging Environment

Like any rational administrator, the Novell team also wanted a staging environment where it could test new packages thoroughly before moving them into production. Subscription Management Tool doesn’t support that capability in its default configuration, but it is easy enough to add with a bit of Apache config file work.

“The idea is to create two vhost definitions,” Crute said. “One for, the other for Both are on the same box, but a little Apache redirection sends the production and staging requests to different directories.

[SMT Article Script File #1]

<VirtualHost *:80>
ServerAdmin [deleted]
alias /repo/ /srv/www/htdocs/production/repo/
alias /repo /srv/www/htdocs/production/repo

<irtualHost *:80>
ServerAdmin [deleted]
alias /repo/ /srv/www/htdocs/repo/
alias /repo /srv/www/htdocs/repo

To selectively move tested RPMs into production without disturbing those still under evaluation, or disrupting the physical repositories on disk, the Novell team wrote a script that makes daily backups of the staging catalogs, naming them by date. To minimize the time and disk space required, a link copy is made (see man cp for details) which, in essence, simply duplicates the inodes or directory information, leaving the actual files unchanged. Click here to see the complete script code.

[SMT Article Script File #2]

#script to keep multiple copies of the staging catalogue to enable us to move a
#specific day's staging into production after testing.
#the backups are created as "hard link copies". See the cp man page and the --link option.

# the number of copies to keep
#where the staging catalogue are kept
#where the backup catalogues are kept.
# Must be the same file system as STGAGING_LOCATION.
# Do not use spaces in name
#the basename of the backup directory

if [[ $1 != $BACKUP_LOCATION ]] ; then
echo "BACKUP_LOCATION has bad characters in it, probably spaces, or IFS is set incorrectly"
echo "Failure to fix this may result in data loss on your server"
#create new backup name.and check dir does not exist
if [[ -e $NEW_NAME ]] ; then
echo "$NEW_NAME" already exists. Quiting.
#find out how many backups there are and remove old ones.
#if there are more than COPIES, remove the oldest
while [[ $NO_BACKUP_DIRS -gt $COPIES-1 ]]; do
echo "Removing old backup: $"
rm -rf $1
#copy the newest one.
echo "Link-Copying staging to staging backup"
cp --archive --link $STAGING_LOCATION $NEW_NAME

Once administrators are satisfied with a set of updates, they simply rename the directories from the backup location into production. A daily e-mail is circulated that summarizes the differences between staging and production. Click here to see the e-mail creation script.

[SMT Article Script File #3]

#bash script to show the differences between two repositories.

echo "=============================================================="
echo "This script will report the differences between staging and production"
echo -n "Running at "
echo "=============================================================="

for REPO in ${REPOS[*]}; do
echo "Looking at $REPO"
echo "-----------------------------------------------"
echo -n "Total new RPMs "
diff -r $PRODUCTION/$REPO $STAGING_LOCATION/$REPO |cut -f 4 -d " " |grep -v .patch.rpm | grep -v .delta.rpm | wc -l
echo "RPM list follows"
diff -r $PRODUCTION/$REPO $STAGING_LOCATION/$REPO |cut -f 4 -d " " |grep -v .patch.rpm | grep -v .delta.rpm

Stage Five: Migrating Existing Systems

With its Subscription Management Tool server functioning correctly, the Novell team then repointed its client systems to the new source for registration and update services. Several methods are available. For new installations, the following script can be added at boot time:

regurl=https://[servername]/center/regsvc regcert=done

Subscribe to Connection Magazine

The same script can be easily adopted for PXE-based network installs, and in the physical boot media used in media-based installations. For installations via AutoYaST, another script fragment can also be used to register new machines.

[SMT Article Script File #4]



And finally, Subscription Management Tool includes the following script, which can be used to help migrate existing machines:

/usr/share/doc/packages/smt/ https://[servername]/center/regsvc

This can be incorpoated into existing login scripts, or wrapped and distributed for users to run. If you have an existing update infrastructure in place, you can even create a package around this script that moves users to the new service automatically.

Step Six: Transparently Caching Updates at Distributed Locations

The final decision required in deploying Subscription Management Tool, at least in an installation with multiple locations under management, is how to best provide distributed access to the update service. Deploying separate Subscription Management Tool servers in each location increases the administrative overhead, sacrifices transparency, and reduces bandwidth efficiency, particularly for users who travel between branches.

Instead, the Novell team decided to cache update transfers locally using the Squid caching proxy server. This required configuring a Squid server at each location to accept transparent proxying, then configuring the router at the Subscription Management Tool site to send Subscription Management Tool-bound traffic to the local proxies. On Cisco routers this is known as a policy route. Details for configuring Squid can be found at

The Novell team is using the following aging details for its Squid servers. These are provided as an example only, with no claim of correctness or best practice.

[SMT Article Script File #5]

refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern (cgi-bin|\?) 0 0% 0
#long age on rpms cos an rpm file name should not change
refresh_pattern -i smt\.foo\.com/.*rpm 4320 100% 43200 reload-into-ims
#much shorter age on repodata cos it does change
refresh_pattern -i smt\.foo\.com/.*repodata 10 20% 60
refresh_pattern -i smt-stage\.foo\.com/.*rpm 4320 100% 43200 reload-i
refresh_pattern -i smt-stage\.foo\.com/.*repodata* 10 20% 60
refresh_pattern . 0 20% 4320

Managing 1,500 SUSE Linux Enterprise Desktop Subscriptions with a Free Tool

Today, Novell IS&T is managing registrations and subscription updates for its 1,500 SUSE Linux Enterprise Desktops with a high degree of automation, using the Subscription Management Tool proxy server that’s included in every copy of SUSE Linux Enterprise 10 Service Pack 2. More than 700 SP1 users have successfully used the service to update their machines to SP2. For more information, see the Subscription Management Tool home page at


  • Figure 1

    The Subscription Management Tool for SUSE Linux Enterprise is a proxy server that mirrors Novell Customer Center and Novell Update, providing local registration, subscription management and update distribution services.

  • Figure 2


© 2014 Novell