|Applies To||RSA Product Set: Identity Management and Governance|
RSA Product/Service Type: Appliance
RSA Version/Condition: ALL
|Issue||Customer has been testing on newer version of the IMG application and is not able to continue with the upgrade, so they want to revert their (Development) server back to a previous version.|
Is this possible? - Yes, it is possible if the process outlined in this knowledge base is carefully followed.
Can they keep their newer data? - No, it is not possible for the IMG database to go 'backwards,, so they are not able to 'use' their current data in an older or previous version. They can of course make a copy of the new data for use with that new version when they are able to continue with the new version testing.
If they go back to an earlier or previous application version, it is only possible to use either the same previous version database or an even earlier version, which can then be migrated forward.
The ACM/IMG documentation states that the only method to go back to an older or lower version is to restore from backup. This knowledge base give more details on specifically what needs to be done.
|Resolution||To revert back to an earlier version of the Application Server, the following needs to be done:|
Ensure that each step completes successfully before moving on.
1) Make sure there is a backup of current database, created while the jboss Server is stopped and the Oracle database instance is restarted (to ensure all data is either committed or rolled back). This step should be done as either the Linux oracle or admin user. It is strongly recommended that the version of the application/database is included in the backup name for ease of future identification. The application database backup script, as documented, can be used. For example, if the current version is 6.9.1-P01, then a database backup could be created like this:
./AVDB_Export_AVUSER.sh -t _691-P01_May-05-2015
Ensure no error messages occurred during backup creation. Restart the Jboss server once the sucessful backup is created.
2) Make sure there is a copy of the required packages for the version that will be reverted to (and patches if necessary) on the server being restored. . Refer to the relevant pages of the Installation Guide for that version (example: pages 30-31 of the 681 Installation guide lists the required packages for that version.
3) Determine if database backup from the 'previous' version, which is now going to be installed, is available. If there is, then it needs to either:
a. match the exact version and patch that is being restored OR
b. be from an earlier version than is being restored. In this case, a database migration can be done after the database is imported.
It can extremely useful and time saving if the exact version of the database being restored, as that specific version can be installed and made ready.
4) Login as the Linux root user and uninstall the existing version, by executing the uninstall.sh script found in /tmp/aveksa/staging/deploy/uninstall.sh.
5) Log out and log back in, as the root user, to ensure that no environment variables are 'lingering' from the previous installation.
6) Remove the existing version staging files by changing directory to /tmp/aveksa/staging and do a 'rm -rf *' command.
Alternatively, the staging directory can be renamed. for example, if version 691 had been installed, the /tmp/aveksa/staging directory could be renamed to /tmp/aveksa/691_staging
7) Determine the location of the packages for the older version that will be installed and extract them using the command outlined in the Installation guide for that version.
If the staging directory had been renamed, a new staging diretory will need to be created. If the existing directory will be used, then change direcotry to that location and extract the files for the version that is to be installed. The tar command typically used, will be in the format of: 'tar -jxvf /tmp/aveksa/<packages-location>/aveksa-<product version>.tar.bz2. Remember the packages location name, in the event it is not the default of /tmp/aveksa/packages, as this location is needed when the install.sh script is executed.
8) Execute 'install.sh', found in /tmp/aveksa/staging, and respond to the prompts for installing the 'new' version.
9) Upon successful installation, access the application UI as AveksaAdmin, remember that this is a 'new installation' and will have the 'new' default password which needs to be changed. Confirm application version upon successful login. Logout of the application.
**10) Optional - If a previous database is going to be restored, ensure that the version of that database is noted and if that database had had a previous patch applied, make sure that the appropriate patch is also installed onto the server before the import is done. If the database is from an even earlier version, then it can be imported and will then need to be migrated to the now restored application version.
** 11) Optional - Import the database identified in step #3, by ensuring that a copy of the .dmp is moved or copied to /home/oracle/AveksaExportImportDir (if it's not allready there). Ensure that jboss server is stopped before the import is started. Ensure that all steps of the import complete, not just the datapump portion. Upon successful completion, start the jboss server and log into the application UI and confirm the version and that the expected data is there.