SUSE Linux Enterprise Desktop 설명서 › SMT Guide › Advanced Topics
ContentsContents
Subscription Management Tool for SLES 12 SP2
  1. About This Guide
  2. 1 SMT Installation
  3. 2 SMT Server Configuration
  4. 3 Mirroring Repositories on the SMT Server
  5. 4 Managing Repositories with YaST SMT Server Management
  6. 5 Managing Client Machines with SMT
  7. 6 SMT Reports
  8. 7 SMT Tools and Configuration Files
  9. 8 Configuring Clients to Use SMT
  10. 9 Advanced Topics
  11. A SMT REST API
  12. B Documentation Updates
Navigation←→
SUSE Linux Enterprise Desktop 설명서 › SMT Guide › Advanced Topics
Top
←→
Applies to SUSE Linux Enterprise Desktop 12 SP2

9 Advanced Topics

9.1 Backup of the SMT Server
9.2 Disconnected SMT Servers

This chapter introduces topics that will give you more control over your SMT server, but are beyond the usual workflow.

9.1 Backup of the SMT Server

Creating backups of the SMT server regularly can help restore it quickly and reliably if the server fails.

There are three main areas on the SMT server to back up:

  • Configuration files

  • Package repositories

  • The database

9.1.1 Configuration Files and Repositories

The SMT server configuration is stored in the /etc/smt.conf file and files in the /etc/smt.d directory.

As SMT depends on the services provided by the Apache Web server and Maria DB database engine, you need to back up their configuration files as well. Apache's configuration files are located in the /etc/apache2 directory, while the configuration files for Maria DB are /etc/my.cnf, /etc/mysqlaccess.conf, and files in the /etc/my.cnf.d directory.

Package repositories are stored in the /srv/www/htdocs/repo directory. Although you can normally mirror the repositories on the restored server from the update server as well, the download can take a long time. Therefore backing up the repositories saves you time and bandwidth. Furthermore, backing up the repositories is necessary if you are using repository staging and want to restore the snapshots of the repositories (see Section 3.6, “Testing and Filtering Update Repositories with Staging”).

Warning
Warning: Size of the Repositories

The size of the software repositories can be huge and you will need to transfer them from the update server.

Use your preferred tool to back up the configuration and repository files.

9.1.2 The Database

SMT uses the Maria DB database to store information about clients, registrations, machine data, which repositories are enabled for mirroring, or custom repositories. Unlike the configuration files and repositories, the database information cannot be recovered without a valid backup.

To back up the SMT database, you can for example create a cron job that performs an SQL dump into a plain text file: 

mysqldump -u root -p smt_db_password smt > /backup_dir/smt-db-backup.sql

Then include the resulting file to your normal backup jobs.

9.2 Disconnected SMT Servers

In some restricted environments it is not possible for SMT servers to access the Internet because they are located in disconnected or isolated networks. By using some special parameters on the SMT commands and a mobile disk, it is possible to accommodate for this.

You need to have one external SMT server that mirrors the repositories from SUSE Customer Center. Then you can 'mirror' these repositories to the SMT servers on the isolated network using the mobile storage medium.

SMT Disconnected Setup
Figure 9.1: SMT Disconnected Setup

Although the initial setup of this solution requires additional configuration, the regular update synchronization with SUSE Customer Center and distribution to isolated servers is simple. The steps required during the initial setup consist of:

  • Installation and configuration of the external SMT server.

  • Installation of the internal server.

  • Modification of /etc/smt.conf and cron setup on the internal SMT server.

  • Copying of the SUSE Customer Center data on the external SMT server and importing it to the internal one.

  • Enabling and disabling of repositories on the internal server.

  • Creation of an SMT database replacement file (which can be used instead of the normal Maria DB database when performing the mirror jobs) on the internal server.

Day-to-day operation includes:

  • On the external server run the smt-mirror job based on the database replacement file that writes to the mobile disk.

  • Synchronization of the mirrored repositories from the mobile disk to the internal SMT server.

A detailed description of the individual steps follows:

