Applies to SUSE Linux Enterprise Server 12 SP5

10 Advanced Topics #

This chapter covers usage scenarios beyond the regular workflow to give you more control over your SMT server.

10.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 parts on the SMT server to back up:

Configuration files
Package repositories
The database

10.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 MariaDB database engine, you need to back up their configuration files as well. Apache configuration files are located in the /etc/apache2 directory, while configuration of MariaDB is stored in /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. While 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 can save you time and bandwidth. Moreover, backing up the repositories is necessary if you are using repository staging and want to restore the snapshots of the repositories (see Section 4.6, “Testing and Filtering Update Repositories with Staging”).

Warning: Size of the Repositories

The software repositories can be significant in size, and you will need to transfer them from the update server.

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

10.1.2 The Database #

SMT uses the MariaDB database to store information about clients, registrations, machine data, which repositories are enabled for mirroring, and 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 add the resulting file to your regular backup jobs.

10.2 Disconnected SMT Servers #

In some restricted environments it is not possible for SMT servers to access the Internet because they are located on disconnected or isolated networks. In this case, you can back up the relevant data on an external storage device using special parameters with the SMT commands.

You need an external SMT server that mirrors the repositories from SUSE Customer Center. Then you can transfer these repositories to the SMT servers on the isolated network using the external storage device.

Figure 10.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 are as follows:

Installing and configuring the external SMT server
Installing the internal server
Editing /etc/smt.conf and setting up a cron job on the internal SMT server
Transferring the SUSE Customer Center data from the external SMT server to the internal server
Enabling and disabling repositories on the internal server
Creating an SMT database replacement file on the internal server—when performing mirror jobs, this file can be used instead of the normal MariaDB database

Day-to-day operation requires the following actions:

Running the smt-mirror job on the external server
Synchronizing the mirrored repositories from the external storage device to the internal SMT server

Below is a detailed description of the individual steps.

Procedure 10.1: External SMT Server Configuration for the Disconnected Setup #

Install and configure SMT as described in Chapter 2, SMT Installation.
Enable the repositories for use by the internal SMT servers.
Perform a standard repository mirroring from SUSE Customer Center with smt-mirror.
Attach a removable storage device to the server and mount it.
Export the required SUSE Customer Center data to a directory on the mounted storage device:
1. Create a directory with correct permissions for storing the data. Because the smt commands run as the smt user (whose numeric UID can differ between the servers), you need to make permissions for the directories on the external storage device less restrictive:
```
chmod o+w /path/to/scc/dir/on/storage/device
```
2. Export the SUSE Customer Center data:
```
smt-sync --todir /path/to/scc/dir/on/storage/device
```

Create a directory with correct permissions:

mkdir /path/to/repository/on/storage/device
chmod o+w /path/to/repository/on/storage/device

Unmount and detach the storage device.

Procedure 10.2: Internal SMT Server Configuration for the Disconnected Setup #

Ensure you have a working SUSE Linux Enterprise Server installation source.
Install SMT the same way as on the external server with the following exceptions:
1. Start the SMT Wizard:
```
tux > sudo yast2 smt-wizard
```
  The first step of the wizard shows the Customer Center Configuration.
2. In the User and Password text boxes, enter random strings (the boxes must not be left empty).
3. Set up the database, SSL certificate and everything else as you would normally do.
4. Finish the SUSE Customer Center Configuration wizard.
5. In the final step of the wizard, Writing SMT Configuration, ignore the following error message:
```
Running the synchronization script failed
```
Re-launch the YaST Subscription Management Tool Server Configuration module (yast2 smt-server) and go to the Scheduled SMT Jobs tab.
Delete SCC Registration and Synchronization of Updates jobs.
Click OK to finish the wizard, provide the SMT user password, and acknowledge the synchronization error again.
Prevent registration data upstream synchronization to SUSE Customer Center by setting
```
forwardRegistration = false
```
in /etc/smt.conf.
Connect an external storage device and mount it.
Populate the SMT database with the previously created SUSE Customer Center data:
```
smt-sync --fromdir /path/to/scc/dir/on/mobile/disk
```
Enable mirroring of the desired repositories using the smt-repos -e command.

Create a database replacement file on the external storage device:

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

Unmount and detach the storage device.

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 be synchronized, and the internal SMT server will be ready to serve clients.

Procedure 10.3: Daily External SMT Server Operation #

Connect an external storage device and mount it.

Perform a mirror to a directory on the storage device based on the file stored on it:

smt-mirror --dbreplfile /path/to/dbrepl/file/on/storage/device/filename.xml \
 --fromlocalsmt --directory /path/to/repository/on/storage/device \
 -L /var/log/smt/smt-mirror-example.log

Update the database on the storage device with the product and subscription info from SUSE Customer Center:
```
smt-sync --todir /path/to/scc/dir/on/storage/device
```
Optionally, scan the storage device for viruses and other unwanted content.
Unmount and disconnect the storage device.

Procedure 10.4: Daily Internal SMT Server Operation #

Connect a storage device and mount it.

Update the SUSE Customer Center data on the server:

smt-sync --fromdir /path/to/scc/dir/on/storage/device

Mirror from the storage device to the server:

smt-mirror --fromdir /path/to/repository/on/storage/device

Update the SUSE Customer Center data on the storage device with local changes in the mirror status since the last synchronization:
```
smt-sync --createdbreplacementfile /path/to/dbrepl/file/on/storage/device/filename.xml
```
Unmount and disconnect the storage device.