Versions Compared

Old Version 41

changes.mady.by.user Keith Dwyer

Saved on

compared with

New Version 42

changes.mady.by.user Keith Dwyer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: 1.20.1 bump

In most cases, upgrading an existing instance of SHRINE is a relatively quick process. Exceptions to this rule include older versions of SHRINE that contained substantial changes to configuration files and other portions of the file structure. The instructions here specifically describe an upgrade path from SHRINE 1.1819.x to SHRINE 1.1920.x1. For instructions on upgrading to SHRINE 1.1819.x, check the child pages underneath this articlethe "Archived Upgrade Instructions" section.

If upgrading from SHRINE 1.17.x to SHRINE 1.19.x, you will need to make sure to run the database scripts listed in the "Schema Changes" section of the 1.18.x article in addition to the instructions provided in this article.

 

Table of Contents
outlinetrue
stylenone

Shut Down SHRINE

Before starting the upgrade process, make sure SHRINE's Tomcat is not running. Leaving it running during this process can cause problems. Simply run the following command:

$ shrine_shutdown

If the above command is not found, try the following instead:

$ /opt/shrine/tomcat/bin/shutdown.sh

Create Backups

Now that SHRINE is stopped, it is a good idea to back up the current versions of the components we will be upgrading. The exact method for making this backups may vary, but these instructions will place the backups in a folder called /opt/shrine/upgrade-backups.

Start by creating a folder to contain these backups:

$ mkdir /opt/shrine/upgrade-backups

Next, move the current SHRINE webapp to the backup location:

This guide makes the following assumptions of a current 1.19.2 user. Make sure all of these conditions are satisfied before proceeding:

  • i2b2 1.7.05 or newer is installed and operational.
  • SHRINE 1.19.2 is installed and operational. (along with Tomcat 7)
  • The SHRINE Data Steward included with 1.19.2 has been installed and configured properly.

Table of Contents
outlinetrue
stylenone

Shut Down SHRINE

Before starting the upgrade process, make sure SHRINE's Tomcat is not running. Leaving it running during this process can cause problems. Simply run the following command:

$ shrine_shutdown

If the above command is not found, try the following instead:

$$ mv /opt/shrine/tomcat/webapps/shrine /opt/shrine/upgrade-backups/shrine

Next, move the SHRINE webclient to that same backup location. Later on, we will be restoring i2b2_config_data.js from this backup. If you choose not to make any backups, make sure to at least keep a copy of i2b2_config_data.js and js-i2b2/cells/SHRINE/cell_config_data.js!

bin/shutdown.sh

Create Backups

Now that SHRINE is stopped, it is a good idea to back up the current versions of the components we will be upgrading. The exact method for making this backups may vary, but these instructions will place the backups in a folder called /opt/shrine/upgrade-backups.

Start by creating a folder to contain these backups:

$ mkdir /opt/shrine/upgrade-backups

Remove the old .war files with this command:

