Globus Connect Server v4 Installation Guide

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

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

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:

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.

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

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:

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

Finally, install Globus Connect Server:

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

Next, retrieve and install the additional required repositories:

Finally, install Globus Connect Server:

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

Then, install Globus Connect Server:

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.

This sets the name of the endpoint.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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).

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).

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.

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.

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

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.

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.

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.

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.

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.

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:

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:

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.

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:

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:

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.

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.

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.

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:

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:

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.

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.

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.

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.

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.

The trusted certs directory must contain a copy of the CA cert that signed the hostcert. If the CA that signed the hostcert was not a root CA, then the trusted certs directory must contain a copy of all of the intermediate CA certs needed to chain back to the root CA, and must also contain a copy of the root CA cert.

The certs in the trusted certs directory must be named according to this pattern: "cert_subject_hash.0". The corresponding .signing_policy file for each cert must be named according to this pattern: "cert_subject_hash.signing_policy". The following command can be used to find the subject hash value for a cert:

Configuring trusted certs for endpoint using MyProxy based activation

If the endpoint is configured for MyProxy (or OAuth for MyProxy) based activation, then the trusted certs directory must contain a copy of the CA cert for the MyProxy server, as well as any additional certs needed to chain that cert back to a root CA as described above. It is also required that the corresponding .signing_policy files for the cert(s) be placed into the trusted certs directory as well. By default, when using the MyProxy service that ships with GCS, the trusted certs directory will be automatically configured with the needed MyProxy CA certs.

Configuring trusted certs for endpoint using CILogon based activation

If the endpoint is configured for CILogon based activation, then the trusted certs directory must contain a copy of the CILogon certs as found here:

https://github.com/globus/globus-connect-server/tree/master/source/globus/connect/security

In addition to these certs described above, the trusted certs directory must contain a copy of the .signing_policy file for each of the certs. By default, GCS will automatically configure the trusted certs directory with the needed CILogon CA certs when GCS is configured to use CILogon based activation.