SUSE Manager Documentation › Best Practices › SUSE Manager Server Migration

11 SUSE Manager Server Migration

11.1 Service Pack Migration Introduction
11.2 Service Pack Migration
11.3 Upgrading PostgreSQL to Version 9.6
11.4 Updating SUSE Manager
11.5 Migrating SUSE Manager version 3.1 to 3.2
11.6 SUSE Manager Migration from Version 2.1 to Version 3

11.1 Service Pack Migration Introduction #

You can upgrade the underlying operating system and also migrate SUSE Manager server from one patch level to the other (SP migration) or from one version to the next. This works for migrating SUSE Manager server 3.0 to version 3.1, or version 3.1 to version 3.2. For migrating version 3.0 to version 3.1, see the product documentation for SUSE Manager 3.1:

https://www.suse.com/documentation/suse-manager-3/

11.2 Service Pack Migration #

SUSE Manager uses SUSE Linux Enterprise Server 12 as its underlying operating system. Therefore Service Pack migration (for example, from version 12 SP1 to 12 SP3) may be performed in the same way as a typical SLES migration.

Warning: Upgrading PostgreSQL to Version 9.6 Before Migrating to SLES12 SP3 or Later

Before migrating the underlying system to SUSE Linux Enterprise 12 SP3 or later, you must upgrade PostgreSQL to version 9.6.

The migration needs PostgreSQL 9.4 and 9.6 installed in parallel and PostgreSQL 9.4 is only available in SUSE Linux Enterprise 12 SP2. For more information, see Section 11.3, “Upgrading PostgreSQL to Version 9.6”.

SUSE offers a graphical and command line tool for upgrading to a new service pack. Comprehensive documentation for executing service pack migration scenarios is located in the SUSE Linux Enterprise Server documentation chapter https://www.suse.com/documentation/sles-12/book_sle_deployment/data/cha_update_sle.html.

11.3 Upgrading PostgreSQL to Version 9.6 #

Warning: Migrating to SLES 12 SP3

SUSE Manager Server 3.1 must not be migrated to SLES 12 SP3 or later before upgrading PostgreSQL to version 9.6.

The upgrade needs PostgreSQL 9.4 and 9.6 installed in parallel. PostgreSQL 9.4 is only available in SLES 12 SP2.

Before starting the update, prepare an up-to-date backup of your database.

On existing installations of SUSE Manager Server 3.1 you must migrate from PostgreSQL 9.4 to version 9.6.

/usr/lib/susemanager/bin/pg-migrate.sh

During the upgrade your SUSE Manager Server will not be accessible.

The upgrade will create a copy of the database under /var/lib/pgsql and thus needs sufficient disk space to hold two copies (versions 9.4 and 9.6) of the database. Because it does a full copy of the database, it also needs considerable time depending on the size of the database and the I/O speed of the storage system.

If your system is short on disk space you can do a fast, in-place upgrade by running

/usr/lib/susemanager/bin/pg-migrate.sh fast

The fast upgrade usually only takes a few minutes and uses no additional disk space. However, if the upgrade fails, you will need to restore the database from a backup.

For more information, see https://wiki.microfocus.com/index.php?title=SUSE_Manager/postgresql96.

11.4 Updating SUSE Manager #

This section provides information on performing regular updates and running a spacewalk-schema-upgrade on your PostgreSQL database.

Procedure: Updating SUSE Manager #

As the root user, stop Spacewalk services:
```
spacewalk-service stop
```
Apply the latest patches:
```
zypper patch
```
You will be informed if a new database schema was included in the latest patch. Ensure the database service is running:
```
rcpostgresql start
```
Perform the upgrade:
```
spacewalk-schema-upgrade
```
Restart Spacewalk services:
```
spacewalk-service start
```
Important: Restart of Services and Applications
Services affected by a package update are not automatically restarted after an update. You need to restart these services manually to avoid potential failures.
You may use zypper ps to check for any applications which may be using old code. Restart these applications.

11.5 Migrating SUSE Manager version 3.1 to 3.2 #

The migration can either be done with the Online Migration tool (YaST) or with the Zypper command line tool.

