globus / globus-connect-server Goto Github PK

View Code? Open in Web Editor NEW

6.0 6.0 10.0 638 KB

Globus Connect Server

Makefile 0.52% Perl 31.18% Python 32.88% Shell 0.71% CSS 0.01% HTML 30.12% Roff 4.59%

globus-connect-server's People

Contributors

Stargazers

Watchers

Forkers

treydock giovtorres pauldonovan08 sirosen bradleymorgan jtfrey ronpandolfi bester felliott

globus-connect-server's Issues

globus-connect-server-setup doesn't work on ubuntu 16.04

I tried the newest globus-connect-server on ubuntu 16.04 following https://docs.globus.org/globus-connect-server-installation-guide/.

Things look good up until I run set:

$ sudo globus-connect-server-setup
get() got an unexpected keyword argument 'fallback'

Sounds like the same problem reported on ticket #8 that's happening on CentOS as well.

It does work on Ubuntu-14.04, but that's hitting EoL in April

Update to use python3

As part of migration to python3, use the globus-sdk-python instead of the old Transfer API client which does not support python3.

GCS configures wrong MyProxy CA cert when attempting to join second IO node to endpoint

GCS configures wrong MyProxy CA cert when attempting to join second IO node to endpoint configured to use MyProxy based auth.

Both nodes running CentOS 7 and GCS 4.0.36.

Both nodes are fresh instances of ami-1b4a032b, fully patched, and running fresh GCS installs.

Details for first node, configured to run GridFTP and MyProxy:

# grep -v "^$\|^;" /etc/globus-connect-server.conf
[Globus]
User = %(GLOBUS_USER)s
Password = %(GLOBUS_PASSWORD)s
[Endpoint]
Name = prod01
Public = True
DefaultDirectory = /~/
[Security]
FetchCredentialFromRelay = True
IdentityMethod = MyProxy
[GridFTP]
Server = %(HOSTNAME)s
RestrictPaths =
[MyProxy]
Server = %(HOSTNAME)s
[OAuth]

# cat /etc/gridftp.d/*
version_tag GCS-4.0.36
usage_stats_id GCS-4.0.36+centos-7.2.1511-64bit
port_range 50000,51000
data_interface 54.186.30.23
$GSI_AUTHZ_CONF "/etc/gridmap_verify_myproxy_callout-gsi_authz.conf"
$GRIDMAP "/etc/grid-security/grid-mapfile"
$GLOBUS_MYPROXY_CA_CERT "/var/lib/globus-connect-server/grid-security/certificates/6f1924ec.0"
$X509_USER_CERT "/var/lib/globus-connect-server/grid-security/hostcert.pem"
$X509_USER_KEY "/var/lib/globus-connect-server/grid-security/hostkey.pem"
log_single /var/log/gridftp.log
log_level ERROR,WARN
$X509_CERT_DIR "/var/lib/globus-connect-server/grid-security/certificates"

Note $GLOBUS_MYPROXY_CA_CERT "/var/lib/globus-connect-server/grid-security/certificates/6f1924ec.0". Here are the subject and issuer for that cert:

# openssl x509 -subject -issuer -noout -in /var/lib/globus-connect-server/grid-security/certificates/6f1924ec.0
subject= /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=bf78630a-4ac8-11e6-8233-22000b97daec
issuer= /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=bf78630a-4ac8-11e6-8233-22000b97daec

Details for second node, running GridFTP and configured to use first node for MyProxy services:

# grep -v "^$\|^;" /etc/globus-connect-server.conf
[Globus]
User = %(GLOBUS_USER)s
Password = %(GLOBUS_PASSWORD)s
[Endpoint]
Name = prod01
Public = True
DefaultDirectory = /~/
[Security]
FetchCredentialFromRelay = True
IdentityMethod = MyProxy
[GridFTP]
Server = %(HOSTNAME)s
RestrictPaths =
[MyProxy]
Server = ec2-54-186-30-23.us-west-2.compute.amazonaws.com
[OAuth]

# globus-connect-server-setup -v
Globus Id:  XXX
Password: 
ENTER: ID.setup()

...

