Skip to content

Deploying SciGateway

Jump to bottom
Louise Davies edited this page Apr 8, 2020 · 27 revisions

To deploy SciGateway itself on it's own is fairly simple - since it is purely html + javascript it can be served by any static server. Or, you could write your own server and run that as a service. Some information on how to do this generally are detailed on the ReactJS deployment documentation page: https://create-react-app.dev/docs/deployment.

Below I will describe how I set up SciGateway on the scigateway-preprod.esc.rl.ac.uk machine.

Server setup

1. Install node & yarn

(Node Instructions)

(Yarn instructions)

2. Install Apache:

yum install httpd

3. Open firewall ports

iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 8000 -j ACCEPT
iptables-save > /etc/sysconfig/iptables

4. Add VirtualHost config to Apache:

/etc/httpd/conf.d/scigateway.conf

<VirtualHost *:80>
  ServerName http://scigateway-preprod.esc.rl.ac.uk

  <LocationMatch "^/api/(.*)">
    ProxyPassMatch "http://scigateway-preprod.esc.rl.ac.uk:8000/api/$1"
  </LocationMatch> 

  <Directory "/var/www/html">
    RewriteEngine on
    # Don't rewrite files or directories
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    # Rewrite everything else to index.html to allow html5 state links
    RewriteRule ^ index.html [QSA,L]
  </Directory>
</VirtualHost>