Requirements. SUSE Manager 3.2 requires SLES 12 SP3 or later, with PostgreSQL version 9.6. Check the release notes for more information about these requirements. If you want to upgrade from an earlier version of SUSE Manager, check the relevant product documentation.

Note: Reduce Installation Size

When performing the migration, YaST will install all recommended packages. Especially in the case of custom minimal installations, this may increase the installation size of the system significantly.

To change this default behavior and allow only required packages, adjust /etc/zypp/zypp.conf and set the following variable:

solver.onlyRequires = true
installRecommends=false # or commented

This changes the behavior of all package operations, such as the installation of patches or new packages.

11.5.1 Using YaST #

Warning: Checking PostgreSQL Version

Before migrating to SLES 12 SP3 or later, check whether PostgreSQL is already updated to version 9.6. For more information, see Section 11.3, “Upgrading PostgreSQL to Version 9.6”.

To perform the migration with YaST, use the Online Migration tool:

Procedure: Migrating using YaST #

If you are logged into a GNOME session running on the machine you are going to update, switch to a text console. Running the update from within a GNOME session is not recommended. This does not apply when being logged in from a remote machine (unless you are running a VNC session with GNOME).
Start in YaSTSystem › Online Migration (yast2 migration). YaST will show possible migration targets with detailed summaries.
In case of trouble, resolve the following issues first:
- If the Online Migration is not available, install the yast2-migration package and its dependencies. Restart YaST , otherwise the newly installed module will not be shown in the control center.
- If there are “old” online updates available for installation, the migration tool will warn and ask to install them now before starting the actual migration. It is recommended to install all updates before proceeding.

11.5.2 Using zypper #

Warning: Checking PostgreSQL Version

Before migrating to SLES 12 SP3 or later, check whether PostgreSQL is already updated to version 9.6. For more information, see Section 11.3, “Upgrading PostgreSQL to Version 9.6”.

To perform the migration with Zypper on the command-line, use the zypper migration subcommand tool:

Procedure: Migrating using `zypper migration` #

If you are logged into a GNOME session running on the machine you are going to update, switch to a text console. Running the update from within a GNOME session is not recommended. This does not apply when being logged in from a remote machine (unless you are running a VNC session with GNOME).
The zypper migration subcommand show possible migration targets and a summary.
In case of trouble, resolve the following issues first:
- If the migration subcommand is not available install the zypper-migration-plugin package and its dependencies.
- If there are “old” online updates available for installation, the migration tool will warn and ask to install them now before starting the actual migration. It is recommended to install all updates before proceeding.
If more than one migration target is available for your system, select one from the list (specify the number).
Read the notification and update the SUSE Manager database schema as described (spacewalk-schema-upgrade).
Make sure SUSE Manager is up and running (spacewalk-service start).

After finishing the migration procedure SUSE Manager 3.2 on SLES 12 SP3 or later is available to be used.

11.6 SUSE Manager Migration from Version 2.1 to Version 3 #

The migration from SUSE Manager 2.1 to SUSE Manager 3 works in the same way as a migration from Red Hat Satellite to SUSE Manager. The migration happens from the original machine to a new one. There is no in-place migration. While this has the drawback that you temporarily need two machines, it also has the advantage that the original machine will remain fully functional in case something goes wrong.

Important: Migration Process

The whole process may be tricky, so it is strongly advised that the migration is done by an experienced consultant.

Given the complexity of the product, the migration is an “all-or-nothing” procedure- if something goes wrong you will need to start all over. Error handling is very limited. Nevertheless it should work more or less out of the box if all the steps are carefully executed as documented.

Note: Time-Consuming Operation

The migration involves dumping the whole database on the source machine and restoring it on the target machine. Also all of the channels and packages need to be copied to the new machine, so expect the whole migration to take several hours,

11.6.1 Prerequisites #

Warning: Latest Updates

The source machine needs to run SUSE Manager 2.1 with all the latest updates applied. Before starting the migration process, make sure that the machine is up to date and all updates have been installed sucessfully.

