Globus Connect Server v4 Installation Guide

2.5.1. Check hostname local DNS resolution

Execute this command on the system where you plan to install Globus Connect Server:

$ hostname -f

Confirm that a fully qualified domain name (FQDN) is returned (e.g., 'ep1.transfer.globus.org' ).

2.5.2. Check hostname external DNS resolution

Use a public DNS server operated by a different organization to verify that the returned FQDN is publicly resolvable. More concretely, you can use nslookup to check that your server’s FQDN resolves against one of Google’s public DNS servers:

$ nslookup 'ep1.transfer.globus.org' 8.8.4.4

If you get a message of the form "** server can’t find ep1.transfer.globus.org: NXDOMAIN", your system’s hostname is not resolvable via public DNS and you need to address the issue before continuing with the installation.

3.1.1. CentOS, Fedora, Red Hat Enterprise Linux, Scientific Linux

First, add the Globus Connect Server repository to your package management system:

$ sudo curl -LOs https://downloads.globus.org/toolkit/globus-connect-server/globus-connect-server-repo-latest.noarch.rpm
$ sudo rpm --import https://downloads.globus.org/toolkit/gt6/stable/repo/rpm/RPM-GPG-KEY-Globus
$ sudo yum install globus-connect-server-repo-latest.noarch.rpm

You will need the EPEL repository available and enabled on your system. If this is not already the case, you can install the EPEL repository with the instructions below.

Install EPEL repository on CentOS 6, Red Hat Enterprise Linux 6, and Scientific Linux 6:

$ sudo curl -LOs https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
$ sudo yum install epel-release-latest-6.noarch.rpm

Install EPEL repository on CentOS 7, Red Hat Enterprise Linux 7, and Scientific Linux 7:

$ sudo curl -LOs https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
$ sudo yum install epel-release-latest-7.noarch.rpm

$ sudo yum install yum-plugin-priorities

Finally, install Globus Connect Server:

$ sudo yum install globus-connect-server

3.1.2. SuSE Linux Enterprise Server

First, add the Globus Connect Server repository to your package management system:

$ sudo curl -LOs https://downloads.globus.org/toolkit/globus-connect-server/globus-connect-server-repo-latest.noarch.rpm
$ sudo rpm --import https://downloads.globus.org/toolkit/gt6/stable/repo/rpm/RPM-GPG-KEY-Globus
$ sudo zypper install globus-connect-server-repo-latest.noarch.rpm

Next, retrieve and install the additional required repositories:

$ sudo zypper ar http://download.opensuse.org/repositories/Apache/SLE_12_SP2/Apache.repo
$ sudo zypper ar http://download.opensuse.org/repositories/Apache:/Modules/Apache_SLE_12_SP2/Apache:Modules.repo
$ sudo rpm --import http://download.opensuse.org/repositories/Apache/SLE_12_SP2/repodata/repomd.xml.key
$ sudo rpm --import http://download.opensuse.org/repositories/Apache:/Modules/Apache_SLE_12_SP2/repodata/repomd.xml.key
$ sudo zypper remove libapr1

Finally, install Globus Connect Server:

$ sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-Globus
$ sudo zypper install globus-connect-server

3.1.3. Debian, Ubuntu

First, add the Globus Connect Server repository to your package management system:

$ sudo curl -LOs https://downloads.globus.org/toolkit/globus-connect-server/globus-connect-server-repo_latest_all.deb
$ sudo dpkg -i globus-connect-server-repo_latest_all.deb
$ sudo apt-get update

Then, install Globus Connect Server:

$ sudo apt-get install globus-connect-server

4.1.1. User and Password options

These options can be used to set the username and password of the Globus user that will be used when creating or updating the endpoint definition.

4.2.1. Name option

This sets the name of the endpoint.

4.2.2. Public option

This determines if the endpoint is publicly visible to all Globus users.

4.2.3. DefaultDirectory option

This sets the default directory that users will be sent to when first accessing an endpoint.

4.3.1. IdentityMethod option

This option has three legal values: MyProxy, OAuth, and CILogon. For a graphical overview of the authentication flows each of these methods use, see here. If you wish to use MyProxy as your endpoint’s identity method, then you need to be sure to specify the Server option in the [MyProxy] section. If you wish to use OAuth as your endpoint’s identity method, then you need to be sure to specify the Server option in the [OAuth] section, and may also need to specify the Server option in the [MyProxy] section if you are using MyProxy on the server to provide authentication for the OAuth service. If you are using CILogon, then you will also need to specify the CILogonIdentityProvider option in the [Security] section.