ENTER: get_myproxy_ca_dn_from_server()
fetching myproxy ca dn from server
MyProxy CA DN is /C=US/O=Globus Consortium/CN=Globus Connect CA 3
EXIT: get_myproxy_ca_dn_from_server()
MyProxy CA DN is /C=US/O=Globus Consortium/CN=Globus Connect CA 3
CA dir is /var/lib/globus-connect-server/grid-security/certificates
Looking for MyProxy CA cert in /var/lib/globus-connect-server/grid-security/certificates
Checking to see if a059cd44.0 matches MyProxyDN
EXIT: configure_gridmap_verify_myproxy_callout()

...

Using Authentication Method MyProxy
Configured Endpoint prod01
EXIT: IO.setup()

Note MyProxy CA DN is /C=US/O=Globus Consortium/CN=Globus Connect CA 3 and Checking to see if a059cd44.0 matches MyProxyDN.

# cat /etc/gridftp.d/*
version_tag GCS-4.0.36
usage_stats_id GCS-4.0.36+centos-7.2.1511-64bit
port_range 50000,51000
data_interface 54.149.162.126
$GSI_AUTHZ_CONF "/etc/gridmap_verify_myproxy_callout-gsi_authz.conf"
$GRIDMAP "/etc/grid-security/grid-mapfile"
$GLOBUS_MYPROXY_CA_CERT "/var/lib/globus-connect-server/grid-security/certificates/a059cd44.0"
$X509_USER_CERT "/var/lib/globus-connect-server/grid-security/hostcert.pem"
$X509_USER_KEY "/var/lib/globus-connect-server/grid-security/hostkey.pem"
log_single /var/log/gridftp.log
log_level ERROR,WARN
$X509_CERT_DIR "/var/lib/globus-connect-server/grid-security/certificates"

Note $GLOBUS_MYPROXY_CA_CERT "/var/lib/globus-connect-server/grid-security/certificates/a059cd44.0"

Attempts to access node 2 now generate errors like this:

Command Failed: Error (login) Endpoint: XXX#prod01 (c206fda2-4ac8-11e6-8233-22000b97daec) Server: ec2-54-149-162-126.us-west-2.compute.amazonaws.com:2811 Message: Login Failed --- 530-Login incorrect. : globus_gss_assist: Error invoking callout\r\n530-globus_callout_module: The callout returned an error\r\n530-globus_gridmap_callout_error: Gridmap lookup failure: Could not map /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=bf78630a-4ac8-11e6-8233-22000b97daec/CN=testuser\r\n530-\r\n530 End.\r\n

The /var/lib/globus-connect-server/grid-security/certificates/6f1924ec.0 cert exists on node 2, and pointing $GLOBUS_MYPROXY_CA_CERT at it and restarting GridFTP fixes the issue - e.g.:

# cat /etc/gridftp.d/*
version_tag GCS-4.0.36
usage_stats_id GCS-4.0.36+centos-7.2.1511-64bit
port_range 50000,51000
data_interface 54.149.162.126
$GSI_AUTHZ_CONF "/etc/gridmap_verify_myproxy_callout-gsi_authz.conf"
$GRIDMAP "/etc/grid-security/grid-mapfile"
$GLOBUS_MYPROXY_CA_CERT "/var/lib/globus-connect-server/grid-security/certificates/6f1924ec.0"
$X509_USER_CERT "/var/lib/globus-connect-server/grid-security/hostcert.pem"
$X509_USER_KEY "/var/lib/globus-connect-server/grid-security/hostkey.pem"
log_single /var/log/gridftp.log
log_level ERROR,WARN
$X509_CERT_DIR "/var/lib/globus-connect-server/grid-security/certificates"

# systemctl restart globus-gridftp-server.service

Node 2 is now properly accessible.

globus-connect-server-setup failure on Ubuntu 18.04

Hi,
I got the following exception while trying to create endpoint with
sudo globus-connect-server-setup