Only machines running with the embedded PostgreSQL database may be migrated in one go. For the migration of an Oracle based installation, a two-step migration is required: First the installation needs to get migrated from Oracle to PostgreSQL (by means of a separate tool) and afterwards the migration to SUSE Manager 3 can be performed as documented here.

SUSE Manager 3 no longer supports Novell Customer Center but only SCC (SUSE Customer Center). Therefore, you can migrate a machine only after it has been switched to SCC. The migration script will check if the installation has already been switched to SCC and will terminate if this is not the case. Switch to SCC on the source machine and repeat the migration. During migration the database from the source machine needs to get dumped and this dump needs to be temporarily stored on the target system. The dump gets compressed with gzip using the default compression options (maximum compression only yields about 10% of space savings but costs a lot of runtime); so check the disk usage of the database with:

{prompt.root}du -sch /var/lib/pgsql/data

This will ensure that you have at least 30 % of this value available in /var/spacewalk/tmp .

These values from a test migration should aid in illustrating space requirements:

suma21:/var/lib/pgsql# du -sch data
1,8G    data
1,8G    total
suma21:/var/spacewalk/tmp# ls -lh susemanager.dmp.gz
-rw-r--r-- 1 root root 506M Jan 12 14:58 susemanager.dmp.gz

This is a small test installation; for bigger installations the ratio might be better (space required for the database dump might be less than 30%). The dump will be written to the directory /var/spacewalk/tmp , the directory will be created if it does not exist yet. If you want the dump to be stored somewhere else, change the definition of the variable $TMPDIR on the beginning of the script to suit your needs.

11.6.2 Setup the Target Machine #

To prepare the target machine (with the example host name suma30) proceed as follows:

Procedure: Setup Target Machine #