This sets up Apache on port 80, it forwards any requests to /api to port 8000 (this is where we'll host an auth server), and rewrites all paths back to index.html as long as they don't correspond to a real file or directory (this allows for client side routing)

5. Start Apache

systemctl start httpd

Deploying SciGateway

On scigateway-preprod.esc.rl.ac.uk, the SciGateway repository is cloned and built by the ICAT glassfish user in the /home/glassfish/scigateway folder - which contains all the git repos.

1. (If cloning the repo for the first time) Setup SciGateway repo

Run yarn install to install dependencies and ensure your settings files are correct (e.g. public/settings.json exists and is configured correctly, check your strings file (default is public/res/default.json))

2. Build SciGateway

yarn build

This will build SciGateway in production mode. This will minimise the JavaScript and perform other performance improvements.

3. Copy build contents to Apache web root

cp build/* /var/www/html/

Deploying auth-server.js

In order for SciGateway to have login functionality, it needs to be able to contact an auth server. The Apache config is already proxying requests to /api to port 8000, so we just need to run our auth server. If you run

node server/auth-server.js

In the root of SciGateway then this should run the server and if you try logging in with SciGateway it should work. Now, we don't want to have to run this manually ourselves so we can create a systemd service file to run the auth server as a service.

Create /etc/systemd/system/scigateway-auth-test.service and paste the following contents:

[Unit]
Description=Default scigateway auth server
Documentation=https://github.com/ral-facilities/scigateway/wiki
After=network.target

[Service]
Type=simple
User=glassfish
ExecStart=/usr/bin/node /home/glassfish/scigateway/scigateway/server/auth-server.js
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target

(this assumes that there is an unprivileged glassfish user that has cloned the SciGateway repo - as is used by the ICAT stack - you can change this to be any unprivileged user)

Deploying scigateway-auth

It's all well and good to be able to deploy the test auth server, but this doesn't help if we want to authenticate using scigateway-auth, which supplies ICAT authentication capabilities. We can instead choose to set up scigateway-auth instead of the auth-server.js server.

NOTE: You can only have one authentication server running at a time, so disable auth-server.js if you had previously set it up.

1. Clone scigateway-auth 

git clone https://github.com/ral-facilities/scigateway-auth.git

1. Install Python 3, mod_wsgi + dependencies

As root:

yum install epel-release
yum install python36 python36-pip
yum install httpd-devel
pip3 install mod-wsgi
mod_wsgi-express install-module > /etc/httpd/conf.modules.d/02-wsgi.conf

As glassfish, in /home/glassfish/scigateway/scigateway-auth:

pip3 install --user -r requirements.txt

2. Create settings file

In /home/glassfish/scigateway/scigateway-auth, you will need to copy the example config file config.json.example and modify it to suit your needs. The host and port values only affect the dev server and so can be ignored, but other options like icat_url need to be modified to suit your deployment.

e.g. for our setup

{
    "host": "127.0.0.1",
    "port": 5000,
    "debug_mode": false,
    "icat_url": "https://scigateway-preprod.esc.rl.ac.uk:8181/icat",
    "log_level": "INFO",
    "access_token_valid_for": 120,
    "refresh_token_valid_for": 120,
    "blacklist": [],
    "verify": "/home/glassfish/scigateway/scigateway-auth/icat_cert.crt"
}

The verify config option specifies how requests will verify that ICAT is trusted to communicate over SSL. This can be set to false to disable certificate verification but better is to supply ICAT's actual self signed certificate. ICAT's certificate can be extracted using the following steps:

keytool -importkeystore -srckeystore /home/glassfish/payara[version-string]/glassfish/domains/domain1/config/keystore.jks -srcstoretype JKS -srcstorepass changeit -destkeystore keystore.p12 -storepass changeit -deststoretype PKCS12
openssl pkcs12 -in keystore.p12 -passin pass:changeit -clcerts -nokeys -out /home/glassfish/scigateway/scigateway-auth/icat_cert.crt

3. Add VirtualHost config to Apache:

/etc/httpd/conf.d/scigateway-auth

Listen 8000
<VirtualHost *:8000>
     ServerName http://scigateway-preprod.esc.rl.ac.uk

     WSGIPassAuthorization On
     WSGIDaemonProcess scigateway-auth user=glassfish group=glassfish threads=1 python-path=/home/glassfish/scigateway/scigateway-auth 
     WSGIScriptAlias / /var/www/scigateway-auth/scigateway-auth.wsgi process-group=scigateway-auth application-group=%{GLOBAL}

     <Directory /var/www/scigateway-auth>
          Options FollowSymLinks
          AllowOverride None
          Require all granted
     </Directory>
</VirtualHost>

This sets up Apache to run mod_wsgi on port 8000. It expects a wsgi file in /var/www/scigateway-auth/scigateway-auth.wsgi and runs the server as the unprivileged glassfish user.

4. Set up wsgi file

Create /var/www/datagateway-api/datagateway-api.wsgi

#! /usr/bin/python3.6

import logging
import sys
logging.basicConfig(stream=sys.stderr)
sys.path.insert(0, '/home/glassfish/scigateway/scigateway-auth/scigateway-auth/')

from app import app as application

systemctl restart httpd

This tells mod_wsgi the actual location of our app and how to run it.

5. Modify scigateway settings.json

Since we are now using the ICAT authenticator, we need to update our settings.json to reflect this. It's recommended to update the settings.json in both the git folder (/home/glassfish/scigateway/scigateway/public/settings.json) and the deployment folder (/var/www/html/settings.json) - updating the deployment folder will immediately reflect any changes whereas updating the git folder will ensure the changes are applied when you next build SciGateway.

Switch the auth-provider field to say icat instead of jwt

6. OPTIONAL: Check ICAT authenticator info settings

In order to make the most of the SciGateway ICAT authenticator, the run.properties file of the ICAT you are suing may need to be updated. There are optional config options for authenticators: friendly, which specifies a more human readable name for the authenticator; and admin, which indicates whether an authenticator is intended for admin use only. If a friendly name is set, then SciGateway will display that name in the dropdown instead of the mnemonic, and if admin is true then SciGateway will not display it in the dropdown (since that authenticator is for admin use only, it should not be displayed in the frontend). Updating the run.properties file requires reinstalling ICAT, and thus production ICATs will need to plan around this, either by incorporating the change into existing downtime plans or planning a downtime exclusively for this change.

Clone this wiki locally