Traceback (most recent call last):
  File "/usr/bin/globus-connect-server-setup", line 14, in <module>
    load_entry_point('globus-connect-server==4.0.59', 'console_scripts', 'globus-connect-server-setup')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 480, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2693, in load_entry_point
    return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2324, in load
    return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2330, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/globus/connect/server/__init__.py", line 36, in <module>
    from globus_sdk import (
  File "/usr/share/globus-connect-server-common/globus_sdk/__init__.py", line 3, in <module>
    from globus_sdk.auth import AuthClient, ConfidentialAppAuthClient, NativeAppAuthClient
  File "/usr/share/globus-connect-server-common/globus_sdk/auth/__init__.py", line 1, in <module>
    from globus_sdk.auth.client_types import (
  File "/usr/share/globus-connect-server-common/globus_sdk/auth/client_types/__init__.py", line 1, in <module>
    from globus_sdk.auth.client_types.base import AuthClient
  File "/usr/share/globus-connect-server-common/globus_sdk/auth/client_types/base.py", line 9, in <module>
    from globus_sdk.auth.token_response import OAuthTokenResponse
  File "/usr/share/globus-connect-server-common/globus_sdk/auth/token_response.py", line 5, in <module>
    import jwt
ModuleNotFoundError: No module named 'jwt'

I followed the instructions from here.

wrong GLOBUS_MYPROXY_AUTHORIZED_DN value generated in gsi-authz.conf when "[Security].CILogonIdentityProvider = University of Notre Dame" is set in gcs.conf

see https://globusonline.zendesk.com/agent/tickets/344865

Initially reported from and reproduced on GCS-4.0.50 RHEL7 systems.

gsi-authz.conf gets generated with GLOBUS_MYPROXY_AUTHORIZED_DN="/DC=org/DC=cilogon/C=US/C=US/O=University of Notre Dame" when "[Security].CILogonIdentityProvider = University of Notre Dame" is set in gcs.conf:

# cat /var/lib/globus-connect-server/gsi-authz.conf

|globus_mapping libglobus_gridmap_eppn_callout globus_gridmap_eppn_callout ENV:GLOBUS_MYPROXY_CA_CERT=/var/lib/globus-connect-server/grid-security/certificates/c2868627.0 GLOBUS_MYPROXY_AUTHORIZED_DN="/DC=org/DC=cilogon/C=US/C=US/O=University of Notre Dame"
|globus_mapping libglobus_gridmap_eppn_callout globus_gridmap_eppn_callout ENV:GLOBUS_MYPROXY_CA_CERT=/var/lib/globus-connect-server/grid-security/certificates/01b5d333.0 GLOBUS_MYPROXY_AUTHORIZED_DN="/DC=org/DC=cilogon/C=US/C=US/O=University of Notre Dame"

Note "/C=US/C=US/" rather than "/C=US/".

Issue prevented users from being able to access endpoint using their CILogon credentials. Fixing the DN value resolved the issue.

This does not happen when "[Security].CILogonIdentityProvider = University of Chicago" is set in gcs.conf:

# cat /var/lib/globus-connect-server/gsi-authz.conf

|globus_mapping libglobus_gridmap_eppn_callout globus_gridmap_eppn_callout ENV:GLOBUS_MYPROXY_CA_CERT=/var/lib/globus-connect-server/grid-security/certificates/c2868627.0 GLOBUS_MYPROXY_AUTHORIZED_DN="/DC=org/DC=cilogon/C=US/O=University of Chicago"
|globus_mapping libglobus_gridmap_eppn_callout globus_gridmap_eppn_callout ENV:GLOBUS_MYPROXY_CA_CERT=/var/lib/globus-connect-server/grid-security/certificates/01b5d333.0 GLOBUS_MYPROXY_AUTHORIZED_DN="/DC=org/DC=cilogon/C=US/O=University of Chicago"

globus-connect-server-setup generates SSL handshake failure during version check on RHEL 6, CentOS 6 and Ubuntu 14.04

User reports that running globus-connect-server-setup generates SSL handshake failure during version check on RHEL 6, see:

https://globusonline.zendesk.com/agent/tickets/309375

The error does not prevent globus-connect-server-setup from continuing with the rest of the GCS setup process.

This behavior has also been reproduced on CentOS 6 and Ubuntu 14.04.

# cat /etc/redhat-release 
CentOS release 6.9 (Final)

# yum -q list installed \*globus-connect-server\*
Installed Packages
globus-connect-server.noarch           4.0.46-1.el6+gt6    @Globus-Toolkit-6-el6
globus-connect-server-common.noarch    4.0.46-1.el6+gt6    @Globus-Toolkit-6-el6
globus-connect-server-id.noarch        4.0.46-1.el6+gt6    @Globus-Toolkit-6-el6
globus-connect-server-io.noarch        4.0.46-1.el6+gt6    @Globus-Toolkit-6-el6
globus-connect-server-web.noarch       4.0.46-1.el6+gt6    @Globus-Toolkit-6-el6

# globus-connect-server-setup 
Unable to get version info from: https://downloads.globus.org/toolkit/gt6/packages/GLOBUS_CONNECT_SERVER_LATEST
[Errno socket error] [Errno 1] _ssl.c:492: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Skipping version check.

# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.5 LTS
Release:	14.04
Codename:	trusty

# dpkg -l | grep .*globus-connect-server.*
ii  globus-connect-server                     4.0.46-1+gt6.trusty                        all          Globus Connect Server Installation Tool
ii  globus-connect-server-common              4.0.46-1+gt6.trusty                        all          Globus Connect Server Installation Tool
ii  globus-connect-server-id                  4.0.46-1+gt6.trusty                        all          Globus Connect Server Installation Tool
ii  globus-connect-server-io                  4.0.46-1+gt6.trusty                        all          Globus Connect Server Installation Tool
ii  globus-connect-server-web                 4.0.46-1+gt6.trusty                        all          Globus Connect Server Installation Tool

# globus-connect-server-setup 
Unable to get version info from: https://downloads.globus.org/toolkit/gt6/packages/GLOBUS_CONNECT_SERVER_LATEST
[Errno socket error] [Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Skipping version check.

How to build globus-connect-server for Solaris 10 or 11?

How to build globus-connect-server for Solaris 10 or 11?
Currently only Debian and Fedora flavors of linux are supported.

globus-connect-server-setup does not update CILogon cert CRL files in GridFTP trusted certs directory

globus-connect-server-setup does not update CILogon cert CRL files in GridFTP trusted certs directory. These CRL files get dropped down during the initial setup of an endpoint configured for CILogon activation, but subsequent executions of globus-connect-server-setup do not update the CRL files. When these files expire, endpoint user/admins encounter access errors complaining about the CRL files being expired that prevent endpoint access until the CRL files are removed or manually updated. Verified with GCS-4.0.46 on CentOS7. Also have ticket where behavior was observed with GCS-4.0.46 on CentOS6.

Upgrade to myproxy-oauth-0.26-1.el7+gt6.noarch deletes /etc/httpd/conf.d/wsgi-myproxy-oauth.conf

When upgrading from GCS with myproxy-oauth-0.25-1.el7+gt6.noarch or prior to myproxy-oauth-0.26-1.el7+gt6.noarch, the /etc/httpd/conf.d/wsgi-myproxy-oauth.conf file gets deleted thus breaking the MyProxy OAuth Delegation Service. The file can be recreated by running 'globus-connect-server-setup' again, but this requires intervention by the GCS admin. Reproduced by installing GCS with myproxy-oauth-0.25-1.el7+gt6.noarch on CentOS 7, configuring endpoint for OAuth based activation, and then updating to myproxy-oauth-0.26-1.el7+gt6.noarch.

Globus connect

Hi,
Is there a way to connect to an endpoint to run a command. I am looking for something like below;
ssh [email protected] --label "hello" user#endpoint echo "hello"

closed

globus-gridftp-server service breaks after yum update from Globus-Toolkit-6-Stable

On September 13 onwards, running our daily yum-cron updater breaks the globus-gridftp-server service. Using telnet per the troubleshooting suggested by the docs:

[root@dtn-transfer ~]# telnet 127.0.0.1 2811
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
[root@dtn-transfer ~]#

The yum update leaves behind a gridftp process running and globus-gridftp-server service fails.

[root@dtn-transfer ~]# pgrep -a gridftp
11545 /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 /
[root@dtn-transfer ~]# systemctl status globus-gridftp-server
● globus-gridftp-server.service - LSB: Globus GridFTP Server
   Loaded: loaded (/etc/rc.d/init.d/globus-gridftp-server; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2017-09-14 06:45:31 EDT; 5h 12min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 13095 ExecStop=/etc/rc.d/init.d/globus-gridftp-server stop (code=exited, status=203/EXEC)
  Process: 13097 ExecStart=/etc/rc.d/init.d/globus-gridftp-server start (code=exited, status=203/EXEC)
 Main PID: 11295 (code=exited, status=203/EXEC)
   CGroup: /system.slice/globus-gridftp-server.service
           └─11545 /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 /

Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Starting LSB: Globus GridFTP Server...
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: globus-gridftp-server.service: control process exited, code=exited status=203
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Failed to start LSB: Globus GridFTP Server.
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Unit globus-gridftp-server.service entered failed state.
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: globus-gridftp-server.service failed.
Warning: globus-gridftp-server.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[root@dtn-transfer ~]# journalctl -u globus-gridftp-server -u crond -S today | grep -v CRON | grep -v anacron
-- Logs begin at Fri 2017-08-18 01:44:50 EDT, end at Thu 2017-09-14 11:51:13 EDT. --
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-xio.x86_64 5.16-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-openssl-error.x86_64 3.8-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-sysconfig.x86_64 6.11-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-proxy-ssl.x86_64 5.10-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-openssl-module.x86_64 4.8-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-cert-utils.x86_64 9.16-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-callback.x86_64 5.13-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-credential.x86_64 7.11-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-proxy-core.x86_64 8.6-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gssapi-gsi.x86_64 12.17-3.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gss-assist.x86_64 10.21-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-xio-gsi-driver.x86_64 3.11-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-io.x86_64 11.9-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-ftp-control.x86_64 7.8-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-ftp-client.x86_64 8.36-1.1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gass-copy.x86_64 9.27-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-authz.x86_64 3.15-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-xio-udt-driver.x86_64 1.28-1.osg33.el7
Sep 14 06:45:30 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gridftp-server.x86_64 12.2-1.1.osg33.el7
Sep 14 06:45:31 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gridftp-server-progs.x86_64 12.2-1.1.osg33.el7
Sep 14 06:45:31 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gass-copy-progs.x86_64 9.27-1.osg33.el7
Sep 14 06:45:31 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-proxy-utils.x86_64 6.19-1.osg33.el7
Sep 14 06:45:31 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-xio-pipe-driver.x86_64 3.10-1.osg33.el7
Sep 14 06:45:31 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gsi-cert-utils-progs.noarch 9.16-1.osg33.el7
Sep 14 06:45:31 dtn-transfer.net.uconn.edu yum[8524]: Updated: globus-gss-assist-progs.noarch 10.21-1.osg33.el7
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Stopping LSB: Globus GridFTP Server...
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: globus-gridftp-server.service: control process exited, code=exited status=203
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Unit globus-gridftp-server.service entered failed state.
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: globus-gridftp-server.service failed.
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Starting LSB: Globus GridFTP Server...
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: globus-gridftp-server.service: control process exited, code=exited status=203
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Failed to start LSB: Globus GridFTP Server.
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: Unit globus-gridftp-server.service entered failed state.
Sep 14 06:45:31 dtn-transfer.net.uconn.edu systemd[1]: globus-gridftp-server.service failed.
[root@dtn-transfer ~]#

Yes, one should not be instead using globus-connect-server-setup to start the globus-gridftp-service, but after the packages are updated, that also fails:

[root@dtn-transfer ~]# pkill gridftp
[root@dtn-transfer ~]# globus-connect-server-setup 
Globus Id:  uconn
Password: 
Configured MyProxy server on dtn-transfer.net.uconn.edu:7512
CA DN: /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=920cfc6e-3e02-11e6-80c2-22000b1701d1
Service DN: /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=0b39aad2-9966-11e7-ac63-22000a92523b
Configured GridFTP server to run on dtn-transfer.net.uconn.edu
Server DN: /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=0c655500-9966-11e7-ac63-22000a92523b
Using Authentication Method MyProxy
Configured Endpoint dtn-transfer
[root@dtn-transfer ~]# telnet 127.0.0.1 2811
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
[root@dtn-transfer ~]#

Rolling back the update of 25 packages is a workaround (still trying to track narrow down which package(s) need to be masked):

[root@dtn-transfer ~]# yum history undo 155
...
[root@dtn-transfer ~]# globus-connect-server-setup 
Globus Id:  uconn
Password: 
Configured MyProxy server on dtn-transfer.net.uconn.edu:7512
CA DN: /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=920cfc6e-3e02-11e6-80c2-22000b1701d1
Service DN: /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=46e86cb2-9966-11e7-ac63-22000a92523b
Configured GridFTP server to run on dtn-transfer.net.uconn.edu
Server DN: /C=US/O=Globus Consortium/OU=Globus Connect Service/CN=47c21a16-9966-11e7-ac63-22000a92523b
Using Authentication Method MyProxy
Configured Endpoint dtn-transfer
[root@dtn-transfer ~]# telnet 127.0.0.1 2811
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 dtn-transfer.net.uconn.edu GridFTP Server 12.2 (gcc64, 1497977252-85) [Globus Toolkit 6.0.1488563530 GCS-4.0.45] ready.
^]
telnet> quit
Connection closed.
[root@dtn-transfer ~]#

Original transaction:

[root@dtn-transfer ~]# yum history info 155
Loaded plugins: fastestmirror, langpacks, priorities
Transaction ID : 155
Begin time     : Thu Sep 14 06:45:29 2017
Begin rpmdb    : 1067:2d0ab7ac34e0481b1b7d9a64b2cbd78079fa6ead
End time       :            06:45:32 2017 (3 seconds)
End rpmdb      : 1067:ab83de5e00597fadf0dba102a3b94bbc0cfbcb4b
User           : root <root>
Return-Code    : Success
Transaction performed with:
    Installed     rpm-4.11.3-21.el7.x86_64                      @base
    Installed     yum-3.4.3-150.el7.centos.noarch               @base
    Installed     yum-plugin-fastestmirror-1.1.31-40.el7.noarch @base
Packages Altered:
    Updated globus-authz-3.15-1.el7+gt6.x86_64                    @Globus-Toolkit-6-Stable
    Update               3.15-1.osg33.el7.x86_64                  @osg
    Updated globus-ftp-client-8.36-1.el7+gt6.x86_64               @Globus-Toolkit-6-Stable
    Update                    8.36-1.1.osg33.el7.x86_64           @osg
    Updated globus-ftp-control-7.8-1.el7+gt6.x86_64               @Globus-Toolkit-6-Stable
    Update                     7.8-1.osg33.el7.x86_64             @osg
    Updated globus-gass-copy-9.27-1.el7+gt6.x86_64                @Globus-Toolkit-6-Stable
    Update                   9.27-1.osg33.el7.x86_64              @osg
    Updated globus-gass-copy-progs-9.27-1.el7+gt6.x86_64          @Globus-Toolkit-6-Stable
    Update                         9.27-1.osg33.el7.x86_64        @osg
    Updated globus-gridftp-server-12.2-1.el7+gt6.x86_64           @Globus-Toolkit-6-Stable
    Update                        12.2-1.1.osg33.el7.x86_64       @osg
    Updated globus-gridftp-server-progs-12.2-1.el7+gt6.x86_64     @Globus-Toolkit-6-Stable
    Update                              12.2-1.1.osg33.el7.x86_64 @osg
    Updated globus-gsi-callback-5.13-1.el7+gt6.x86_64             @Globus-Toolkit-6-Stable
    Update                      5.13-1.osg33.el7.x86_64           @osg
    Updated globus-gsi-cert-utils-9.16-1.el7+gt6.x86_64           @Globus-Toolkit-6-Stable
    Update                        9.16-1.osg33.el7.x86_64         @osg
    Updated globus-gsi-cert-utils-progs-9.16-1.el7+gt6.x86_64     @Globus-Toolkit-6-Stable
    Update                              9.16-1.osg33.el7.noarch   @osg
    Updated globus-gsi-credential-7.11-1.el7+gt6.x86_64           @Globus-Toolkit-6-Stable
    Update                        7.11-1.osg33.el7.x86_64         @osg
    Updated globus-gsi-openssl-error-3.8-1.el7+gt6.x86_64         @Globus-Toolkit-6-Stable
    Update                           3.8-1.osg33.el7.x86_64       @osg
    Updated globus-gsi-proxy-core-8.6-1.el7+gt6.x86_64            @Globus-Toolkit-6-Stable
    Update                        8.6-1.osg33.el7.x86_64          @osg
    Updated globus-gsi-proxy-ssl-5.10-1.el7+gt6.x86_64            @Globus-Toolkit-6-Stable
    Update                       5.10-1.osg33.el7.x86_64          @osg
    Updated globus-gsi-sysconfig-6.11-1.el7+gt6.x86_64            @Globus-Toolkit-6-Stable
    Update                       6.11-1.osg33.el7.x86_64          @osg
    Updated globus-gss-assist-10.21-1.el7+gt6.x86_64              @Globus-Toolkit-6-Stable
    Update                    10.21-1.osg33.el7.x86_64            @osg
    Updated globus-gss-assist-progs-10.21-1.el7+gt6.x86_64        @Globus-Toolkit-6-Stable
    Update                          10.21-1.osg33.el7.noarch      @osg
    Updated globus-gssapi-gsi-12.17-1.el7+gt6.x86_64              @Globus-Toolkit-6-Stable
    Update                    12.17-3.osg33.el7.x86_64            @osg
    Updated globus-io-11.9-1.el7+gt6.x86_64                       @Globus-Toolkit-6-Stable
    Update            11.9-1.osg33.el7.x86_64                     @osg
    Updated globus-openssl-module-4.8-1.el7+gt6.x86_64            @Globus-Toolkit-6-Stable
    Update                        4.8-1.osg33.el7.x86_64          @osg
    Updated globus-proxy-utils-6.19-1.el7+gt6.x86_64              @Globus-Toolkit-6-Stable
    Update                     6.19-1.osg33.el7.x86_64            @osg
    Updated globus-xio-5.16-1.el7+gt6.x86_64                      @Globus-Toolkit-6-Stable
    Update             5.16-1.osg33.el7.x86_64                    @osg
    Updated globus-xio-gsi-driver-3.11-1.el7+gt6.x86_64           @Globus-Toolkit-6-Stable
    Update                        3.11-1.osg33.el7.x86_64         @osg
    Updated globus-xio-pipe-driver-3.10-1.el7+gt6.x86_64          @Globus-Toolkit-6-Stable
    Update                         3.10-1.osg33.el7.x86_64        @osg
    Updated globus-xio-udt-driver-1.28-1.el7+gt6.x86_64           @Globus-Toolkit-6-Stable
    Update                        1.28-1.osg33.el7.x86_64         @osg
history info
[root@dtn-transfer ~]#

GCS on RHEL6 derivatives pulls EOL Apache 2.2 as dependency during install

First noticed issue when troubleshooting ticket 308458.

Apache 2.4 is available via httpd24-httpd package provided by the RHEL6/CentOS6/Scientific6 SCL repos. However, this package doesn't seem to meet the httpd dependency that GCS has, and Apache 2.2 httpd package still gets pulled during a GCS install.

python3 error reading signing policy

One issue missed in our release testing was loading the sharing CA signing policies, which is resulting in a python backtrace.

globus-connect-server-setup fails when GCS is configured to use CILogon auth on CentOS 6

see https://globusonline.zendesk.com/agent/tickets/305699

User reports globus-connect-server-setup fails when attempting to configure GCS to use CILogon based auth on CentOS 6. Was able to reproduce issue on clean CentOS 6 image with GCS 4.0.35 - see below:

# python --version

Python 2.6.6

# grep -v "^$\|^;" /etc/globus-connect-server.conf

[Globus]
User = %(GLOBUS_USER)s
Password = %(GLOBUS_PASSWORD)s
[Endpoint]
Name = ticket305699 
Public = False
DefaultDirectory = /~/
[Security]
FetchCredentialFromRelay = True
IdentityMethod = CILogon
CILogonIdentityProvider = University of Chicago
[GridFTP]
Server = %(HOSTNAME)s
RestrictPaths =
[MyProxy]
[OAuth]

# globus-connect-server-setup -v

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/globus/connect/server/setup.py", line 132, in <module>
    conf = ConfigFile(config_file=conf_filename, root=root)
  File "/usr/lib/python2.6/site-packages/globus/connect/server/configfile.py", line 370, in __init__
    self.validate_cilogon_identity_provider()
  File "/usr/lib/python2.6/site-packages/globus/connect/server/configfile.py", line 405, in validate_cilogon_identity_provider
    % cilogon_idp)
  File "/usr/lib64/python2.6/xml/etree/ElementTree.py", line 330, in find
    return ElementPath.find(self, path)
  File "/usr/lib64/python2.6/xml/etree/ElementPath.py", line 186, in find
    return _compile(path).find(element)
  File "/usr/lib64/python2.6/xml/etree/ElementPath.py", line 176, in _compile
    p = Path(path)
  File "/usr/lib64/python2.6/xml/etree/ElementPath.py", line 93, in __init__
    "expected path separator (%s)" % (op or tag)
SyntaxError: expected path separator ([)

error: get() got an unexpected keyword argument 'raw'

When I try to run globus-connect-server-setup on an AWS EC2 Ubuntu machine I get the following error: get() got an unexpected keyword argument 'raw'. I thought it might be a problem with the python version used-- but it doesn't seem to work regardless of 2.7 or 3.5 and with multiple different installs.

globus-connect-server-setup fails when GCS is configured to use OAuth on RHEL 7.2

Discovered in:

https://globusonline.zendesk.com/agent/tickets/305945

NOTE: Issue does NOT show up on CentOS 7.2

GCS=4.0.36-1

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

# grep -v "^$\|^;" /etc/globus-connect-server.conf
[Globus]
User = %(GLOBUS_USER)s
Password = %(GLOBUS_PASSWORD)s
[Endpoint]
Name = %(SHORT_HOSTNAME)s
Public = False
DefaultDirectory = /~/
[Security]
FetchCredentialFromRelay = True
IdentityMethod = OAuth
[GridFTP]
Server = %(HOSTNAME)s
RestrictPaths =
[MyProxy]
Server = %(HOSTNAME)s
[OAuth]
Server = %(HOSTNAME)s

# globus-connect-server-setup -v

...

EXIT: GCMU.configure_trust_roots()
ENTER: GCMU.restart()
restarting with /etc/init.d/httpd restart
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/globus/connect/server/setup.py", line 138, in <module>
    web.setup()
  File "/usr/lib/python2.7/site-packages/globus/connect/server/web/__init__.py", line 108, in setup
    self.restart(**kwargs)
  File "/usr/lib/python2.7/site-packages/globus/connect/server/__init__.py", line 856, in restart
    restarter = Popen(args, stdin = None, stdout=PIPE, stderr=PIPE)
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

globus-connect-server-setup public_name() and public_ip() returning wrong values on specific non-ec2 system

see https://globusonline.zendesk.com/agent/tickets/345764

globus-connect-server-setup public_name() and public_ip() returning wrong values on specific non-ec2 system.

Admin's system is CentOS7 system not running on an ec2 instance. From the admin's system, a host 169.254.169.254 is reachable with a web server listening on port 80, and it returns 404s formatted like so:

# curl -v http://169.254.169.254/latest/meta-data/public-hostname
* About to connect() to 169.254.169.254 port 80 (#0)
* Trying 169.254.169.254...
* Connected to 169.254.169.254 (169.254.169.254) port 80 (#0)
> GET /latest/meta-data/public-hostname HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 169.254.169.254
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Length: 154
< Content-Type: text/html; charset=UTF-8
< Date: Thu, 02 May 2019 15:33:30 GMT
<
<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>404 Not Found</h1>
The resource could not be found.<br /><br />

</body>
* Connection #0 to host 169.254.169.254 left intact
</html>

The public_name() and public_ip() functions don't catch these 404 messages, causing the message contents to be dumped inappropriately into data_interface and defaults["HOSTNAME"].

The message gets dumped into data_interface if [GridFTP].DataInterface is not set in the gcs.conf file, causing it to show in the data_interface value in the /etc/gridftp.d/globus-connect-server file.

If "Server = %(HOSTNAME)s" is set, the message gets dumped into the server value for the service causing gcs-setup to fail like so:

Invalid value for Server in [GridFTP] section of /etc/globus-connect-server.conf: 404 Not Found

It was possible to work around the issue by having the admin set [GridFTP].DataInterface, [GridFTP].Server, and [MyProxy].Server to the appropriate FQDN hostname.