This guide is designed to assist system admins installing SHRINE.
This guide assumes that you have already installed a working version of the i2b2 software. If you have any problems installing the i2b2 software, please refer to the i2b2 installation guide, provided here:
Follow this guide in the order that the steps are written. Some steps must occur before others. The chapters are organized in the order in which the installation should occur. Some chapters subchapters . Expand the sidebar in the lower left corner to see the chapter list.
This documentation frequently refers to template configuration files in shrine-setup.zip. Download this archive from https://repo.open.catalyst.harvard.edu/nexus/content/groups/public/net/shrine/shrine-setup/4.1.0/shrine-setup-4.1.0-dist.zip
This documentation is written without specific regards to the actual informatics network in which SHRINE is deployed. For network-specific information and configuration, please contact the support personnel appropriate to your network.
Considerations Before You Begin
We designed SHRINE with the best default values for most settings to minimize customization. However, SHRINE supports some high-level customizations to better fit your institutions' practices.
Note: If you are joining a network, make sure you are choosing a version of SHRINE that is compatible with the network you are joining. SHRINE 4.1 is not backwards compatible with previous versions. As of now, the hubs on the ENACT network are running SHRINE version 3.1. Therefore, all downstream nodes on the ENACT network must use SHRINE 3x or earlier.
SHRINE provides schemas for downstream nodes that support mysql/mariadb, Oracle, and MS SQL server. See SHRINE 4.1.0 Chapter 6 - Install and Configure a Database Service.
By default SHRINE uses the i2b2 PM cell to authenticate and authorize users. See SHRINE 4.1.0 Chapter 9 . Starting in 4.0 SHRINE can be configured to use Shibboleth. See SHRINE 4.1.0 Appendix A - Setting up SSO - with Shibboleth SP 3.
Considerations for a Network
SHRINE uses message-oriented middleware to support reliable asynchronous communication. By default a SHRINE network needs no additional configuration, but can be configured to use AWS SQS or Kafka to minimize the impact of hub maintenance. See SHRINE 4.1.0 Chapter 8.2 - Configuring a Hub.