4.3.2. CILogonIdentityProvider option

This option specifies the identity provider to use with CILogon. See https://cilogon.org/include/idplist.xml for a list of valid providers. To configure your endpoint to use a specific provider, set this option to the value of the "Organization_Name" given for that provider at the previous URL. Be sure to also set "IdentityMethod=CILogon" in the [Security] section of the config file if you intend to use CILogon for your endpoint.

4.4.1. Server option

This option specifies the hostname of the GridFTP server. This should match the hostname of the server except, possibly, if NAT is being used. Can be left blank if you don’t want to configure a GridFTP server on this host. If a GridFTP service is to be run on this server, then the default value of "Server = %(HOSTNAME)s" is suitable to most cases, so long as the configured hostname on the server matches the public FQDN that is going to be used for the server.

4.4.2. ServerBehindNAT option

This option specifies that the server is behind a NAT firewall/router. See the NAT section for details.

4.4.3. RestrictPaths option

This option is used to both enable and/or disable specified file paths for all Globus users that are authorized to use this endpoint. By default, all paths are enabled for access.

4.4.4. Sharing option

This is a boolean value that determines if sharing is enabled on this particular endpoint. This option is only used on a managed endpoint, and will be ignored otherwise.

4.4.5. SharingRestrictPaths option

This option is used to both enable and/or disable specified file paths for all Globus users that are authorized to use this shared endpoint. By default, all paths are enabled for access. NOTE: When accessing a shared endpoint through Globus, the SharingRestrictPaths option can only set further access restrictions to the endpoint owner’s local unix file system permissions. Globus does not and can not override the local unix file system permissions. This option is only used on a managed endpoint, and will be ignored otherwise.

4.4.6. RequireEncryption option

This boolean value determines if encryption will be forced for the GridFTP server being configured on this host. Please note that, if set to True, transfers will fail if they are attempted without encryption.

4.5.1. Server option

This option specifies the hostname of the MyProxy server. If you are running the MyProxy server on this host, then this should match the hostname of this server except, possibly, if NAT is being used. If you are using a MyProxy server on a different host, then use the hostname of that host. Can be left blank if you don’t want to configure a MyProxy server at all. If the MyProxy service for the endpoint is to be run on this server, then the default value of "Server = %(HOSTNAME)s" is suitable to most cases, so long as the configured hostname on the server matches the public FQDN that is going to be used for the server. Be sure to also set "IdentityMethod=MyProxy" in the [Security] section of the config file if you intend to use MyProxy for your endpoint.

4.5.2. ServerBehindNAT option

This option specifies that the server is NATed. See the NAT section for details.

4.6.1. Server option

This option specifies the hostname of the OAuth server. If you are running the OAuth server on this host, then this should match the hostname of this server except, possibly, if NAT is being used. If you are using an OAuth server on a different host, then use the hostname of that host. Can be left blank if you don’t want to configure an OAuth server at all. If the OAuth service for the endpoint is to be run on this server, then the default value of "Server = %(HOSTNAME)s" is suitable to most cases, so long as the configured hostname on the server matches the public FQDN that is going to be used for the server. Be sure to also set "IdentityMethod=OAuth" in the [Security] section of the config file if you intend to use OAuth for your endpoint.

4.6.2. ServerBehindNAT option

This option specifies that the server is NATed. See the NAT section for details.

5.1.1. Using GridFTP behind a NAT Firewall

To use a GridFTP behind a NAT firewall, set the Server option to the public name of the GridFTP server, and set the ServerBehindNAT option to True. This causes globus-connect-server-io-setup to generate GridFTP configuration for the node even if the Server name doesn’t match the node’s local hostname. This requires that the GridFTP server is visible from Globus at the address associated on the public internet with the name that is the Server value.

5.1.2. NAT Firewall Example

As an example, this configures the GridFTP server to run on the current host, using public-gridftp.example.org as its public name and listening on port 22811 instead of the default 2811. In order for this to work, the NAT firewall must allow connections to TCP port 22811 and the range 50000-51000 on the I/O node. By default, the Server name is used to construct the data interface name as well, but this behavior can be changed (see Using GridFTP with a Particular Data Interface).

