Upgrade

Upgrade and migration

Riversoft® STCP Gemini components are distributed as RPM packages in the Riversoft repository and are upgraded with the system package manager, dnf or yum. Each component is a package and can be upgraded separately:

Component	Package
Riversoft STCP Gemini API	`stcpgemini-api`
Riversoft Console Portal	`stcpgemini-portal`
Riversoft STCP Gemini Server	`stcpgemini-server`

Best practices

Read the release notes of every version between the installed one and the target. They describe behavior changes, new parameters and specific procedures.
Upgrade a staging environment first and repeat the tests of critical flows before upgrading production.
Plan a maintenance window and notify partners when transfers will be unavailable.
Back up the configuration and the databases before each upgrade.
Upgrade to one target version at a time and keep the same version on every server in the environment.
Record the previous version of each package so you can roll back.

Before upgrading

Survey

Record the installed versions:

rpm -q stcpgemini-api stcpgemini-portal stcpgemini-server

Check the versions available in the repository:

dnf makecache
dnf list --showduplicates stcpgemini-api stcpgemini-portal stcpgemini-server

Identify transfers in progress and schedules due during the maintenance window.
Define who is responsible for the change and the rollback plan.

Backup

Component configuration files:

Component	File
Riversoft STCP Gemini API	`/usr/local/stcpgemini-api/configs/config.json`
Riversoft Console Portal	`/usr/local/stcpgemini-api/portal/app/configs/config.json`
Riversoft STCP Gemini Server	`/usr/local/stcp/configs/stcpserver.config.json`

Configuration database and log database, according to the organization’s backup policies.
Certificates, keys and licenses used by the components.

Upgrade procedure

Stop the services

Stop Riversoft STCP Gemini Server before the API:

systemctl stop stcpgemini-server
systemctl stop stcpgemini-api

Upgrade the packages

Refresh the repository metadata and upgrade the packages of the components installed on the server:

dnf clean all
dnf makecache
dnf upgrade stcpgemini-api stcpgemini-portal stcpgemini-server

To upgrade to a specific version, add the version to the package name, for example dnf upgrade stcpgemini-server-6.6.18.

Review the configuration

The configuration files in use are not replaced by the upgrade. Compare them with the templates (example-*.json) of the new version to identify new or changed parameters, as described in the release notes. If the package manager creates files with the .rpmnew extension, compare them with the files in use:

find /usr/local/stcpgemini-api /usr/local/stcp -name "*.rpmnew"

Update the database, when required

When the new version requires database changes, the release notes list the scripts and the order in which to run them. Run them with the DBA team, as in database preparation.

Start the services

Start the API before the Server and confirm both are running:

systemctl start stcpgemini-api
systemctl start stcpgemini-server
systemctl status stcpgemini-api stcpgemini-server

Note

When Riversoft STCP DirectLink uses the same Riversoft STCP Gemini API and Riversoft Console Portal, upgrade the API and the Portal first and then each product, checking version compatibility in the release notes.

Post-upgrade validation

rpm -q shows the target version of each package.
systemctl status shows running for the API and the Server.
The Riversoft Console Portal opens and accepts sign-in.
The Server connects to the database and loads the instance (ApplName), with no errors in the log.
A test transfer with a partner completes in both directions.
Schedules run.

Rollback

If validation fails and the cause cannot be fixed within the maintenance window:

Stop the services.
Return the packages to the previous version recorded before the upgrade:
```
dnf downgrade stcpgemini-server-<previous-version>
```
You can also undo the whole transaction with dnf history undo <id>, where <id> is the transaction identifier shown by dnf history. With yum, use yum downgrade and yum history undo.
Restore the configuration files from the backup.
If database scripts were run, restore the database backup.
Start the services and repeat the validation.

Important

Rollback depends on the previous version still being available in the repository and on backups of the files and databases taken before the upgrade.

Migration between major versions

When a version requires migration, with changes to the database structure, parameters or component behavior, the specific procedure is published in the release notes. Follow that procedure instead of the simple upgrade described on this page.

Installation Security