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 -Slists all configured virtual hosts; confirm yourServerNameand port are listed as expected.- Check the Apache error log (
/var/log/apache2/error.logor/var/log/httpd/error_log) forProxyPassor SSL errors. - Confirm the ingestor containers are actually listening on the ports referenced in the
ProxyPassdirectives (ss -tlnpordocker ps). - A
503 Service Unavailableusually means Apache cannot reach the backend port; a404on the proxied paths usually means the trailing slash is missing fromProxyPass/ProxyPassReverse. - On RHEL-based systems, SELinux may block Apache from making outbound network connections; check with
getenforceand enable thehttpd_can_network_connectboolean 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.