$ rm /opt/shrine/tomcat/webapps/*.war

Next, move the current SHRINE webapp folder to the backup location:

$ mv /opt/shrine/tomcat/webapps/shrine$ mv /opt/shrine/tomcat/webapps/shrine-webclient /opt/shrine/upgrade-backups/shrine-webclient

Upgrade Tomcat

If you plan to use the Data Steward application, you will need to upgrade Tomcat to version 7. Most older SHRINE installations defaulted to Tomcat 6, which is incompatible with the new Data Steward application. To ease the upgrade process, the SHRINE installer includes a script to detect the presence of Tomcat 6 and upgrade it to Tomcat 7. It will also back up your existing Tomcat installation, just in case.

Before running the upgrade script, make sure the following environment variables are set correctly:

  • SHRINE_HOME
  • SHRINE_TOMCAT_HOME
  • SHRINE_PORT
  • SHRINE_SSL_PORT
  • KEYSTORE_FILE
  • KEYSTORE_PASSWORD

Next, download the upgrade script from the SHRINE installer and run it.

$ wget https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/install/i2b2-1.7/shrine/upgrade_tomcat.sh
$ chmod +x upgrade_tomcat.sh
$ ./upgrade_tomcat.sh

The script should cleanly replace an existing Tomcat 6 installation with Tomcat 7, generating a new server.xml in the process. If you are already on Tomcat 7 (or newer), the script will exit and do nothing.

Use setenv.sh to fix "java.lang.OutOfMemoryError: PermGen space"

Depending on the version of Java you are running, you may need to create a file called setenv.sh in Tomcat's bin/ folder to increase the PermGen size given to it. If you are suddenly unable to access SHRINE and catalina.out logs multiple OutOfMemoryError messages, you should create setenv.sh, make sure it is owned by the same user that runs SHRINE, and make sure it is executable:

Code Block
titlecreating setenv.sh
$ cd /opt/shrine/tomcat/bin
$ vi setenv.sh
$ sudo chown shrine:shrine setenv.sh
$ sudo chmod 755 setenv.sh
Make sure to also back up the other existing SHRINE components (shrine-proxy and steward), just in case:
$ mv /opt/shrine/tomcat/webapps/shrine-proxy /opt/shrine/upgrade-backups/shrine-proxy
$ mv /opt/shrine/tomcat/webapps/steward /opt/shrine/upgrade-backups/steward
Make especially sure that the shrine-webclient/ folder is backed up. Later on, we will be restoring important webclient configuration files from this backup. If you choose not to make any backups, make sure to at least keep a copy of i2b2_config_data.js and js-i2b2/cells/SHRINE/cell_config_data.js!
$ mv /opt/shrine/tomcat/webapps/shrine-webclient /opt/shrine/upgrade-backups/shrine-webclient
Modify Tomcat
You will need to create a file called setenv.sh in Tomcat's bin/ folder to increase the PermGen size given to it. This will prevent OutOfMemoryError messages caused by one of the underlying application libraries. Make sure this file is owned by the same user that runs SHRINE, and make sure it is executable:
 Code Block
titlecreating setenv.sh
$ cd /opt/shrine/tomcat/bin
$ vi setenv.sh
$ sudo chown shrine:shrine setenv.sh
$ sudo chmod 755 setenv.sh
The contents of setenv.sh should look like this:
 Code Block
languagebash
titlesetenv.sh contents
export CATALINA_OPTS=" -XX:MaxPermSize=256m "
If using Windows, the file should be named setenv.bat instead, and the contents should look something The contents of setenv.sh should look like this:
 Code Block
languagebashpowershell
titlesetenv.sh bat contents
exportset CATALINA_OPTS=" -XX:MaxPermSize=256m "
Restart SHRINE to make the changes take effect.
Deploy New shrine.war
Next, we will retrieve the new SHRINE webapp from the HMS Sonatype Nexus server at http://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/shrine-war/. Choose the version that you are upgrading to (for example, 1.19.2) and navigate to that folderNavigate to the folder for 1.20.1. From there, download the appropriate download shrine-war-[VERSION]1.20.1.war file to the webapps directory  to the webapps/ directory on the SHRINE server and rename it to to shrine.war.
For example:
$ cd /opt/shrine/tomcat/webapps
$ wget --no-check-certificate http://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/shrine-war/1.1920.21/shrine-war-1.1920.21.war -O shrine.war
Deploy New 
...
steward.war
NOTE: The previous bug with the SHRINE Data Steward turning all usernames into lowercase has been fixed. Any i2b2 usernames that use both uppercase and lowercase letters will now be able to use the SHRINE Data Steward properly. However, for the sake of consistency, please continue using all lowercase letters in your usernames if they were already changed.
Much like shrine.war, the SHRINE Data Steward can be found on the HMS Sonatype Nexus server at http://repo.open.med.Like other SHRINE artifacts, the SHRINE proxy can be found on the HMS Sonatype Nexus server at https://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/shrine-proxysteward/. Navigate to the folder for 1.1920.21. From there, download the shrine-proxy-download steward-1.1920.21.war to the webapps directory  to the webapps/ directory on the SHRINE server and rename it to shrine-proxyto steward.war.
For example:
$ cd /opt/shrine/tomcat/webapps
$ wget --no-check-certificate https://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/shrine-proxysteward/1.1920.21/shrine-proxysteward-1.1920.21.war -O shrine-proxysteward.war
...
Deploy New 
...
shrine-proxy.war
Much like shrine.war, steward.war Like other SHRINE artifacts, the SHRINE proxy can be found on the HMS Sonatype Nexus server at httphttps://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/stewardshrine-proxy/. Navigate to the folder for 1.1920.21. From there, download the appropriate steward-[VERSION].war file to the webapps directory download shrine-proxy-1.20.1.war to the webapps/ directory on the SHRINE server and rename it to stewardto shrine-proxy.war.
For example:
$ cd /opt/shrine/tomcat/webapps
$ wget --no-check-certificate https://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/stewardshrine-proxy/1.1920.21/stewardshrine-proxy-1.1920.21.war -O stewardshrine-proxy.war
Deploy New SHRINE Webclient
NOTE: Installation procedures for this component have changed! Please be careful. The SHRINE webclient is now packaged as a zip file, and no longer requires a checkout from the (no-longer-used) SHRINE SVN repository.
The SHRINE webclient can now be found on the HMS Sonatype Nexus server Unlike shrine.war and steward.war, the SHRINE webclient is retrieved from the releases folder of the HMS Subversion repository at https://repo.open.med.harvard.edu/nexus/svncontent/shrinegroups/releases/. The webclient is found at [VERSION]/codepublic/net/shrine/shrine-webclient. Checkout or export this folder to /opt/shrine/tomcat/webapps./. Navigate to the folder for 1.20.1. From there, download shrine-webclient-1.20.1-dist.zip file to the webapps/ directory on the SHRINE server and rename it to shrine-webclient.zip. Then, unzip the shrine-webclient.zip file.
For example:
$ cd /opt/shrine/tomcat/webapps
$ svn export  wget --no-check-certificate https://repo.open.med.harvard.edu/svnnexus/content/groups/public/net/shrine/releasesshrine-webclient/1.1920.2/code/shrine-webclient/1/shrine-webclient-1.20.1-dist.zip -O shrine-webclient.zip
$ unzip shrine-webclient.zip
 
Restore Webclient Backups
After this, restore the previous previous i2b2_config_data.js and  and cell_config_data.js file  files from your backup and place it them in the new shrine-webclient folder:
...
$ cp /opt/shrine/upgrade-backups/shrine-webclient/js-i2b2/cells/SHRINE/cell_config_data.js /opt/shrine/tomcat/webapps/shrine-webclient/js-i2b2/cells/SHRINE/cell_config_data.js
[Optional] Configure the SHRINE Data Steward
Note that a few of these steps can be automatically done by the install-steward-only.sh script available with the SHRINE installer.
Database - i2b2
The SHRINE Data Steward is typically backed by the i2b2 PM cell used by SHRINE. From the steward application's point of view, all users on the SHRINE project are considered Researchers. However, there is some additional work that has to be done to the i2b2 user list to accommodate the SHRINE Data Steward.
NOTE: install-steward-only.sh does NOT handle this! The creation of i2b2 users/setting of user parameters must be done manually by an i2b2 administrator!
QEP User
The Steward application requires set of user credentials that it will use to submit queries through to SHRINE. It is recommended that this be a dedicated user separate from any other account. Additionally, it will need to have the parameter "qep" defined (name: qep, value: true, type: text), which can be set in the Manage Users section of the i2b2 Admin Panel.
In shrine.conf, make sure there is a shrineSteward block in the queryEntryPoint section, and that the qepUserName and qepPassword properties match the user with the qep parameter.
Steward User
In Steward application deployments that require manual topic approval, a trusted user will have to be given permission to review proposed research topics and approve/reject them. To mark a user as such, add the "DataSteward" parameter (name: DataSteward, value: true, type: text) to that user in the Manage Users section of the i2b2 Admin Panel.
Database - Steward
The SHRINE Data Steward application uses a separate database to store its logging information, similar to how the core SHRINE application keeps its own query log.
This step should be handled by install-steward-only.sh, but instructions to manually perform it can be found below:
  1. Create a database (typically stored in MySQL alongside the existing shrine_query_history database, but this is just a suggestion). The installer by default calls it stewardDB.
  2. Grant a shrine/steward-specific user full access to this database. The installer by default uses the same credentials as it does for the SHRINE query history database, but you are welcome to (and encouraged to!) change this.
  3. Run the appropriate schema script included with the steward application
    1. For MySQL, this is https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/steward/src/main/sql/mysql.ddl
    2. For SQL Server, this is https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/steward/src/main/sql/sqlserver.ddl
steward.conf - Application config
This step should be handled by install-steward-only.sh, but instructions to manually perform it can be found below:
  1. Start with a sample steward.conf from the installer: https://open.med.harvard.edu/svn/shrine/releases/1.19.2/code/install/i2b2-1.7/shrine/skel/steward.conf
    1. If using the JDBC driver, make sure slickProfileClassName is set to "scala.slick.driver.JdbcDriver$" (mind the lowercase "dbc"!)
  2. Substitute the following variables with their appropriate value. (see common.rc and shrine.rc for reference, as well as the listing of configuration variables in the installer)
    1. SHRINE_ADAPTER_I2B2_DOMAIN
    2. SHRINE_STEWARD_DB_NAME
    3. I2B2_PM_IP
    4. KEYSTORE_FILE
    5. KEYSTORE_PASSWORD
    6. KEYSTORE_ALIAS
  3. Save this file to /opt/shrine/tomcat/lib/steward.conf
An important setting in steward.conf which should be manually set by a site administrator is createTopicsMode. By default, this is set to "Pending", which means that topic requests submitted in the Data Steward application will have to be manually approved by a user with DataSteward privileges. The potential values for createTopicsMode are:
  • Pending: Topic requests must be submitted, and a user with the DataSteward parameter set for them in the i2b2 PM cell must log in and approve them manually before queries can be executed under that topic.
  • Approved: Topic requests must be submitted, but no manual approval is necessary. All topics submitted are automatically approved, and researchers can immediately begin executing queries for that topic.
  • TopicsIgnoredJustLog: No topic requests are necessary, the Data Steward application simply intercepts queries for recordkeeping and analysis. If using this mode, ensure the isSHRINE property in shrine-webclient/i2b2_config_data.js is either not present or set to false
steward.xml - Tomcat context definition
This step should also be handled by install-steward-only.sh, but instructions to manually perform it can be found below:
Deploy New SHRINE Dashboard
NOTE: This component is a working prototype, and simply mirrors information from the existing SHRINE Happy module in its current state. Additional functionality is coming in a future release.
Like other SHRINE artifacts, the SHRINE proxy can be found on the HMS Sonatype Nexus server at https://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/dashboard-war/. Navigate to the folder for 1.20.1. From there, download dashboard-war-1.20.1.war to the webapps/ directory on the SHRINE server and rename it to shrine-dashboard.war.
For example:
$ cd /opt/shrine/tomcat/webapps
$ wget --no-check-certificate https://repo.open.med.harvard.edu/nexus/content/groups/public/net/shrine/dashboard-war/1.20.1/dashboard-war-1.20.1.war -O shrine-dashboard.war
Create dashboard.conf File
A new .conf file is required for the new SHRINE Dashboard component. Its contents are relatively simple, and can be mostly copied from an existing steward.conf.
  1. Create a file named dashboard.conf in the tomcat/lib/ folder.
  2. The first line of the file should be "shrine {", and the last line of the file should be "}".
  3. In between these two lines, copy the contents of the pmEndpoint{} block from shrine.conf or steward.conf.
  4. Create an authenticate{} block, and within that block, create a usersource{} block. Within that block, there should be one variable, "domain", which should be set to the same i2b2 domain referenced in the hiveCredentials block of shrine.conf.
  5. Afterwards, copy the contents of the keystore{} block from steward.conf into this file.
  6. Save this file (of course).
dashboard.conf should look something like this:
 
 No Format
nopaneltrue
shrine {
  pmEndpoint {
    //URL for the PM Service, used to authenticate users
    url = "http://our.site.edu/i2b2/services/PMService/getServices"
  }

  authenticate {
    usersource {
      domain = "i2b2demo"
    }
  }

  keystore {
    file = "/opt/shrine/shrine.keystore"
    password = "PASSWORD"
    privateKeyAlias = "our.site.edu"
  }
}
(Optional) For Users of Oracle or SQL Server
If you experience issues in getting the SHRINE Data Steward (or the new audit logging functionality) working with Oracle or SQL Server, please try the instructions in this article written by a SHRINE developer: Using SHRINE Data Steward with Oracle or SQL Server
This article contains links to alternative database drivers, as well as links to alternative database scripts for creating tables for the SHRINE Data Steward. It also includes information on the necessary changes to make to shrine.xml, steward.xml, shrine.conf, and steward.conf.
Create Query Audit Databases
SHRINE 1.20.1 adds query audit databases, which will need to be created in order for SHRINE 1.20.1 to function.
  1. Create a database named adapterAuditDB on the same database server used for storing SHRINE query history.
  2. Download and run the schema creation script for the adapterAuditDB database, available here: https://open.med.harvard.edu/stash/projects/SHRINE/repos/shrine/browse/adapter/adapter-service/src/main/sql/mysql.ddl?at=tags/1.20.1&raw
    1. Other schema creation scripts can be found in the same folder
    3. Start with a sample steward.xml from the installer
    1. : https://open.med.harvard.edu
    4. /svn
    1. /stash/projects/SHRINE/repos/shrine/
    5. releases/1.19.2/code/install/i2b2-1.7/shrine/skel/steward.xml
  5. Substitute the following variables with their appropriate value. (see common.rc and shrine.rc for reference, as well as the listing of configuration variables in the installer)
    1. SHRINE_STEWARD_MYSQL_USER
    2. SHRINE_STEWARD_MYSQL_PASSWORD
    3. SHRINE_STEWARD_MYSQL_HOST
    4. SHRINE_STEWARD_DB_NAME
  6. Save this file to /opt/shrine/tomcat/conf/Catalina/localhost/steward.xml
SHRINE Webclient
NOTE: install-steward-only.sh does NOT handle this step!
In webapps/shrine-webclient/js-i2b2/cells/SHRINE/cell_config_data.js, make sure newTopicURL and readApprovedURL are set to something like the following:
    newTopicURL: "https://your.hostname.here:6443/steward/client/index.html#/topics",
    readApprovedURL:"https://your.hostname.here:6443/shrine/rest/i2b2/request"
If createTopicsMode in steward.conf is set to either "Approved" or "Pending", then make the following change in webapps/shrine-webclient/i2b2_config_data.js:
    isSHRINE: true
The above may already be present in i2b2_config_data.js, but commented out. (there may be a /* on the previous line) If so, uncomment it. If isSHRINE is not already present, add it to the main entry in lstDomains.
shrine.conf Changes
SHRINE Data Steward Integration
If using the SHRINE Data Steward, you will need to change the authorizationType value and add the following shrineSteward block to the queryEntryPoint block of shrine.conf:
queryEntryPoint {
  ...
  authorizationType = "shrine-steward"

  shrineSteward {
    qepUserName = "qep" // name of user the steward will submit queries as
    qepPassword = "trustme"
    stewardBaseUrl = "https://your.hostname.here:6443" // typically hostname+port of Tomcat server running steward.war
  }

  ...
}
The qepUserName and qepPassword properties should match the set of credentials used for the QEP user defined earlier.
Steward Naming Change (HMS Only)
Users on the HMS SHRINE networks will have to make a change to shrine.conf in order to accommodate a renamed property value.
In the queryEntryPoint block, change authorizationType from "data-steward" to "hms-steward":
queryEntryPoint {
  ...
  authorizationType = "hms-steward"
  ...
}
It is also worth noting that HMS users will not need to deploy or configure the new SHRINE Data Steward, so they may safely ignore steps involving the SHRINE Data Steward.
Breakdowns
In SHRINE 1.18.0+, it is now required to specify the names of result types corresponding to breakdown queries.  These names must match the names of result output types defined in the i2b2 DB of every node on your Shrine network.  For example, on a network comprised of nodes backed by i2b2 demo VMs, add this to shrine.conf:
shrine {
  ...
  breakdownResultOutputTypes {
    PATIENT_AGE_COUNT_XML {
      description = "Age patient breakdown"
    }
      
    PATIENT_RACE_COUNT_XML {
      description = "Race patient breakdown"
    }
 
    PATIENT_VITALSTATUS_COUNT_XML {
      description = "Vital Status patient breakdown"
    }
 
    PATIENT_GENDER_COUNT_XML {
      description = "Gender patient breakdown"
    }
  }
  ...
}
the format is
breakdownResultOutputTypes {
  <breakdown-result-output-type-name 0> {
    description = <string human-readable-description 0>
  }
  ...
    <breakdown-result-output-type-name N> {
    description = <string human-readable-description N>
  }
}
Note that shrine.breakdownResultOutputTypes can contain 0 or more child elements.
    1. browse/adapter/adapter-service/src/main/sql/?at=tags/1.20.1
  2. Create a database named qepAuditDB on the same database server used for storing SHRINE query history.
  3. Download and run the schema creation script for the qepAuditDB database, available here: https://open.med.harvard.edu/stash/projects/SHRINE/repos/shrine/browse/qep/service/src/main/sql/mysql.ddl?at=tags/1.20.1&raw
    1. Other schema creation scripts can be found in the same folder: https://open.med.harvard.edu/stash/projects/SHRINE/repos/shrine/browse/qep/service/src/main/sql?at=tags/1.20.1
  4. In tomcat/conf/Catalina/localhost/shrine.xml, add two new <Resource> elements for each of these new databases. You can copy and paste the lines used for shrine_query_history Resource, making sure that both the "shrineDB" part of the name attribute and the "shrine_query_history" part of the url attribute both change to "adapterAuditDB" for the first copy and "qepAuditDB" for the second copy.
Update ERROR_RESULT Table Structure
In order to accommodate improvements made to error reporting in the SHRINE webclient, additional columns have been added to the ERROR_RESULT table in the shrine_query_history database. Run the following queries on your SHRINE query history database:
 Code Block
languagesql
titlemysql -u shrine -p -D shrine_query_history
alter table ERROR_RESULT add column CODEC varchar(256) not null default "Pre-1.20 Error";
alter table ERROR_RESULT add column STAMP varchar(256) not null default "Unknown time and machine";
alter table ERROR_RESULT add column SUMMARY text not null;
alter table ERROR_RESULT add column PROBLEM_DESCRIPTION text not null;
alter table ERROR_RESULT add column DETAILS text not null;
shrine.conf Changes
(Optional) New Property - create
The hub{}, adapter{}, and queryEntryPoint{} components in shrine.conf have an additional (optional) boolean property named "create". This will enable or disable creation of that component. For example, a site that serves solely as a data source (no webclient, no querying users at their site) could disable the hub{} and queryEntryPoint{} components.
In SHRINE 1.20.1, the default value for this is true, but this is subject to change in a future release.
hub {
  ...
  create = false // this is solely an example, not a mandatory change.
  ...
}
steward.conf Changes
Change slickProfileClassName
Due to an underlying library upgrade, the names of the database drivers used for this variable have changed. If your current value for slickProfileClassName starts with "scala.", remove "scala." from it. For example, change this:
slickProfileClassName = "scala.slick.driver.MySQLDriver$"
To this:
slickProfileClassName = "slick.driver.MySQLDriver$"
Wrapper for usersource block
Surround the usersource{} block with a new block called authenticate{}. For example:
 No Format
nopaneltrue
  authenticate {
    usersource {
      domain = "i2b2demo"
    }
  }
(Optional) Increase pmEndpoint timeout
If you experience issues with the SHRINE webclient occasionally failing to retrieve a list of approved topics and are certain the SHRINE Data Steward application is otherwise functioning properly, try increasing the timeout for the SHRINE Data Steward's interactions with the i2b2 PM cell. By default, the SHRINE Data Steward will only wait 1 second for a response from i2b2. To increase this limit, add the following inside the pmEndpoint{} block:
 No Format
nopaneltrue
  pmEndpoint {
    [...]
    timeout {
      seconds = 10
    }
  }
Start SHRINE
The only thing left to do at this point is start SHRINE back up. Simply do the following:
...
$ /opt/shrine/tomcat/bin/startup.sh
Verify SHRINE Upgrade
After starting SHRINE up, verify that the upgrade was properly deployed by checking the SHRINE Happy moduleDashboard. The exact address you will need to go to depends on your configuration, but the general format looks like the following:
https://your-server.nameshrine.herehost:6443/shrine/rest/happy/version-dashboard/client/index.html#/dashboard/diagnostics
It may take a few seconds for the page to load, but after it does load, load, log in with your SHRINE credentials (any user will do, regardless of role) and verify that the value for <shrineVersion> matches the version that was just deployed"SHRINE Version" is 1.20.1. If it is still displaying an old version, repeat steps 1 and 4 to redeploy the shrine.war file and start SHRINE again. Example output from this report for SHRINE 1.19.2 can be seen below:
...
the instructions in the "Deploy New shrine.war" section, restart SHRINE, and try again.