On the target machine install SUSE Linux Enterprise Server 12 SP2 including the extension product “SUSE Manager” .
Important: Background Information on Required Target Machine
It is actually required to install version 12 SP2 on the target machine. On that version you will upgrade the PostgreSQL database from version_9.4 to 9.6. For more information about the PostgreSQL upgrade, see Section 11.3, “Upgrading PostgreSQL to Version 9.6”.
Initiate yast2 susemanagersetup as you would normally do for an installation of SUSE Manager.
For more information about installing SUSE Manager, see Book “Getting Started”, Chapter 2 “JeOS Installation”.
On the first SUSE Manager setup screen, ensure that Migrate a SUSE Manager compatible server › ] is marked instead of menu:Set up SUSE Manager from scratch[ .
On the second screen, enter the name of the source system as Hostname of source SUSE Manager Server as well as the domain name. Also enter the database credentials of the source system.
On the next screen, you will need to specify the IP address of the SUSE Manager 3 target system. Normally this value should be pre-set to the correct value and you only should need to press Enter . Only in the case of multiple IP addresses you might need to specify the one that should be used during migration.
Important: Faking the Host Name
During the migration process, the target system will fake its host name to be the same as the source system, this is necessary as the host name of a SUSE Manager installation is vital and should not be changed once set. Therefore do not be confused when logging in to your systems during migration; they both will present you with the same host name.
Continue by following the normal installation steps.
Important: Database Parameters
Specify the database parameters using the same database parameters as the source system is recommended. At least, using the the same database credentials as when creating the source or original SUSE Manager database is mandatory.
Enter your SCC credentials. After all the data has been gathered, YaST will terminate.

The actual migration will not start automatically but needs to be triggered manually as outlined in Section 11.6.3, “Performing the Migration”.

11.6.3 Performing the Migration #

A migration is performed by excecuting the following command:

/usr/lib/susemanager/bin/mgr-setup -m

This command reads the data gathered during Procedure: Setup Target Machine, sets up SUSE Manager onto a new target machine and transfers all of the data from the source machine. As several operations need to be performed on the source machine via SSH, you will be prompted once for the root password of the source machine. A temporary SSH key named migration-key is created and installed on the source machine, so you need to give the root password only once. The temporary SSH key will be deleted after successful migration. Ideally, this is all you will need to do.

Depending on the size of the installation, the actual migration will take up to several hours. Once finished, you will be prompted to shutdown the source machine, re-configure the network of the target machine to use the same IP address and host name as the original machine and restart it. It should now be a fully functional replacement for your previous SUSE Manager 2.1 installation. The following numbers illustrate the runtime for dumping and importing a small database:

14:53:37   Dumping remote database to /var/spacewalk/tmp/susemanager.dmp.gz on target system. Please wait...
14:58:14   Database successfully dumped. Size is: 506M
14:58:29   Importing database dump. Please wait...
15:05:11   Database dump successfully imported.

For this example dumping the database takes around five minutes to complete. Importing the dump onto the target system will take an additional seven minutes. For big installations this can take up to several hours. You should also account for the time it takes to copy all the package data to the new machine. Depending on your network infrastructure and hardware, this can also take a significant amount of time.

11.6.4 Speeding up the Migration #

A complete migration can consume a lot of time. This is caused by the amount of data that must be copied. Total migration time can be greatly decreased by eliminating the need to copy data prior to performing the migration (for example, channels, packages, auto-install images, and any additional data). You can gather all data via YaST by running the command mgr-setup -r.

Executing mgr-setup -r will copy the data from the old server to the new one. This command may be run at any time and your current server will remain fully functional. Once the migration has been initiated only data changed since running mgr-setup -r will need to be transferred which will significantly reduces downtime.

On large installations transfering the database (which involves dumping the database onto the source machine and then importing the dump onto the target system) will still take some time. During the database transfer no write operations should occur therefore the migration script will shut down any SUSE Manager database services running on the source machine.

11.6.5 Packages on External Storage #

Some installations may store the package data on external storage (for example, NFS mount on /var/spacewalk/packages ). You do not need to copy this data to the new machine. Edit the script located in /usr/lib/susemanager/bin/mgr-setup and remove the respective rsync command (located around line 345).

Important: Mounting External Storage

Make sure your external storage is mounted on the new machine before starting the system for the first time. Analogue handling for /srv/www/htdocs/pub if appropriate.

In general, all needed files and directories, not copied by the migration tool, should be copied to the new server manually.

11.6.6 Troubleshooting a Broken Web UI after Migration #

It is possible that the Web UI may break during migration. This behavior is not a bug, but a browser caching issue. The new machine has the same host name and IP address as the old machine. This duplication can confuse some Web browsers. If you experience this issue reload the page. For example, in Firefox pressing the key combination Ctrl–F5 should resume normal functionality.

11.6.7 Example Session #

This is the output of a typical migration:

suma30# /usr/lib/susemanager/bin/mgr-setup -m
  Filesystem type for /var/spacewalk is ext4 - ok.
  Open needed firewall ports...
  Migration needs to execute several commands on the remote machine.
  Please enter the root password of the remote machine.
Password:
  Remote machine is SUSE Manager
  Remote system is already migrated to SCC. Good.
  Shutting down remote spacewalk services...
  Shutting down spacewalk services...
  Stopping Taskomatic...
  Stopped Taskomatic.
  Stopping cobbler daemon: ..done

  Stopping rhn-search...
  Stopped rhn-search.
  Stopping MonitoringScout ...
  [ OK ]
  Stopping Monitoring ...
  [ OK ]
  Shutting down osa-dispatcher: ..done
  Shutting down httpd2 (waiting for all children to terminate) ..done
  Shutting down Tomcat (/usr/share/tomcat6)
  ..done
  Terminating jabberd processes...
        Stopping router ..done
        Stopping sm ..done
        Stopping c2s ..done
        Stopping s2s ..done
  Done.
  CREATE ROLE
  * Loading answer file: /root/spacewalk-answers.
  ** Database: Setting up database connection for PostgreSQL backend.
  ** Database: Populating database.
  ** Database: Skipping database population.
  * Configuring tomcat.
  * Setting up users and groups.
  ** GPG: Initializing GPG and importing key.
  * Performing initial configuration.
  * Configuring apache SSL virtual host.
  ** /etc/apache2/vhosts.d/vhost-ssl.conf has been backed up to vhost-ssl.conf-swsave
  * Configuring jabberd.
  * Creating SSL certificates.
  ** Skipping SSL certificate generation.
  * Deploying configuration files.
  * Setting up Cobbler..
  * Setting up Salt Master.
  11:26:47   Dumping remote database. Please wait...
  11:26:50   Database successfully dumped.
  Copy remote database dump to local machine...
  Delete remote database dump...
  11:26:50   Importing database dump. Please wait...
  11:28:55   Database dump successfully imported.
  Schema upgrade: [susemanager-schema-2.1.50.14-3.2.devel21] -> [susemanager-schema-3.0.5-5.1.develHead]
  Searching for upgrade path to: [susemanager-schema-3.0.5-5.1]
  Searching for upgrade path to: [susemanager-schema-3.0.5]
  Searching for upgrade path to: [susemanager-schema-3.0]
  Searching for start path:  [susemanager-schema-2.1.50.14-3.2]
  Searching for start path:  [susemanager-schema-2.1.50.14]
  The path: [susemanager-schema-2.1.50.14] -> [susemanager-schema-2.1.50.15] -> [susemanager-schema-2.1.51] -> [susemanager-schema-3.0]
  Planning to run schema upgrade with dir '/var/log/spacewalk/schema-upgrade/schema-from-20160112-112856'
  Executing spacewalk-sql, the log is in [/var/log/spacewalk/schema-upgrade/schema-from-20160112-112856-to-susemanager-schema-3.0.log].
(248/248) apply upgrade [schema-from-20160112-112856/99_9999-upgrade-end.sql]        e-suse-channels-to-public-channel-family.sql.postgresql]
  The database schema was upgraded to version [susemanager-schema-3.0.5-5.1.develHead].
  Copy files from old SUSE Manager...
  receiving incremental file list
  ./
  packages/

  sent 18 bytes  received 66 bytes  168.00 bytes/sec
  total size is 0  speedup is 0.00
  receiving incremental file list
  ./
  RHN-ORG-TRUSTED-SSL-CERT
  res.key
  rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
  suse-307E3D54.key
  suse-39DB7C82.key
  suse-9C800ACA.key
  bootstrap/
  bootstrap/bootstrap.sh
  bootstrap/client-config-overrides.txt
  bootstrap/sm-client-tools.rpm

  sent 189 bytes  received 66,701 bytes  44,593.33 bytes/sec
  total size is 72,427  speedup is 1.08
  receiving incremental file list
  ./
  .mtime
  lock
  web.ss
  config/
  config/distros.d/
  config/images.d/
  config/profiles.d/
  config/repos.d/
  config/systems.d/
  kickstarts/
  kickstarts/autoyast_sample.xml
  loaders/
  snippets/
  triggers/
  triggers/add/
  triggers/add/distro/
  triggers/add/distro/post/
  triggers/add/distro/pre/
  triggers/add/profile/
  triggers/add/profile/post/
  triggers/add/profile/pre/
  triggers/add/repo/
  triggers/add/repo/post/
  triggers/add/repo/pre/
  triggers/add/system/
  triggers/add/system/post/
  triggers/add/system/pre/
  triggers/change/
  triggers/delete/
  triggers/delete/distro/
  triggers/delete/distro/post/
  triggers/delete/distro/pre/
  triggers/delete/profile/
  triggers/delete/profile/post/
  triggers/delete/profile/pre/
  triggers/delete/repo/
  triggers/delete/repo/post/
  triggers/delete/repo/pre/
  triggers/delete/system/
  triggers/delete/system/post/
  triggers/delete/system/pre/
  triggers/install/
  triggers/install/post/
  triggers/install/pre/
  triggers/sync/
  triggers/sync/post/
  triggers/sync/pre/

  sent 262 bytes  received 3,446 bytes  7,416.00 bytes/sec
  total size is 70,742  speedup is 19.08
  receiving incremental file list
  kickstarts/
  kickstarts/snippets/
  kickstarts/snippets/default_motd
  kickstarts/snippets/keep_system_id
  kickstarts/snippets/post_delete_system
  kickstarts/snippets/post_reactivation_key
  kickstarts/snippets/redhat_register
  kickstarts/snippets/sles_no_signature_checks
  kickstarts/snippets/sles_register
  kickstarts/snippets/sles_register_script
  kickstarts/snippets/wait_for_networkmanager_script
  kickstarts/upload/
  kickstarts/wizard/

  sent 324 bytes  received 1,063 bytes  2,774.00 bytes/sec
  total size is 12,133  speedup is 8.75
  receiving incremental file list
  ssl-build/
  ssl-build/RHN-ORG-PRIVATE-SSL-KEY
  ssl-build/RHN-ORG-TRUSTED-SSL-CERT
  ssl-build/index.txt
  ssl-build/index.txt.attr
  ssl-build/latest.txt
  ssl-build/rhn-ca-openssl.cnf
  ssl-build/rhn-ca-openssl.cnf.1
  ssl-build/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
  ssl-build/rhn-org-trusted-ssl-cert-1.0-1.src.rpm
  ssl-build/serial
  ssl-build/d248/
  ssl-build/d248/latest.txt
  ssl-build/d248/rhn-org-httpd-ssl-archive-d248-1.0-1.tar
  ssl-build/d248/rhn-org-httpd-ssl-key-pair-d248-1.0-1.noarch.rpm
  ssl-build/d248/rhn-org-httpd-ssl-key-pair-d248-1.0-1.src.rpm
  ssl-build/d248/rhn-server-openssl.cnf
  ssl-build/d248/server.crt
  ssl-build/d248/server.csr
  ssl-build/d248/server.key
  ssl-build/d248/server.pem

  sent 380 bytes  received 50,377 bytes  101,514.00 bytes/sec
  total size is 90,001  speedup is 1.77
  SUSE Manager Database Control. Version 1.5.2
  Copyright (c) 2012 by SUSE Linux Products GmbH

  INFO: Database configuration has been changed.
  INFO: Wrote new general configuration. Backup as /var/lib/pgsql/data/postgresql.2016-01-12-11-29-42.conf
  INFO: Wrote new client auth configuration. Backup as /var/lib/pgsql/data/pg_hba.2016-01-12-11-29-42.conf
  INFO: New configuration has been applied.
  Database is online
  System check finished

  ============================================================================
  Migration complete.
  Please shut down the old SUSE Manager server now.
  Reboot the new server and make sure it uses the same IP address and hostname
  as the old SUSE Manager server!

  IMPORTANT: Make sure, if applicable, that your external storage is mounted
  in the new server as well as the ISO images needed for distributions before
  rebooting the new server!
  ============================================================================