[GridFTP]
Server = public-gridftp.example.org:22811
ServerBehindNAT = True

5.1.3. Using GridFTP with Firewall Port Restrictions

To use a GridFTP server with a firewall with incoming and/or outgoing port restrictions, use the IncomingPortRange and OutgoingPortRange configuration options. The former restricts the TCP port range that the GridFTP server listens on for ephemeral connections to a port range. The OutgoingPortRange restricts the TCP source port range that the GridFTP server uses when creating outgoing data connection sockets. For both of these items, the syntax of the port range is startport,endport (e.g., 50000,51000).

5.1.4. Port Restrictions Example

As an example, this configures the GridFTP server to listen for TCP connections on ports from 4000 to 5000 instead of the default 50000 to 51000. This will require configuration on the firewall to allow those ports to connect directly to the I/O node.

[GridFTP]
Server = public-gridftp.example.org:22811
IncomingPortRange = 4000,5000

5.1.5. Using GridFTP with a Particular Data Interface

The GridFTP server can also be configured to use a different IP address for its incoming data connections by setting the DataInterface option in the configuration file. By default, the GridFTP server will use the same IP address as that associated with the Server value. This can be altered, for example, to create a limited-use endpoint that uses a high-speed interconnect between I/O resources, but is not generally accessible from the internet.

5.1.6. Data Interface Example

As an example, this configures the GridFTP server to listen for TCP data connections on gig-e.example.org.

[GridFTP]
Server = public-gridftp.example.org:22811
DataInterface = gig-e.example.org

5.2.1. Using MyProxy behind a NAT Firewall

To use a MyProxy server behind a NAT firewall, set the Server option to the public name of the MyProxy server, and set the ServerBehindNAT option to True. This causes globus-connect-server-id-setup to generate MyProxy configuration for the node even if the Server name doesn’t match the node’s local hostname. If you are configuring an OAuth server, the Server option must be accessible from the Web node and I/O nodes (during configuration); otherwise, it must be accessible from Globus.

5.2.2. NAT Firewall Example

As an example, this configures the MyProxy server to run on the current host, using public-myproxy.example.org as its public name and listening on port 17512 instead of the default 7512. In order for this to work, the NAT firewall must allow connections to the TCP port 17512 on the ID node.

[MyProxy]
Server = public-myproxy.example.org:17512
ServerBehindNAT = True

5.3.1. Using OAuth behind a NAT Firewall

To use an OAuth server behind a NAT firewall, set the Server option to the public name of the OAuth server, and set the ServerBehindNAT option to True. This causes globus-connect-server-web-setup to generate OAuth configuration for the node even if the Server name doesn’t match the node’s local hostname. This requires that the OAuth server is visible from Globus at the address associated on the public internet with the name that is the Server value.

5.3.2. NAT Firewall Example

As an example, this configures the OAuth server to run on the current host, using public-oauth.example.org as its public name. In order for this to work, the NAT firewall must allow connections to TCP port 433 on the web node.

[OAuth]
Server = public-oauth.example.org
ServerBehindNAT = True

7.1.1. Test Basic Endpoint Functionality

An important verification of endpoint health is to confirm that the endpoint is able to successfully participate in transfers from and to other endpoints. Globus maintains two test endpoints, Globus Tutorial Endpoint 1 and Globus Tutorial Endpoint 2, that are always available for users to access when checking the functionality of their own endpoints. First, attempt to transfer the contents of the /share/godata/ directory on the Globus Tutorial Endpoint 1 endpoint to your own endpoint. After that, attempt to transfer those same files to the /~/ directory on the Globus Tutorial Endpoint 2 endpoint. If these tests both succeed, then your endpoint is functional and able to serve as the destination and the source of transfers. For more detailed instructions on how to use the Globus service to transfer files, see here.

7.1.2. Verify globus-gridftp-server Service

Another important check on servers hosting a Globus endpoint is to verify that the globus-gridftp-server service has properly started and is running. To do this, first use the ps command to see if there is an instance of globus-gridftp-server running:

# ps aux | grep globus-gridftp-server
root       604  0.0  0.7  97924  7312 ?        Ss   14:18   0:00 /usr/sbin/globus-gridftp-server -c /etc/gridftp.conf -C /etc/gridftp.d -pidfile /var/run/globus-gridftp-server.pid -no-detach -config-base-path /

