...

• i2b2 1.7.08b or newer is installed and operational.
• SHRINE 1.20 or 1.21 is installed and operational.
• The SHRINE Data Steward included with 1.19.2 and or later has been installed and configured properly.

...

• Which method of re-identification protection does your network use? (required configuration, default provided): In 1.22, we obviate the need for user lockout with new features: greater obfuscation of results,  a more interactive Data Steward Application (DSA), and email audit requests from the DSA to the data steward. Lockout remains on by default. (Lockout will be off by default . Networks in SHRINE 1.23, and removed in SHRINE 1.24.) Networks should not need both lockout (method employed in 1.21 and prior) and the new re-identification protections introduced in 1.22. We recommend using the new features and turning lockout off if your network governance allows. (Lockout will be off by default in SHRINE 1.23, and removed in SHRINE 1.24.) 
• Network contact information (optional configuration): Determine what fields every node should provide via the SHRINE static data service. We created this general-purpose feature to provide contact information for the right person that remote researchers should contact for more information about query results. Networks should agree on key-value pairs to supply for this contact information and any other required information.
• Bot defense values (default values provided, optionally configurable): Determine what values to use for Bot Defense for your network, if other than default.

...

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

...

$ 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: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

Make sure to also back up the other existing SHRINE components (shrine-proxy and steward), just in case:especially sure that the shrine.keystore is backed up. If you lose the private side of a cert you may not be able to recover it.

$ mvcp /opt/shrine/tomcat/webapps/shrine-proxy.keystore /opt/shrine/upgrade-backups/shrine.keystore

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

$ mv /opt/shrine/tomcat/webapps/shrine-proxy
$ mv /opt/shrine/tomcat/webapps/steward /opt/shrine/upgrade-backups/stewardshrine

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!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/shrine-webclientsteward /opt/shrine/upgrade-backups/shrine-webclientsteward

Finally remove the old .war files with this command:Make especially sure that the shrine.keystore is backed up. If you lose the private side of a cert you may not be able to recover it.

$ cprm /opt/shrine/shrine.keystore /opt/shrine/upgrade-backups/shrine.keystoretomcat/webapps/*.war

Upgrade to JDK 8 and Tomcat 8 

...