Print this page

Best Practices

11 SUSE Manager Server Migration

11.1 Service Pack Migration Introduction #

11.2 Service Pack Migration #

Warning: Upgrading PostgreSQL to Version 9.6 Before Migrating to SLES12 SP3 or Later

11.3 Upgrading PostgreSQL to Version 9.6 #

Warning: Migrating to SLES 12 SP3

11.4 Updating SUSE Manager #

Procedure: Updating SUSE Manager #

Important: Restart of Services and Applications

11.5 Migrating SUSE Manager version 3.1 to 3.2 #

Note: Reduce Installation Size

11.5.1 Using YaST #

Warning: Checking PostgreSQL Version

Procedure: Migrating using YaST #

11.5.2 Using zypper #

Warning: Checking PostgreSQL Version

Procedure: Migrating using zypper migration #

11.6 SUSE Manager Migration from Version 2.1 to Version 3 #

Important: Migration Process

Note: Time-Consuming Operation

11.6.1 Prerequisites #

Warning: Latest Updates

11.6.2 Setup the Target Machine #

Procedure: Setup Target Machine #

Important: Background Information on Required Target Machine

Important: Faking the Host Name

Important: Database Parameters

11.6.3 Performing the Migration #

11.6.4 Speeding up the Migration #

11.6.5 Packages on External Storage #

Important: Mounting External Storage

11.6.6 Troubleshooting a Broken Web UI after Migration #

11.6.7 Example Session #

Procedure: Migrating using `zypper migration` #