Infrastructure Maintenance Tasks
If you work with scheduled downtime periods, 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 downtime period, with links to further information on performing each of the steps.
Apply the latest updates. See upgrade:server-intro.adoc.
Upgrade to the latest service pack, if required.
spacewalk-service statusand check whether all required services are up and running.
For information about database schema upgrades and PostgreSQL migrations, see upgrade:db-intro.adoc.
You can install updates using your package manager. For information on using YaST, see https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-onlineupdate-you.html. For information on using zypper, see https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-sw-cl.html#sec-zypper.
By default, several update channels are configured and enabled for the SUSE Manager Server. New and updated packages 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:
The output looks similar to this:
Name | Enabled | GPG Check | Refresh -------------------------------------------------------+---------+-----------+-------- SLE-Module-Basesystem15-SP2-Pool | Yes | (r ) Yes | No SLE-Module-Basesystem15-SP2-Updates | Yes | (r ) Yes | Yes SLE-Module-Python2-15-SP2-Pool | Yes | (r ) Yes | No SLE-Module-Python2-15-SP2-Updates | Yes | (r ) Yes | Yes SLE-Product-SUSE-Manager-Server-4.1-Pool | Yes | (r ) Yes | No SLE-Product-SUSE-Manager-Server-4.1-Updates | Yes | (r ) Yes | Yes SLE-Module-SUSE-Manager-Server-4.1-Pool | Yes | (r ) Yes | No SLE-Module-SUSE-Manager-Server-4.1-Updates | Yes | (r ) Yes | Yes SLE-Module-Server-Applications15-SP2-Pool | Yes | (r ) Yes | No SLE-Module-Server-Applications15-SP2-Updates | Yes | (r ) Yes | Yes SLE-Module-Web-Scripting15-SP2-Pool | Yes | (r ) Yes | No SLE-Module-Web-Scripting15-SP2-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.1 is incremented to 4.1.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.
When the server is updated consider updating some tools on the clients, too.
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 Salt clients 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.
If you are using an inter-server synchronization slave server, update it after the SUSE Manager Server update is complete.
For more in inter-server synchronization, see administration:iss.adoc.
If you are using a monitoring server for Prometheus, update it after the SUSE Manager Server update is complete.
For more information on monitoring, see administration:monitoring.adoc.
Proxies should be updated as soon as SUSE Manager 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 if you are migrating from version 4.0 to 4.1, upgrade the server first, then any proxy.
For more information, see upgrade:proxy-intro.adoc.