Upgrading Subscription Management Tool from version 1.0 to 1.1


The goal of this document is to walk the reader through the process of upgrading a Subscription Management Tool (SMT) 1.0 server to version 1.1.

It also provides precautionary measures to ensure panic-free and timely recovery in case something should wrong during the upgrade.

Note: Upgrading SMT is not officially supported by Novell. The reason is that upgrade functionality was not a requirement during the design phase of version 1.1. That being said, if the steps outlined in this document are followed strictly, then upgrading has proven to work.

The upgrade can be divided into three parts:

  • Pre upgrade tasks
  • Operating system upgrade to SLES 11 and installation of SMT 1.1
  • Post upgrade tasks

Pre upgrade tasks
A normal rule is to ensure to have a usable backup of the complete system.
Besides that it is recommended to create easily-accessible copies of the data mentioned in the following steps, which should all be performed while being authenticated as the root user.

  • To back up the server certificate and be able to create a new server certificate when it expires, the easiest way is to create a copy of /var/lib/CAM/*
  • Record the IP address, DNS and routing configuration of the server in a file.
  • Create a copy of the following:
    • If special configuration of apache2 has been done, then make a copy of the modified files (e.g. /etc/apache2/default-server.conf)
    • /etc/smt.conf
    • /etc/smt.d/*
  • Stop the SMT services:
    # rcsmt stop
  • Create a backup of the SMT database.
    # mysqldump -uroot -p<mysql-root-user-password> smt > <some-directory>/smt-db-backup.sql
  • Depending on factors like :
    • the amount of repository data mirrored
    • backup capacity and costs
    • internet bandwidth constraints
    • requirements for SMT service restoration

    it might or might not be feasible to back up the repository structure (repo/), which is located in the directory specified in the MirrorTo parameter in /etc/smt.conf.

  • By default this means /srv/www/htdocs/repo/ and everything below
  • When all the files above have been stored on a removable media (and this has been removed from the server), the upgrade can start.
    Operating system upgrade to SLES 11 and installation of SMT 1.1

    It is recommended to upgrade the server by booting from the SLES 11 installation medium rather than performing an online upgrade of the server.

    • Start the installation and proceed to the Installation Mode dialog.
    • Select Update and check the “Include Add-On Products from Separate Media” box before clicking Next.
    • Select the appropriate system to update in the Select for Update dialog
    • Click Next in the Previously Used Repositories dialog
    • In the Media Type dialog, select the applicable media type and continue entering the installation source information data for SMT 1.1.
    • Accept the SMT license agreement and click Next in the Add-On Product Installation dialog.
    • Kick off the upgrade by selecting Update in the Installation Settings dialog.
    • Agree to prompts as they appear.
    • …wait…
    • Select Yes to Test Internet Connection, Next and Next to the (hopefully successful) results.
    • In the Novell Customer Center (NCC) Configuration dialog, check the Registration Code option. In case another internal SMT server with the appropriate repositories is available, then click Advanced | Local Registration Server and enter the full URL of it – e.g. : https://smt2.mycompany.com/center/regsvc.
    • Enter the Server CA certificate location if it is non-standard. Click OK.
    • Click Next when back at the NCC Configuration dialog.
    • Enter data as required and once the NCC configuration is completed, click Details to verify that the SLE11-SMT-Updates and SLES11-Updates repositories has been enabled.
    • Click OK and run through the complete online update process including the reboot.
    • When the installation workflow has completed, authenticate as root. If an error about loading OAFIID:TomboyApplet appers, then delete it.

    Post installation configuration tasks

    • Main configuration file fixup.
      • The upgrade workflow creates the file /etc/smt.conf.rpmnew. This file contains the default parameters for SMT 1.1. Since the /etc/smt.conf file from version 1.0 does not contain these parameters, it is recommended to transfer the non-default configuration settings from /etc/smt.conf to /etc/smt.conf.rpmnew.

        Typically this would be the values for the parameters:


        Settings in the YOU9-* sections in case SLE 9 mirroring is configured

      • When the relevant parameters have been entered in /etc/smt.conf.rpmnew, rename the files and restart the SMT service like this:
        # rcsmt stop
        # mv /etc/smt.conf /etc/smt.conf.old
        # mv /etc/smt.conf.rpmnew /etc/smt.conf
        # rcsmt start
    • In case changes have been made to the configuration files in /etc/smt.d/ the old ones will be saved as *.rpmsave. The novell.com-smt.rpmsave will always be created, since the scheduling of cron jobs has changed in the new version.

      For instance if extra parameters have been added to the regular SMT jobs, they are saved in /etc/smt.d/smt-cron.conf.rpmsave.

      • Transfer the desired settings from the .rpmsave files to the live files.
      • In case the novell.com-smt file has been modified, then restart the cron daemon:
        # rccron restart
    • Kick off a mirror job to fix up the database:
      # smt-mirror -d -L /var/log/smt/smt-mirror.log &
    • In SMT 1.1 a patchstatus job is automatically created whenever a client registers with the server. This job is executed when the smt-client package has been installed on the SLE 11 clients and reports information back to the SMT server about if all available patches have been installed. The next time the clients register (cron-initiated once a month for SLE 11) such a job will be created
      To eliminate the need to wait for the re-registrations to occur the following script can be used to immediately create patchstatus jobs for all registered SLES and SLED 11 clients.

      Simply create a file on the server with the contents below and execute it.

    # Create patchstatus jobs for all registered SLES and SLED 11 clients.
    TEMPFILE=/tmp/`basename $0`.$$
    smt-list-registrations > $TEMPFILE
    while read LINE ; do
      if echo $LINE | grep -E "SUSE_SLES 11|SUSE_SLED 11" >/dev/null 2>&1 ; then
        UNIQUE_ID=`echo $LINE | awk '{FS="|"}{print $2}'`
        HOST=`echo $LINE | awk '{FS="|"}{print $4}'`
        # Check if a patchstatus job for this client already
        # exists for the device before creating one
        if ! smt-job -l -g $UNIQUE_ID|grep Patchstatus >/dev/null 2>&1 ; then
          echo "Creating job for client $UNIQUE_ID - hostname $HOST"
          smt-job -c -t patchstatus -g $UNIQUE_ID
    done < "$TEMPFILE"
    rm $TEMPFILE

    At this point the upgrade is completed and SMT service is available to the clients without requiring any further action on their side.

    There is a number of new cool features added to SMT 1.1. Please refer to the SMT 11 deployment guide to check them out.

    In the unlikely event the upgrade should fail and the server needs to be reinstalled from scratch, the information saved during the preparation can be used to get the server smoothly back in business.

    Refer to TID 7004986 for detailed instructions on how to do that.

    (Visited 2 times, 1 visits today)

    Leave a Reply

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

    No comments yet

    Avatar photo