Procedure 9.1: External SMT Server Configuration for the Disconnected Setup

  1. Install and configure SMT as described in Chapter 1, SMT Installation.

  2. Enable the repositories to be consumed by the internal SMT servers.

  3. Perform a normal repository mirroring from SUSE Customer Center with smt-mirror.

  4. Attach a removable disk to the server and mount it.

  5. Export the required SUSE Customer Center data to a directory on the mounted removable disk:

    1. Create the directory with proper permissions to hold the data. Because the smt commands run as the smt user (whose numeric UID can differ between the servers), we need to make the permissions for the directories on the mobile disk less restrictive: 

      chmod o+w /path/to/scc/dir/on/mobile/disk

    2. Export the SUSE Customer Center data: 

      smt-sync --todir /path/to/scc/dir/on/mobile/disk

  6. Set up a directory with proper permissions: 

    mkdir /path/to/repository/on/mobile/disk
chmod o+w /path/to/repository/on/mobile/disk

  7. Unmount and detach the removable disk.

Procedure 9.2: Internal SMT Server Configuration for the Disconnected Setup

  1. Ensure you have a working SUSE Linux Enterprise Server installation source.

  2. Install SMT the same way as on the external server with the following exceptions:

    1. Select Generate new SCC credentials in the SCC Credentials dialog.

    2. Ignore the error message when running the synchronization script in the Writing SMT Configuration phase of the wizard.

    3. Abort the SUSE Customer Center Configuration wizard and then click OK in the list of installed add-on products.

  3. Re-launch the YaST Subscription Management Tool Server Configuration module (yast2 smt-server), and go to the Scheduled SMT Jobs tab.

  4. Delete "SCC Registration" and "Synchronization of Updates" jobs.

  5. Click OK to finish the wizard, provide the SMT user password, and acknowledge the synchronization error again.

  6. Prevent registration data upstream synchronization to SUSE Customer Center by setting 

    forwardRegistration = false

    in /etc/smt.conf.

  7. Connect the mobile disk and mount it.

  8. Populate the SMT database with the SUSE Customer Center data previously created: 

    smt-sync --fromdir /path/to/scc/dir/on/mobile/disk

  9. Enable mirroring of the desired repositories with smt-repos -e.

  10. Create a database replacement file on the mobile hard disk: 

    smt-sync --createdbreplacementfile /path/to/dbrepl/file/on/mobile/disk

  11. Unmount and detach the removable disk.

Now the configuration of both the external and internal SMT servers is complete. However, the update repository is still empty. After you run the following daily operation routines for the first time, the repository will get synchronized, and the internal SMT server will be ready to serve clients.

Procedure 9.3: Daily External SMT Server Operation

  1. Connect the mobile disk and mount it.

  2. Perform a mirror to a directory on the mobile disk based on the file on the mobile disk: 

    smt-mirror --dbreplfile /path/to/dbrepl/file/on/mobile/disk \
 --fromlocalsmt --directory /path/to/repository/on/mobile/disk \
 -L /var/log/smt/smt-mirror-example.log

  3. Update the database on the mobile disk with the product and subscription info from SUSE Customer Center: 

    smt-sync --todir /path/to/scc/dir/on/mobile/disk

  4. Optionally, scan the mobile disk for viruses and/or other unwanted content.

  5. Unmount and disconnect the mobile disk.

Procedure 9.4: Daily Internal SMT Server Operation

  1. Connect the mobile disk and mount it.

  2. Update the SUSE Customer Center data on the server: 

    smt-sync --fromdir /path/to/scc/dir/on/mobile/disk

  3. Mirror from the mobile disk to the server: 

    smt-mirror --fromdir /path/to/repository/on/mobile/disk

  4. Update the SUSE Customer Center data on the mobile disk with local changes in the mirror status since the last synchronization: 

    smt-sync --createdbreplacementfile /path/to/dbrepl/file/on/mobile/disk

  5. Unmount and disconnect the mobile disk.

→Appendix A SMT REST API←Chapter 8 Configuring Clients to Use SMT
Print this page

© 2016 SUSE