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”).
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.
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 serverTransferring 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 serverSynchronizing the mirrored repositories from the external storage device to the internal SMT server
Below is a detailed description of the individual steps.
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:
Create a directory with correct permissions for storing the data. Because the
smt
commands run as thesmt
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
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.
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:
Start the
:tux >
sudo yast2 smt-wizardThe first step of the wizard shows the
.In the
and text boxes, enter random strings (the boxes must not be left empty).Set up the database, SSL certificate and everything else as you would normally do.
Finish the
wizard.In the final step of the wizard,
, 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 tab.Delete
SCC Registration
andSynchronization of Updates
jobs.Click
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.
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.
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.