Documentation ▼

Introduction

OpenEM leverages Globus for transferring data from facilities to PSI.

If you are not transferring data to PSI (e.g. for ETHZ which uses the ETHZ Archiving Service), please refer to its documentation.

In this step you will install Globus Connect Server (GCS) on a system with access to your facility data. This can be a transfer server or a VM which mounts the facility data. It should have a good network connection, ideally a 10Gbps connection to both the facility and the SWITCH internet backbone.

Network

Most facilities configure their globus endpoint to only be accessible from PSI. Thus, we recommend a more restricted network configuration from that suggested in the GCP docs.

The following TCP ports should be opened in the firewall (see all firewall rules):

Port Direction IP range Reason
tcp/443 bidirectional 54.237.254.192/29 Globus Control
tcp/50000-51000 outgoing 192.33.126.53 (lx-globus-01.psi.ch)
192.33.126.54 (lx-globus-02.psi.ch)
Globus GridFTP Out

You should assign a domain name for the server (em-globus.facility.ch in examples) an provision SSL certificates; see requirements

Installation

Follow the Globus Connect Server installation guide. This will install the Apache web server and the globus.

No subscription features are used by OpenEM.

Set up a single Mapped Collection for your data.

Identity Mapping

Usually the globus server should be accessible only by facility operators and a service user that manages transfers. End users should not have access (otherwise they would be able to see other users’ data through globus.org website and APIs).

First, create a local service user with access to the data. We use svcusr-globus here as an example. Make sure that the user can read all datasets. (For instance, you can mount data using the svcusr-globus UID and GID.)

Save the following as identity_mapping.json. It maps globus users to local unix usernames. Customize the list to include all admins that should have access. See the Globus Identity Mapping Guide for details.

{
  "DATA_TYPE": "expression_identity_mapping#1.0.0",
  "mappings": [
    {
      "source": "{username}",
      "match": "ce4c22b8-90e8-40e0-90fd-205583835178@clients\\.auth\\.globus\\.org",
      "output": "svcusr-globus"
    },
    {
      "source": "{username}",
      "match": "(admin1|admin2|...)@facility\\.ch",
      "output": "{0}"
    }
  ]
}

Now restart GCS with the new identity mapping. You should include the clients.auth.globus.org domain to ensure the service user has access.

globus-connect-server storage-gateway update posix <id> \
  --identity-mapping file:identity_mapping.json \
  --domain <facility.ch> \
  --domain clients.auth.globus.org

Apache Reverse Proxy

If you plan to run the ingestor on the same server as globus then you will need to run a reverse proxy to direct traffic to the correct destination. Since Globus relies on Apache already, the easiest configuration is just to use Apache as the ingestor reverse proxy. Globus traffic is redirected by the Apache globus plugin, and shouldn’t need any additional configuration.

The location of the Apache configuration directory depends on your distribution:

  • Debian/Ubuntu: /etc/apache2/sites-available/
  • RHEL/Rocky/AlmaLinux/Fedora/SUSE: /etc/httpd/conf.d/

Create a new apache configuration file with the following:

<VirtualHost *:443>
    ServerName ingestor.example.com

    SSLEngine on
    SSLCertificateFile    /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem

    # Route /dev to :8080
    ProxyPass        /dev/  http://localhost:8080/
    ProxyPassReverse /dev/  http://localhost:8080/

    # Route /qa to :8081
    ProxyPass        /qa/  http://localhost:8081/
    ProxyPassReverse /qa/  http://localhost:8081/

    # Route everything else to :8082
    ProxyPass        /  http://localhost:8082/
    ProxyPassReverse /  http://localhost:8082/

    ProxyPreserveHost On
</VirtualHost>

Note the trailing slashes in the ProxyPass directives. Without these the proxy will not work.

Check the configuration for syntax errors:

apachectl configtest

On Debian/Ubuntu, enable the site and reload Apache:

a2ensite <sitename>.conf
systemctl reload apache2

On RHEL/Rocky/AlmaLinux/Fedora/SUSE, files in conf.d/ are enabled automatically, so just reload:

systemctl reload httpd

After installing the ingestor, test that the redirects work by trying the following:

curl https://ingestor.example.com/version
curl https://ingestor.example.com/dev/version
curl https://ingestor.example.com/qa/version

If these requests fail, check the following:

  • apachectl -S lists all configured virtual hosts; confirm your ServerName and port are listed as expected.
  • Check the Apache error log (/var/log/apache2/error.log or /var/log/httpd/error_log) for ProxyPass or SSL errors.
  • Confirm the ingestor containers are actually listening on the ports referenced in the ProxyPass directives (ss -tlnp or docker ps).
  • A 503 Service Unavailable usually means Apache cannot reach the backend port; a 404 on the proxied paths usually means the trailing slash is missing from ProxyPass/ProxyPassReverse.
  • On RHEL-based systems, SELinux may block Apache from making outbound network connections; check with getenforce and enable the httpd_can_network_connect boolean if needed (setsebool -P httpd_can_network_connect 1).
  • Ensure the firewall allows local traffic between Apache and the ingestor ports, and that the external firewall rules are open for port 443.

Registration

The PSI globus proxy requires the endpoint to be registered before it will be available for use. Please send the following information to scicat-help@list.psi.ch to register the new endpoint with OpenEM:

  • domain name
  • Globus endpoint ID
  • facility name

The PSI admins will reply with the correct ingestor configuration for data transfer.

< Back Next >