This chapter describes how to upgrade Oracle Communications Services Gatekeeper from version 6.1 to version 7.0. Upgrades are supported on the Linux, Solaris, and Windows operating systems.
For more information about supported operating systems, see "Services Gatekeeper System Requirements".
If you are upgrading from an release previous to 6.1, you must first upgrade to Services Gatekeeper 6.1 with patch set 3:
To upgrade from Services Gatekeeper 5.0.0.1 to 5.1, see the Services Gatekeeper Installation Guide for release 5.1.
To upgrade from Services Gatekeeper 5.1 to 6.0, see the Services Gatekeeper Multi-tier Installation Guide for release 6.0.
To upgrade from Services Gatekeeper 6.0 to 6.1, see the Services Gatekeeper Multi-tier Installation Guide for release 6.1.
https://docs.oracle.com/communications/E64613_01/doc.61/e64621/toc.htm
At this point, you have Services Gatekeeper 6.1 (with patchset 3) installed in your location. To upgrade to Services Gatekeeper 7.0, complete the tasks described in this chapter.
The following restrictions apply when upgrading Services Gatekeeper:
SIP functionality is no longer provided in Gatekeeper 7.0. If you require SIP functionality do not upgrade from 6.1.
If you are using JavaDB as your database, the database upgrade will copy the old database password. Make sure that the domain user password is the same as your 6.1 domain user password, because JavaDB will use that old password as its own.
Do not make configuration changes (such as changing Services Gatekeeper MBean attributes) during the upgrade process until all of the servers in the cluster have been upgraded. This is especially important for new configuration options. Services Gatekeeper servers ignore settings that are not understood, and the local configuration file may not be updated properly.
During the upgrade, the location of the old Services Gatekeeper installation and the location of the new Services Gatekeeper installation must be in different directories.
Set the number for processes/sessions at database level in Oracle to suit your requirements. If your Oracle database is dedicated to Services Gatekeeper only, then 500 processes are recommended. If your Oracle database is shared between Services Gatekeeper and other systems, set the number for processes to between 1000 and 2000.
For Portal analytics, your customers must re-submit the password for the Analytics server.
In addition to the placeholders described in "Placeholders Used in this Guide", Table 12-1 describes the directories and values that are specific to upgrading.
Table 12-1 Upgrade-Specific Placeholders
| Placeholder | Description |
|---|---|
|
new_Middleware_home |
The new Middleware home directory is the directory under which you install Services Gatekeeper 7.0. Middleware home is the repository for common files that are used by Oracle Communications service delivery products such as Services Gatekeeper, WebLogic Server, and Java Development Kit. |
|
new_Services_Gatekeeper_home |
The directory in which the new version of the Services Gatekeeper software is installed. By default, this is new_Middleware_home/ocsg. |
|
old_version |
The two-digit version number, without periods, of the existing Services Gatekeeper version to be upgraded. For example, 70 represents version 7.0. |
|
new_version |
The two-digit version number, without periods, of the new Services Gatekeeper version to which you are upgrading. For example, 70 represents version 7.0. |
|
new_domain_home |
The directory in which you create the new Services Gatekeeper domain. By default, this is a subdirectory of the new_Middleware_home/user_projects/domains directory. |
If you are using Oracle database as data source of Services Gatekeeper, please ignore this section.
If you are using MySQL with Oracle Linux as the database for Services Gatekeeper, then complete the steps in this section.
Set the SQL Table name identifier, lower_case_table_names, to be case insensitive when starting mysqld.
To do so:
Go to the location where my.cnf file is located. By default, my.cnf is typically located in /etc.
Open the my.cnf file at a terminal to edit it:
sudo vi $mysql/my.cnf
Locate this start of the [mysqld] section seen as:
[mysqld]
Directly below this line, add the following entry:
lower_case_table_names = 1
Save the file.
Restart mysql:
sudo /etc/init.d/mysql restart
To verify the change, run this command:
mysqladmin -u root -p variables
Oracle Communications Services Gatekeeper (OCSG), version 7.0, provides procedures to upgrade from version 6.1 to 7.0 and to roll back from 7.0 to version 6.1, if necessary.
Note:
SIP-related functionality is not supported in OCSG 7.0. If you need this functionality, you should not migrate from version 6.1.These are the summary steps to upgrade to OCSG 7.0:
Install a complete OCSG 7.0, create a new 7.0 domain, and point to a new database.
Recreate all of the domain configurations, including both OCSG and cluster-specific configurations.
Stop the old 6.1 cluster.
Migrate your data from your 6.1 database to a new 7.0 database and adjust the schema and the data, particularly your passwords.
Start a new 7.0 cluster.
The principal task in migrating from OCSG 6.1 to 7.0 is migrating from the old database to the new database. The database migration consists of these four steps, which you must complete manually:
Copy data from the old database to the new database.
Adjust the table schema in the new database to match the 7.0 definitions.
Adjust the data in the tables to match 7.0 usage.
Re-encrypt the password records in the tables to match the new domain key.
Different database types provide different solutions for copying or cloning the database and additional third-party tools can also do the job effectively. This section suggests some possible procedures.
Note:
When copying the database, the existing 6.1 cluster must be stopped.The Java database provides both online and offline tools for backup.
The SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure locks the database and performs the copy. It takes a string argument that specifies the location in which to back up the database. Typically, this is the full path to the backup directory. Relative paths are interpreted as relative to the current directory rather than relative to the derby.system.home directory.
For example, you would use the following statement to specify a backup location of c:/mybackups/2004-06-01 for the currently open database:
CALL SYSCTL_UTIL.SYSCS_BACKUP_DATABASE('c:/mybackups/2004-06-01')
Note:
Use forward slashes as the path separator in SQL commands.The SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure puts the database in a state in which you can safely copy it and then copies the entire original database directory, including data files, online transaction log files, and jar files to the backup directory. Files that are not within the original database directory, such as derby.properties, are not copied.
To make an offline copy of a Java database, you can simply copy the database directory to the destination directory. If the database size is large, Oracle recommends for efficiency to first create a zip file of the database directory and then unzip it in the destination directory.
Note:
Before making an offline copy, you must first shut down the Java database. Then copy the database directory directly.MySQL provides the commands mysqldump and mysqlimport to copy a database. You can also use the mysql command. Here are the steps:
On the MySQL command line, create a new database for the OCSG 7.0 domain.
Use the mysqldump command to dump the data from the old OCSG 6.1 database.
Use the mysql command to import data to the newly created database.
The following example illustrates:
mysqldump --host 10.182.12.146 --port 3306 -user ocsgtest --password upgrade61 > dump.sql mysql --host 10.182.12.146 --port 3306 --user ocsgtest --password upgrade70 < dump.sql
The Oracle database provides a set of tools that enable a user to clone database data. The following example uses the exp and imp commands to copy the database:
In SQL *Plus, create a new database user and password.
Grant EXP_FULL_DATABASE privilege to the OCSG 6.1 database user.
Grant CONNECT, RESOURCE, and IMP_FULL_DATABASE to the new user.
Run the exp command to export all of the data and schema information from the OCSG 6.1 database to a file.
Run the imp command to import all of the data and schema information from the exported file.
The following example illustrates:
grant EXP_FULL_DATABASE to upgrade61; grant IMP_FULL_DATABASE to upgrade70; exp upgrade61/123456 FILE=clone.dmp owner=upgrade61 imp upgrade70/123456 FILE=clone.dmp fromuser=upgrade61 touser=upgrade70
The procedure to upgrade from release 6.1 to release 7.0 makes the following assumptions:
OCSG 6.1 is installed in the directory $OCSG_61_INSTALL
The OCSG 6.1 domain is installed in the directory $DOMAIN_61_INSTALL
OCSG 7.0 is installed in the directory $OCSG_70_INSTALL
The OCSG 7.0 domain is installed in the directory $DOMAIN_70_INSTALL
If you use the Java database, the OCSG 7.0 cluster's administration server is located in the same host where the 6.1 administration server was located.
If you are using a Java database, use the following migration procedure:
On the OCSG 6.1 cluster, if you use API management, approve or reject all pending requests on the partner portal.
Install the latest Java Development Kit (JDK).
Install OCSG 7.0 in the directory $OCSG_70_INSTALL.
Note:
Because copying the database also copies the old database password, the new OCSG domain user password must be the same as for the 6.1 installation because the Java database also reuses this password.Configure the OCSG 7.0 cluster. If necessary, use the customized offline configuration.
Note:
Do not start the new OCSG 7.0 servers at this point.On the host where the administration server is located, in the directory $OCSG_70_INSTALL/ocsg/upgrade/, unzip the file migration.zip, which extracts the directory 6.1. In the directory $OCSG_70_INSTALL/ocsg/upgrade/6.1, change the mode of all shell files to make them executable.
Stop the OCSG 6.1 cluster and the Java database for the cluster.
On the host where the administration server is located, in the directory $OCSG_61_INSTALL/wlserver/common/derby, execute the following command:
cp -R gatekeeper $OCSG_70_INSTALL/wlserver/common/derby
Note:
If the database is large, you can zip and unzip the database the database to improve the efficiency of the copy.On the host where the administration server is located, in the directory $DOMAIN_70_INSTALL/bin, execute the following command to start the Java database for the 7.0 cluster:
./dbController.sh start
On the host for the administration server, in the directory $OCSG_70_INSTALL/ocsg/upgrade/6.1, run the runConfigurationMigration.sh script. It will prompt you for the following information:
OCSG 7.0 cluster's database type (oracle, mysql, or javadb). Input: "javadb"
OCSG 7.0 cluster's database host
OCSG 7.0 cluster's database port (default is 1527)
OCSG 7.0 cluster's database name. Input "gatekeeper"
OCSG 7.0 cluster's database user. Input "gatekeeper"
OCSG 7.0 cluster's database password. Input the domain administrator's password.
OCSG 6.1 domain home directory
OCSG 7.0 domain home director
When the script completes, you will see the message, "Congratulations! OCSG 6.1 migration completed successfully."
Start the OCSG 7.0 cluster.
After startup, perform customized online configuration, if any.
Extend the domain, if needed.
Migration is complete.
If you are using the Oracle database, use the following migration procedure:
On the running OCSG 6.1 cluster, if you use API management, approve or reject all of the pending requests on the partner portal.
Install the latest Java Development Kit (JDK).
Install OCSG 7.0 in the directory $OCSG_70_INSTALL and create a new 7.0 database for the installer.
Configure the OCSG 7.0 cluster and do any offline configuration, if needed.
Note:
Do not start the new OCSG 7.0 servers in this step.On the host where the administration server is located, in the directory $OCSG_70_INSTALL/ocsg/upgrade/, unzip the file migration.zip, which extracts the directory 6.1. In the directory $OCSG_70_INSTALL/ocsg/upgrade/6.1, change the mode of all shell files to make them executable.
Stop the OCSG 6.1 cluster and the Java database for the cluster.
On the host where the OCSG 6.1 database is located, copy the database. Refer to "Copying an Oracle Database" for detailed information.
On the host for the administration server, in the directory $OCSG_70_INSTALL/ocsg/upgrade/6.1, run the runConfigurationMigration.sh script to adjust the data, inputting the following information:
OCSG 7.0 cluster's database type (oracle, mysql, or javadb). Input: "oracle"
OCSG 7.0 cluster's database host
OCSG 7.0 cluster's database port
OCSG 7.0 cluster's database name
OCSG 7.0 cluster's database user
OCSG 7.0 cluster's database password. Input the domain administrator's password
OCSG 6.1 domain home directory
OCSG 7.0 domain home directory
Start the OCSG 7.0 cluster.
After startup, perform customized online configuration, if any.
Extend the domain, if needed.
Migration is complete.
If you are using a MySQL database, use the following migration procedure:
On the running OCSG 6.1 cluster, if you use API management, approve or reject all of the pending requests on the partner portal.
Install the latest Java Development Kit (JDK).
Install OCSG 7.0 in the directory $OCSG_70_INSTALL and build up the 7.0 database.
Configure the OCSG 7.0 cluster and do any offline configuration, if needed.
Note:
Do not start the new OCSG 7.0 servers in this step.On the host where the administration server is located, in the directory $OCSG_70_INSTALL/ocsg/upgrade/, unzip the file migration.zip, which extracts the directory 6.1. In the directory $OCSG_70_INSTALL/ocsg/upgrade/6.1, change the mode of all shell files to make them executable.
Stop the OCSG 6.1 cluster and the Java database for the cluster.
On the host where the OCSG 6.1 database is located, copy the database. Refer to "Copying a MySQL Database" for detailed information.
On the host for the administration server, in the directory $OCSG_70_INSTALL/ocsg/upgrade/6.1, run the runConfigurationMigration.sh script to adjust the data, inputting the following information:
OCSG 7.0 cluster's database type (oracle, mysql, or javadb). Input: "mysql"
OCSG 7.0 cluster's database host
OCSG 7.0 cluster's database port
OCSG 7.0 cluster's database name
OCSG 7.0 cluster's database user
OCSG 7.0 cluster's database password. Input the domain administrator's password
OCSG 6.1 domain home directory
OCSG 7.0 domain home directory
Start the OCSG 7.0 cluster.
After startup, perform customized online configuration, if any.
Extend the domain, if needed.
The migration is complete.
To upgrade Services Gatekeeper Reports, complete the tasks described in this section.
If you use the Services Gatekeeper API management features, and your APIs use Text-based security, you need to reset their passwords after upgrading the Services Gatekeeper software. This is required by a change to the Services Gatekeeper security requirements, so you can reset the same usernames and passwords if you want to. Start Services Gatekeeper, and open the Partner and API Management GUI.
For each API that uses Text security, set a username and password.
To upgrade Services Gatekeeper Reports:
Go to the new_Middleware_home/ocsg/applications directory.
Deploy the edr_to_analytic.ear file targeted to the Network Tier cluster.
Deploy the analytics_proxy.war file targeted to the Application Tier cluster.
For Portal analytics, your customers must re-submit the password for the analytics server.