Maintenance Window

If you work with scheduled maintenance windows, you might find it difficult to remember all the things that you need to do before, during, and after that critical downtime of the SUSE Manager Server. SUSE Manager Server related systems such as Inter-Server Synchronization Slave Servers or SUSE Manager Proxies are also affected and have to be considered.

SUSE recommends you always keep your SUSE Manager infrastructure updated. That includes servers, proxies, and build hosts. If you do not keep the SUSE Manager Server updated, you might not be able to update some parts of your environment when you need to.


This section contains a checklist for your maintenance window, with links to further information on performing each of the steps.

  1. Apply the latest updates. See upgrade:server-update.adoc.

  2. Upgrade to the latest service pack, if required. See upgrade:migrate-4x-4x.adoc.

  3. Run spacewalk-service status and check whether all required services are up and running.

For information about database schema upgrades and PostgreSQL migrations, see upgrade:db-migration.adoc.

You can install updates using your package manager. For information on using YaST, see For information on using zypper, see

By default, several update channels are configured and enabled for the SUSE Manager Server. New and updated packages will become available automatically.

To keep SUSE Manager up to date, either connect it directly to SUSE Customer Center or use Repository Management Tool (RMT). You can use RMT as a local installation source for disconnected environments.

You can check that the update channels are available on your system with this command:

zypper lr

The output will look similar to this:

Name                                                   | Enabled | GPG Check | Refresh
SLE-Module-Basesystem15-SP1-Pool                       | Yes     | (r ) Yes  | No
SLE-Module-Basesystem15-SP1-Updates                    | Yes     | (r ) Yes  | Yes
SLE-Module-Python2-15-SP1-Pool                         | Yes     | (r ) Yes  | No
SLE-Module-Python2-15-SP1-Updates                      | Yes     | (r ) Yes  | Yes
SLE-Product-SUSE-Manager-Server-4.0-Pool               | Yes     | (r ) Yes  | No
SLE-Product-SUSE-Manager-Server-4.0-Updates            | Yes     | (r ) Yes  | Yes
SLE-Module-SUSE-Manager-Server-4.0-Pool                | Yes     | (r ) Yes  | No
SLE-Module-SUSE-Manager-Server-4.0-Updates             | Yes     | (r ) Yes  | Yes
SLE-Module-Server-Applications15-SP1-Pool              | Yes     | (r ) Yes  | No
SLE-Module-Server-Applications15-SP1-Updates           | Yes     | (r ) Yes  | Yes
SLE-Module-Web-Scripting15-SP1-Pool                    | Yes     | (r ) Yes  | No
SLE-Module-Web-Scripting15-SP1-Updates                 | Yes     | (r ) Yes  | Yes

SUSE Manager releases maintenance updates (MUs) to provide newer packages. Maintenance updates are indicated with a new version number. For example, the major release 4.0 will be incremented to 4.0.1 when an MU is released.

You can verify which version you are running by looking at the bottom of the navigation bar in the Web UI. You can also fetch the version number with the api.getVersion() XMLRPC API call.

Refreshing Client Tools After Server Update

When the server is updated consider to update some tools on the clients, too. Updating salt-minion, zypper, and other related management package on clients is not a strict requirement, but it is a best practice in general. For example, a maintenance update on the server might introduce a major new Salt version. Then minions will continue to work but might experience problems later on. To avoid this always update the salt-minion package when available. SUSE makes sure that salt-minion can always be updated safely.

Inter-Server Synchronization Slave Server

Inter-server synchronization slave servers should be updated as soon as the update of the main server (master server) is completed.


Proxies should be updated as soon as Server updates are complete. In general, running a Proxy connected to a Server on a different version is not supported. The only exception is for the duration of updates where it is expected that the Server is updated first, so the Proxy could run the previous version temporarily. Especially in a version 3.2 to 4.0 migration you should upgrade the server first, then any proxy. For more information, see upgrade:proxy-update.adoc and upgrade:proxy-migration.adoc.