SUSE Manager/SUMA3 Oracle

From MicroFocusInternationalWiki
Jump to: navigation, search

SUSE Manager 3 with external Oracle database

While SUSE Manager 3 only supports the postgresql database, there might be cases in the future where we need to support usage of an external Oracle database as well. Since such an installation is special in some sense, the installation is not supported by the tools shipped but requires some manual steps that will be described here.

Prerequisites

For accessing the Oracle database, the sqlplus command needs to be available. It can be downloaded directly from Oracle. You will need the following two packages:

oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm
oracle-instantclient12.1-sqlplus-12.1.0.2.0-1.x86_64.rpm

Installation

First SUSE Manager should be installed in the usual way (including the postgresql database) by installing the SUSE Manager pattern on top of a SUSE SLES12SP1 system. It is important that the latest version of all relevant packages are installed, so if the update repositories are not being used during installation, please make sure you run a zypper up with all the relevant repositories enabled to ensure that everything is up to date.

Please note: This is only about installing the system! DO NOT yet configure SUSE Manager, DO NOT run yast2 susemanager_setup

Once this is done, the postgresql specific packages need to be replaced by their oracle counterparts. This can be achieved by issuing the following command:

zypper in +spacewalk-oracle +spacewalk-java-oracle +spacewalk-backend-sql-oracle \
       -spacewalk-postgresql -spacewalk-java-postgresql -patterns-suma_server \
       -spacewalk-backend-sql-postgresql -postgresql94-contrib -postgresql-jdbc \
       -postgresql94 -postgresql-init -postgresql94-server \
       /tmp/oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm \
       /tmp/oracle-instantclient12.1-sqlplus-12.1.0.2.0-1.x86_64.rpm

Note that this command assumes that the Oracle packages with the sqlplus program are stored in the /tmp directory. If you stored them somewhere else, please adapt the path in above command accordingly.

Since there is no YaST support for this kind of installation, you need to create an answer file for the setup program manually. Use the following template and store it in ~root/setup_env.sh:

MANAGER_USER='db_user'
MANAGER_PASS='db_password'
MANAGER_ADMIN_EMAIL='suma-admin@customer.com'
CERT_O='Customer'
CERT_OU='Development'
CERT_CITY='Sample-City'
CERT_STATE='Sample-State'
CERT_COUNTRY='DE'
CERT_EMAIL='cert-admin@customer.com'
CERT_PASS='cert_password'
DB_BACKEND='oracle'
LOCAL_DB='0'
MANAGER_DB_NAME='oracle_sid'
MANAGER_DB_HOST='oracle-host.customer.com'
MANAGER_DB_PORT='1521'
MANAGER_DB_PROTOCOL='TCP'
MANAGER_ENABLE_TFTP='Y'
SCC_USER='scc_user'
SCC_PASS='scc_password'

Of course you need to replace the sample entries with your actual data. Make sure to only user upper case characters for specifying the CERT_COUNTRY value! This is very important as without YaST there is no check for this condition!

Now run the actual setup by issuing the command:

/usr/lib/susemanager/bin/mgr-setup -l /var/log/susemanager_setup.log -s

After this script has been run successfully, the SUSE Manager server is set up and ready to be used.

Migration of SUSE Manager 2.1 with external Oracle database to 3.0

Just as with postgresql, the migration of SUSE Manager 2.1 to version 3 with external Oracle database requires setting up a new machine and migrating from the source machine. Set up the new machine just the same way as for a new installation and replace the postgresql specific packages with the Oracle ones as outlined earlier in this chapter. After that, create a ~root/setup_env.sh like this:

export MANAGER_FORCE_INSTALL='0'
export SATELLITE_DB_PASS='db_password'
export SATELLITE_DB_SID='oracle_sid'
export SATELLITE_DB_USER='db_user'
export SATELLITE_DOMAIN='customer.com'
export SATELLITE_HOST='suma21'
export ACTIVATE_SLP='n'
export MANAGER_ADMIN_EMAIL='suma-admin@customer.com'
export MANAGER_IP='10.0.0.1'
export DB_BACKEND='oracle'
export MANAGER_DB_HOST='oracle-host.customer.com'
export MANAGER_DB_NAME='oracle_sid'
export MANAGER_DB_PORT='1521'
export MANAGER_DB_PROTOCOL='TCP'
export MANAGER_PASS='db_password'
export MANAGER_PASS2='db_password'
export MANAGER_USER='db_user'
export LOCAL_DB='0'
export ISS_PARENT=''
export SCC_PASS='scc_password'
export SCC_USER='scc_user'

The variable SATELLITE_HOST denotes the (old) SUSE Manager server still running 2.1, while MANAGER_IP specifies the IP address of the new server. Since the migration process needs to fake the host name of the new machine to be identical with the old server, you cannot use the correct host name here, but need to specify the IP address.

Since this migration will only work with an external Oracle database and the new server will continue to use the existing database, the credentials for the database are the same, ie. SATELLITE_DB_USER and MANAGER_USER need to be set to the same value. Same applies for MANAGER_PASS and MANAGER_DB_NAME respectively as reflected in above example.

To perform the actual migration, just issue the following command:

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

For this migration there is no need to dump and restore the existing database; so if all the package data is already transferred to the new machine, the actual migration will be very fast and take only some minutes. For details about the migration itself, please refer to the documentation about a postgresql based migration.

During the migration a schema upgrade of the database will be performed. Note that this will happen on your production system! Unlike postgresql based migrations, where the database gets duplicated, you are strongly advised to create a backup of the database before you start the migration, so you can go back in case something goes wrong (for postgresql based migrations, the original database will remain unchanged, so in case of problems you simply can dump the migrated system and the old one is still operational). If something goes wrong, dump the new system, restore the database and restart the original server. It everything works fine, shut down the old server and restart the new one, making sure it uses the same host name and IP address as the old one (same procedure as for postgresql based migrations).