If you do not see an instance of globus-gridftp-server running, then the service has not started. You can try to start it by executing the globus-connect-server-setup command and then checking to see if an instance of globus-gridftp-server appears in the ps output. If you still don’t see an instance of globus-gridftp-server running after issuing the globus-connect-server-setup command, you can take a look in the logs for clues as to what might be wrong.

If there is an instance of globus-gridftp-server running, you can then check to see if you can connect to it locally via the telnet command:

# telnet 127.0.0.1 2811
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ^].
220 ip-172-31-31-13.us-west-2.compute.internal GridFTP Server 7.26 (gcc64, 1433516164-85) [Globus Toolkit 6.0.1428430525 GCS-4.0.18] ready.

If there is an instance of globus-gridftp-server running, but you can’t connect locally, then there is probably a local firewall rule on the server that is interfering with your attempt to connect.

If you are successful with the local telnet connection, then try telnet again using the public FQDN associated with your server and see if that works. If you’re not able to connect when using the public FQDN, then you may have a firewall issue or a name resolution issue that is preventing you from being able to connect properly.

7.1.3. Verify myproxy-server Service

Another important check on servers hosting a Globus endpoint that use MyProxy for endpoint authentication is to verify that the myproxy-server service has properly started and is running. Note that not all endpoints use the MyProxy service, so this check is only useful if your endpoint uses MyProxy for endpoint authentication. To run this check, first use the ps command to see if there is an instance of myproxy-server running:

# ps aux | grep myproxy-server
root       602  0.0  0.1 110812  1112 ?        S    14:18   0:00 /usr/sbin/myproxy-server -s /var/lib/myproxy -c /var/lib/globus-connect-server/myproxy-server.conf -s /var/lib/globus-connect-server/myproxy-ca/store

If you do not see an instance of myproxy-server running, then the service has not started. You can try to start it by executing the globus-connect-server-setup command and then checking to see if an instance of myproxy-server appears in the ps output. If you still don’t see an instance of myproxy-server running after using the globus-connect-server-setup command, you can take a look in the logs for clues as to what might be wrong.

If there is an instance of myproxy-server running, you can then check to see if you can connect to it locally via the telnet command:

# telnet 127.0.0.1 7512
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ^].
type something here and hit enter
VERSION=MYPROXYv2
RESPONSE=1
ERROR=authentication failed
Connection closed by foreign host.

If there is an instance of myproxy-server running, but you can’t connect locally, then there is probably a local firewall rule on the server that is interfering with your attempt to connect.

If you are successful with the local telnet connection, then try telnet again using the public FQDN associated with your server and see if that works. If you’re not able to connect when using the public FQDN, then you may have a firewall issue or a name resolution issue that is preventing you from being able to connect properly.

7.2.1. Documentation Website

This website (docs.globus.org) contains a wealth of information about configuring and using the Globus service. Many common issues can be resolved quickly by browsing our frequently asked questions and reading the relevant guides and how-to’s. We recommend consulting these resources first when looking for fast resolution to any issue you are having with the Globus service.

7.2.2. Mailing Lists

If you use Globus, then participating in one or more of the public email lists is an excellent way to keep in touch with your peers in the Globus Community. For questions about managing your Globus deployment, e.g. installing software for a Globus endpoint, configuring your firewall, and integrating your institution’s identity system, subscribe to the admin list. For other inquiries and discussions, try the user or developer lists. For more information on mailing lists and how to subscribe, click here.

7.2.3. Globus Support

Questions or issues that pertain to Globus Connect Server installation or to any client or service that is used in the Globus software-as-a-service (SaaS) or platform-as-a-service (PaaS) offering can be directed to the Globus support team by submitting a ticket. Subscriptions include a guaranteed support service level.

When submitting a ticket for an issue with Globus Connect Server, please include the endpoint name, a description of your issue, and screenshot/text dumps of any errors you are seeing. Please also include the output of the following commands, run as root, from the server hosting the GCS endpoint:

