Secure Your WorkforceSecure Your CustomersAPI ReferenceEnd User GuideSupport

Upgrading from 6.14 to 6.15

Notable Configuration Changes
Extension API Changes
Upgrade Process

Notable Configuration Changes

DB Ids

  • We are using auto increment id generation for primary keys. This can break when we are replicating between multiple DB masters.
  • Change PKs to be based on UUIDs generated by the application. This removes issues arising from auto increment
  • When starting the 6.15.x server for the first time, DB schema changes will be automatically executed to improve scalability and support for multi-node systems

API tokens moved to the DB

The tokens will be stored in the DB going forward. API tokens will use the same general mechanism used by the Endpoint tokens. These will have a scope of API. Tokens are stored in the rp_endpoint_api_token table. At runtime they will be cached in Java memory.

New tokens are always created in the DB. These will get replicated by usual means and replicate through the DB (and app) cluster

When an existing Vault token is used or renewed - we take that opportunity to automatically and transparently

  • move the token to the DB
  • remove it from Vault

From that point forward, this token is considered to be migrated. The change is transparent to the API token consumer, like Keycloak.

How do I know if all the tokens are migrated?

When the Access Tokens UI is loaded in CC, the following is logged:

CompositeTokenService.listTokens(49) : vaultTokenCount=0, dbTokenCount=0, rpAppId=delete615webApp, scope=API

Once all tokens are migrated, the vaultTokenCount goes to 0

Token format change

Starting with this change, the DB generated tokens are prefixed with hyp. That differentiates them from the legacy Vault tokens. Note that the tokens migrated from Vault to DB will retain the original token name and token identifier

Upgrade Process

On Master Node
On Each Worker Node
Post Install

❗️

Before You Start

Please make a full backup of the database before upgrading. If you run into issues, you can restore from the backup.

On Master Node

Step 1
Back up the current <install dir> by making a copy to <install dir>-copy

Step 2
Shut down dependencies and services:

./stopHyprDependencies.sh
./stopHyprServices.sh

Step 3
Switch to the <install dir> and remove the existing WAR files:

rm -f CC/CC-*.jar

Step 4
Un-tar the new <install pkg> (ServerInstaller-*.tar.gz) in the current <install dir>

# Un-tar install pkg, overlay on existing
# Do not overwrite the nginx certs (hyprServer.crt, hyprServer.key)
# HYPR_GROUP:HYPR_USER. The should match the values defined in env.sh 

tar -xvf <install pkg> -C /opt/hypr/<install dir> --group=<HYPR_GROUP> --owner=<HYPR_USER> --exclude="hyprServer*"

This will:

  • replace the scripts in the <install dir> with the new versions
  • replace the WAR/JAR files for relevant components
  • leave the existing config in (mysql/mysql-8.0.18-linux-x86_64-minimal redis/redis-4.0.13 vault/vault-0.10.3) untouched

Step 5
Restore the envOverrides.sh file from the copy made in Step 1.

Step 6
Start dependencies as normal and start services with the reinit-vault flag:

./startHyprServices --[cluster|single] --rp --enc

You should see the following in the output:

✅  Java version 11 available
Generating /opt/hypr/CC/controlCenterConfigV68Plus.properties
...
✅ Finished writing to vault
...
**** Starting CC service. 
...
✅  Port 8009 is listening

Step 8
Reinstall the systemd services. Since UAF is gone, the systemd start order has to be modified:

cd <install folder>;

# Remove
systemdRemove.sh

# Re-install 
systemdInstall.sh

On Each Worker Node

Repeat Steps 1-4 from above.

Post Install

  • Reapply your License via the Control Center UI
  • Reapply Proxy and SSL Pinning settings via the Control Center UI, if you are using these

Updated about 2 years ago