uname -a
ifconfig
ping $(hostname -f)
cat /etc/os-release; cat /etc/redhat-release
cat /etc/gridftp.d/*
cat /etc/gridftp.conf
globus-gridftp-server --version
grep -v "^$\|^;" /etc/globus-connect-server.conf

8.5.1. Controlling what can be shared

It is possible to control which file system paths on the endpoint are allowed for sharing via the "SharingRestrictPaths" option, which is also in the [GridFTP] section of the /etc/globus-connect-server.conf file. Remember, after making changes to the /etc/globus-connect-server.conf file it is necessary to run the ‘globus-connect-server-setup' command before those changes will take effect. Additional details about these configuration options can be found here and also in the globus-connect-server.conf file itself.

In our scenario, Adam wants to allow his users to create shares that point to the "globus" directory in their home directory. Adam has also decided that he wants to allow his users to create shares that can both be read and written to, so he will specify the SharingRestrictPaths option in his endpoint’s globus-connect-server.conf file like so:

SharingRestrictPaths = RW~/globus

8.5.2. Controlling who can share

Recall that our use case with Adam required that sharing be enabled for only certain users. At this point sharing is enabled for all users on the server hosting the abcu#ep1 endpoint. By editing the SharingUsersAllow, SharingGroupsAllow, SharingUsersDeny, and SharingGroupsDeny options in the [GridFTP] section of the /etc/globus-connect-server.conf file, Adam can restrict which local users on the server are allowed to create shares on the abcu#ep1 endpoint. By default, when no value is set for any of these options, GCS will allow sharing for all local user accounts. Any users or groups listed in the SharingGroupsDeny or SharingUsersDeny options will not be allowed to share. If any value is set for SharingUsersAllow or SharingGroupsAllow, then only users and groups explicitly listed in these options will be allowed to share.

Since Adam only wants to allow certain users to be able to share, he has decided to create a local unix group on his system and adds the users he wants to allow to share to that unix group. Adam thus creates the globus_sharing_allow unix group and then adds Bob’s local user account to that group. Adam then edits his /etc/globus-connect-server.conf file and sets "SharingGroupsAllow = globus_sharing_allow". Adam next runs the globus-connect-server-setup command so that his configuration changes will take effect. With this change made, now all users who are members of the globus_sharing_allow group - such as Bob - will be able to share. Sue, who Adam has not yet added to the globus_sharing_allow group, is still unable to share. To address this, Adam adds Sue’s local user account to the globus_sharing_allow group and Sue is then able to share.

8.7.1. Local user creating a shared endpoint

To illustrate with an example, let’s consider Bob who wants to create a share on endpoint abcu#ep1. Bob has a local account on the server hosting abcu#ep1 with username of bob_local. Bob’s Globus account is bob_globus. When Bob wants to create his share hosted by abcu#ep1, he will log into the Globus website using his bob_globus credentials. He will then activate on the abcu#ep1 endpoint using his bob_local credentials. At that point, Bob can create his share. Let’s say Bob creates a share named bob_globus#myshare, which points to the /home/bob_local/globus directory. Now, Bob can assign share permissions to other users that he wants to have access to his share. He can give Globus users read or write permissions to the share as he desires.

8.7.2. Local user sharing with another local user

Let’s say that Bob gives Sue - who has a Globus account of sue_globus and a local account of sue_local - read and write access to the share. Now, if Sue wants to access the bob_local#myshare share, she will log into the Globus website using her sue_globus credentials. At this point, Sue’s ability to access the bob_local#myshare share depends on both the share permissions that Bob granted the sue_globus Globus user to the share, as well as the file system permissions that the local bob_local account has to the file system that the share points to. Even if Sue has read and write access at the share level, she still won’t - for example - be able to write to the share if the bob_local local user doesn’t have write permissions at the file system level in the file system space that the share points to. Notice that the permissions (or lack thereof) for the sue_local account played no role in determining Sue’s access to the share.

8.7.3. Local user sharing with a non local user

Along the same lines let’s consider what happens when Bob grants share access to Ann, who has a Globus account of ann_globus - and no local account on the server. For this example let’s say that Bob grants the ann_globus account read and write access to the bob_local#myshare share - which are the same permissions that he granted Sue. As sue_globus and ann_globus have identical share permissions, they now have identical levels of access to the share.

8.7.4. Summary

To sum up, both the share permissions granted to a Globus user, as well as the file system rights of the local user that the Globus user (who owns the share) activated on the endpoint with when the share was created, must be taken into account when determining effective permissions to a share.