Giter Club home page Giter Club logo

gct's People

Contributors

bbockelm avatar bester avatar brianhlin avatar chrisburr avatar ellert avatar fscheiner avatar fweimer-rh avatar gridcf-owner avatar ianfoster avatar iwangjiaxiang avatar jaimefrey avatar jbasney avatar jthiltges avatar lukelatin avatar matyasselmeci avatar michaellink avatar msalle avatar mtru32 avatar okeeble avatar rubengarcia avatar sfiligoi avatar spbooth avatar stdweird avatar ysvenkat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gct's Issues

6.2.20190226 release in EPEL updates-testing?

Passing along a question I received from Derek Simmel:

Jim,

I was trying to install various parts from the current gct release today...

The webpage at https://github.com/gridcf/gct/releases/tag/v6.2.20190226 says that precompiled packages are available in the EPEL updates-testing repo:

• EPEL (for Red Hat Enterprise Linux, CentOS and Scientific Linux 6 and 7 (currently in EPEL updates-testing!))

but I can't seem to find where one gets the updates-testing repo from... the epel-testing repo does not have the most current packages in it.

Can you please direct me to where I may find the updates-testing repo?

Thanks -

  • Derek

gridftp failures between ipv4 client and dual-stack server

We have seen gridftp failures on sites with a dual-stack server and ipv4-only clients. In certain configurations (e.g. the new Dirac default), the client will use EPSV to get an IP address for the data connection. This returns an ipv6 address which, in a simple upload/download scenario, is unusable by the client.

While this behaviour is understandable (the client may be trying to establish a third-party transfer between two ipv6 capable servers) in reality it's causing problems.

We will provide a PR to give the option for EPSV to return an ipv4 address over an ipv4 connection.

Related DPM ticket : https://its.cern.ch/jira/browse/LCGDM-2817

bad test checking for default group [patch]

Hello, some build environments (e.g. launchpad builders) don't have a default group, so we have a failure in


ERROR: sharing_allowed_test
===========================

Unable to determine my default group nameERROR sharing_allowed_test (exit status: 99)

https://launchpadlibrarian.net/433273991/buildlog_ubuntu-eoan-amd64.globus-gridftp-server_13.11-2_BUILDING.txt.gz

we patched the source to not fail on that test...
Is it possible to have some upstream workaround or to disable that test?
this is the "patch"
http://launchpadlibrarian.net/433274011/globus-gridftp-server_13.11-2_13.11-2ubuntu1.diff.gz

--- globus-gridftp-server-13.8.orig/test/sharing_allowed_test.c
+++ globus-gridftp-server-13.8/test/sharing_allowed_test.c
@@ -128,7 +128,7 @@ int main()
     if (grent == NULL)
     {
         fprintf(stderr, "Unable to determine my default group name");
-        exit(99);
+        exit(77);
     }
     my_default_group = strdup(grent->gr_name);
     if (my_default_group == NULL)

fail to compiler gct-6.2 because of openssl

I compiled gct6.2 on redhat6.4 before, but it failed.

##uname -a
Linux ln4 2.6.32-358.123.4.el6.x86_64 #11 SMP Mon Jan 5 10:51:32 CST 2015 x86_64 x86_64 x86_64 GNU/Linux

##openssl
openssl-devel-1.0.0-27.el6.x86_64

##commands
autoreconf -i

./configure --enable-myproxy
--enable-gram5-{server,lsf,sge,slurm,condor,pbs,auditing}
--prefix=/THL7/home/globus/softs/gct-6.2

make

####################
step configure .

checking OpenSSL header version... 10000003 (OpenSSL 1.0.0 29 Mar 2010)
checking OpenSSL library version... configure: error: OpenSSL >= 1.0.1 required (have "10000003 (OpenSSL 1.0.0-fips 29 Mar 2010)")
configure: error: ./configure.gnu failed for gsi_openssh/source
#######################################

Then I tried to compiler openssl1.1.1l / openssl3.0 (and used env LD_LIBRARY_PATH,eg) ,
the error disapped but got other errors at step make.

###using openssl1.1.1l

verify_mic.c: 在函数‘globus_l_gss_verify_mic_new’中:
verify_mic.c:489: 错误:‘struct gss_ctx_id_desc_struct’没有名为‘mac_read_sequence’的成员
verify_mic.c:492: 错误:‘struct gss_ctx_id_desc_struct’没有名为‘mac_read_sequence’的成员
verify_mic.c:501: 错误:‘struct gss_ctx_id_desc_struct’没有名为‘mac_read_sequence’的成员
verify_mic.c:514: 错误:‘struct gss_ctx_id_desc_struct’没有名为‘mac_read_sequence’的成员
make[5]: *** [libglobus_gssapi_gsi_la-verify_mic.lo] 错误 1
make[5]: Leaving directory `/home/test/softs/pkgs/gct-github/gsi/gssapi/source/library'
make[4]: *** [all] 错误 2

####using openssl3.0
proxycertinfo.c:50: 错误:与‘PROXYCERTINFO_dup’类型冲突
proxycertinfo.h:155: 附注:‘PROXYCERTINFO_dup’的上一个声明在此
make[4]: *** [proxycertinfo.lo] 错误 1
make[4]: Leaving directory `/home/test/softs/pkgs/gctgithub/gct-github/gsi/proxy/proxy_ssl/source/library'
make[3]: *** [all-recursive] 错误 1

How to fix this error.Hope to get your help.

HPN-SSH not present in EPEL builds

Apologies in advance if you guys don't do the builds for EPEL. I have a question that I hope you can answer.

We recently deployed some data transfer nodes on CentOS 7.6 using the (at the time) latest available GCT packages in EPEL. It appears the gsi-openssh-server package that was installed (gsi-openssh-7.4p1-4.el7.x86_64) doesn't include the HPN patch - attempting to enable the feature in /etc/gsissh/sshd_config results in an error from gsisshd and the service refusing to start.

Oct 24 19:09:03 hdtn1 systemd: Starting Cluster Controlled gsisshd...
Oct 24 19:09:03 hdtn1 gsisshd: /etc/gsissh/sshd_config line 47: Deprecated option RSAAuthentication
Oct 24 19:09:03 hdtn1 gsisshd: /etc/gsissh/sshd_config line 56: Deprecated option RhostsRSAAuthentication
Oct 24 19:09:03 hdtn1 gsisshd: /etc/gsissh/sshd_config line 149: Unsupported option DisableUsageStats
Oct 24 19:09:03 hdtn1 gsisshd: /etc/gsissh/sshd_config: line 189: Bad configuration option: HPNDisabled
Oct 24 19:09:03 hdtn1 gsisshd: /etc/gsissh/sshd_config: line 196: Bad configuration option: HPNBufferSize
Oct 24 19:09:03 hdtn1 gsisshd: /etc/gsissh/sshd_config: terminating, 2 bad configuration options
Oct 24 19:09:03 hdtn1 systemd: gsisshd.service: main process exited, code=exited, status=255/n/a
Oct 24 19:09:03 hdtn1 systemd: Failed to start Cluster Controlled gsisshd.
Oct 24 19:09:03 hdtn1 systemd: Unit gsisshd.service entered failed state.
Oct 24 19:09:03 hdtn1 systemd: gsisshd.service failed.

I found #72 that references a discussion about dropping the HPN patch, but I can't find anything stating that this change was definitely made, and on what date that change was implemented.

Do you have any information on when HPN was removed from the EPEL package builds, and/or what was the last version that included HPN support?

UDT not working

Hello there,

I have been trying to use UDT with GridFTP for several days now and it doesn't work.

Both servers running Ubuntu 18.04.2 LTS.


  1. Downloaded GCT 6.2.20190226
  2. Configured with:
    ./configure --prefix=/home/USER/tools/gct62_selfcompiled --enable-udt --disable-gsi-openssh --disable-gram5 --disable-gsi
  3. Make:
    make ccommonlibs gridftp udt -j 16
  4. Install:
    make install
  5. Follow documentation -> Enabling Threading in GridFTP
  6. Start server:
~/tools/gct62_selfcompiled/sbin$ ./globus-gridftp-server -debug -dc-whitelist udt,gsi,tcp -threads 1 -allow-udt

Server listening at SERVER-IP:40899
  1. Start UDT transfer like mentioned here on Client:
~/tools/gct62_selfcompiled/bin$ ./globus-url-copy -dbg -udt file:/dev/zero sshftp://SERVER-IP/dev/null
debug: starting to put sshftp://SERVER-IP/dev/null
debug: connecting to sshftp://SERVER-IP/dev/null
debug: response from sshftp://SERVER-IP/dev/null:
220 SERVER-IP GridFTP Server 12.17 (gcc64, 1558548600-85) [Globus Toolkit 6.0.1558548600] ready.

debug: authenticating with sshftp://SERVER-IP/dev/null
debug: response from sshftp://SERVER-IP/dev/null:
230 User anonymous logged in.

debug: sending command to sshftp://SERVER-IP/dev/null:
SITE HELP

debug: response from sshftp://SERVER-IP/dev/null:
214-The following commands are recognized:
    ALLO    APPE    REST    CWD     CDUP    DCAU    EPSV    FEAT
    ERET    MDTM    STAT    ESTO    HELP    LIST    MODE    NLST
    MLSC    MLSD    PASV    RNFR    MLSR    MLST    NOOP    OPTS
    STOR    PASS    PBSZ    PORT    PROT    SITE    EPRT    RETR
    SPOR    MFMT    SCKS    TREV    PWD     QUIT    SBUF    SIZE
    SPAS    STRU    SYST    RNTO    TYPE    USER    LANG    MKD
    RMD     DELE    CKSM    DCSC
214 End

debug: sending command to sshftp://SERVER-IP/dev/null:
FEAT

debug: response from sshftp://SERVER-IP/dev/null:
211-Extensions supported
 DSI file-12.17
 STORATTR
 UPAS
 HTTP
 DCSC P,D
 MFMT
 WHOAMI
 AUTHZ_ASSERT
 MLSR
 MLSC
 UTF8
 LANG EN
 DCAU
 PARALLEL
 SIZE
 MLST Type*;Size*;Modify*;Perm*;Charset;UNIX.mode*;UNIX.owner*;UNIX.uid*;UNIX.group*;UNIX.gid*;Unique*;UNIX.slink*;X.count;
 ERET
 ESTO
 SPAS
 SPOR
 REST STREAM
 MDTM
 PASV AllowDelayed;
211 End.

debug: sending command to sshftp://SERVER-IP/dev/null:
SITE CLIENTINFO scheme=sshftp;appname="globus-url-copy";appver="10.4 (gcc64, 1550490409-0) [Globus Toolkit 6.0.1517984806]";
debug: response from sshftp://SERVER-IP/dev/null:
250 OK.

debug: sending command to sshftp://SERVER-IP/dev/null:
TYPE I
debug: response from sshftp://SERVER-IP/dev/null:
200 Type set to I.

debug: sending command to sshftp://SERVER-IP/dev/null:
PASV

debug: response from sshftp://SERVER-IP/dev/null:
227 Entering Passive Mode (xxx,xxx,xxx,xxx,230,137)

debug: sending command to sshftp://SERVER-IP/dev/null:
STOR /dev/null

debug: response from sshftp://SERVER-IP/dev/null:
150 Beginning transfer.

debug: writing buffer 0x7fe3828b4010, length 1048576, offset=0, eof=false
[...]

Netstat shows:

Every 1.0s: netstat -tupn

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp   1623720      0 SERVER-IP:43839     CLIENT-IP:50134     ESTABLISHED 30567/globus-gridft
[...]

ps-aux:

/home/USER/tools/gct62_selfcompiled/sbin/globus-gridftp-server -ssh -dc-whitelist udt,gsi,tcp -threads 1 -allow-udt -debug


Also tried configuring the files sshftp and gridftp.conf on the Server, still not successful.
Unfortunately it is always using TCP..

Seems installing GCT from epel repo contains no compiled excutable?

Hi guys, I tried to install lasted GCT softwares from EPEL repo.

However, the install packages didn't contains any compiled packages.

Are the packages all src rpm packages?

What is the best practice to install GCT from EPEL repo?


UPDATE

Environment

OS

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
KERNEL_VERSION="3.10.0-957.27.2.el7.x86_64"

The software I installed seems to be part of latest release GCT 6.2.20190906 (maintenance release)

Result of rpm -qa | grep globus:

globus-gsi-callback-6.1-1.el7.x86_64
globus-xio-pipe-driver-4.1-1.el7.x86_64
globus-gsi-openssl-error-4.1-1.el7.x86_64
globus-gssapi-gsi-14.11-1.el7.x86_64
globus-gssapi-error-6.1-1.el7.x86_64
globus-authz-4.3-1.el7.x86_64
globus-common-18.5-1.el7.x86_64
globus-openssl-module-5.1-1.el7.x86_64
globus-gsi-proxy-core-9.4-1.el7.x86_64
globus-proxy-utils-7.1-1.el7.x86_64
globus-xio-6.2-1.el7.x86_64
globus-ftp-control-9.4-1.el7.x86_64
globus-authz-callout-error-4.1-1.el7.x86_64
globus-gss-assist-progs-12.2-1.el7.noarch
globus-gridftp-server-13.20-1.el7.x86_64
globus-gsi-proxy-ssl-6.2-1.el7.x86_64
globus-gsi-credential-8.1-1.el7.x86_64
globus-gss-assist-12.2-1.el7.x86_64
globus-io-12.2-1.el7.x86_64
globus-xio-udt-driver-2.2-1.el7.x86_64
globus-gsi-sysconfig-9.2-3.el7.x86_64
globus-callout-4.2-1.el7.x86_64
globus-xio-gsi-driver-5.2-1.el7.x86_64
globus-gridftp-server-control-9.0-1.el7.x86_64
globus-gsi-cert-utils-10.3-1.el7.x86_64
globus-gfork-5.0-1.el7.x86_64
globus-gsi-cert-utils-progs-10.3-1.el7.noarch
globus-common-progs-18.5-1.el7.x86_64

Note that I didn't install GRAM5. I was testing GridFTP performance.

gsi-openssh silently fails to install if not running as root

I'm building the latest master on Debian because I wanted to get gsi-openssh working.

After running the following,

$ autoreconf --install --no-recursive
$ ./configure --prefix=$PWD/install --enable-gsi-openssh
$ make -j3
$ make -j3 install

I did not see gsissh in the ./install/bin directory. Note that I did not execute any of these commands with sudo because my install prefix is a local user directory and hence it should not be necessary.

I spotted the issue buried in the output of the make install run:

<trim>
./mkinstalldirs /home/phidica/Code/gct/install/share/man
./mkinstalldirs /home/phidica/Code/gct/install/share/man/man1
./mkinstalldirs /home/phidica/Code/gct/install/share/man/man5
./mkinstalldirs /home/phidica/Code/gct/install/share/man/man8
./mkinstalldirs /home/phidica/Code/gct/install/libexec
(umask 022 ; ./mkinstalldirs /var/empty)
mkdir /var/empty
mkdir: cannot create directory ‘/var/empty’: Permission denied
make[4]: *** [Makefile:346: install-files] Error 1
make[4]: Leaving directory '/home/phidica/Code/gct/gsi_openssh/source'
make[3]: *** [Makefile:2743: gsi-openssh-install] Error 2
<trim>

It appears that there is some call in the gsi-openssh install process that does not respect the install prefix I overrode with ./configure, and the install fails because it attempts to create /var/empty as a normal user.

I solved the problem by running sudo mkdir /var/empty and repeating the install.

I have two independent interpretations of what the "issue" to be solved here is:

  1. The gsi-openssh install process neglects to incorporate $prefix for this one directory, so it should instead attempt to create, eg, $prefix/var/empty.
  2. The failure of this component was silent and no advice was provided on how to resolve the problem, eg, bring the install to a halt and print "Couldn't create /var/empty. Do you lack superuser permissions?"

I believe that implementing either one of these, individually, would resolve this issue.

globus-url-copy fails during GSI handshake with dCache when using TLS v1.3

When testing with the current tip of gct master branch (commit 2217e6ec24) I cannot upload data to dCache.

I see the following error:

✔ 19:04:11 build [master …64] $ gass/copy/source/globus-url-copy file:///bin/bash gsiftp://localhost/public/test-1

error: globus_l_ftp_control_send_cmd_cb: gss_init_sec_context failed to generate output token

✘ 19:04:14 build [master …64] $ 

I've tested this will all currently supported versions of dCache: the problem is present (on my laptop) in all cases.

Note that the above command is statically built:

✘ 19:04:14 build [master …64] $ ldd gass/copy/source/globus-url-copy 
        not a dynamic executable
✘ 19:05:20 build [master …64] $ 

Therefore, it does not depends on external globus libraries (libglobus_*), making testing easier.

I ran git bisect run with a script that builds gct and runs the above globus-url-copy command. The run completed with the following output:

4e76b43b0e3cba64f61522444016ac462c3dc7ae is the first bad commit
commit 4e76b43b0e3cba64f61522444016ac462c3dc7ae
Author: Mattias Ellert <[email protected]>
Date:   Thu Mar 25 10:42:32 2021 +0100

    TLS v1.3 sends 2 session tokens after the handshake is completed
    We need to recieve them before continuing with the GSI proxy

 .../source/library/globus_gsi_gss_constants.h      |  2 +
 gsi/gssapi/source/library/init_sec_context.c       | 74 +++++++++++++++++++++-
 2 files changed, 75 insertions(+), 1 deletion(-)
bisect run success
✔ 18:12:08 gct [:b2e6edde3|BISECTING …4] $

Retrieved "hostkey.pem" seems to be undecrypted when installing from source

Hi guys.

I cloned latest GCT source 4b1ec65 and installed GCT using a non-root user gct to path /usr/local/gct6.

Configuring non-standard installation GCT instance was hard and I got stuck when launching globus-gatekeeper, which was caused by undecrypted hostkey.pem.

The error was:

GSS failed getting server credentials:
GSS Major Status: General failure
GSS Minor Status Error Chain:
globus_gsi_gssapi: Error with GSI credential
globus_gsi_gssapi: Error with gss credential handle
globus_credential: Valid credentials could not be found in any of the possible locations specified by the credential search order.
Valid credentials could not be found in any of the possible locations specified by the credential search order.
Attempt 1
globus_credential: Error reading host credential
globus_credential: Key is password protected: GSI does not currently support password protected private keys.
OpenSSL Error: pem_pkey.c:117: in library: PEM routines, function PEM_READ_BIO_PRIVATEKEY: bad password read
Attempt 2
globus_credential: Error reading proxy credential
globus_sysconfig: Could not find a valid proxy certificate file location
globus_sysconfig: Error with key filename
globus_sysconfig: File does not exist: /tmp/x509up_u1002 is not a valid file
Attempt 3
globus_credential: Error reading user credential
globus_credential: Key is password protected: GSI does not currently support password protected private keys.
OpenSSL Error: pem_pkey.c:117: in library: PEM routines, function PEM_READ_BIO_PRIVATEKEY: bad password read
Failure: GSS failed to get server credentials

Failed to start globus-gatekeeper

After long time search, I found solution from mail list Re: [gt-user] Problem with globus-gatekeeper by using command openssl rsa -in /etc/grid-security/hostkey.pem -out /etc/grid-security/hostkey.pem to remove the password.

It worked and I managed to launch globus-gatekeeper. I don't know if there would be more problems but it was a temporary work-around.

I don't know what exactly happened but the myproxy-retrieve command might be the root cause.

Hope you could give me some hints :D

Thanks

Release notes?

Dear people,

Are there any release notes? Currently it's very hard for me (as a non-developer) to see whether patch #155 has been released in this version:

[surfadvisors-ozweers@ui-02 ~]$ globus-url-copy -version
globus-url-copy: 10.9

Cheers,
Onno

Bug in /etc/init.d/globus-gridftp-server affects Pacemaker

I've found a bug in the init script for the GridFTP server in current versions of the globus-gridftp-server-progs RPM for RHEL 6. Not sure if that's been fixed in your fork, but I wanted to make you aware in case.

Whenever this script is run with the status option (/etc/init.d/globus-gridftp server status) the status is correctly reported, but the return code is always 0. This isn't a problem until someone tries to use Pacemaker to manage GridFTP services. The incorrect return code causes Pacemaker to always think the GridFTP service is running, so it never gets started.

The following hack makes the script return an exit value correctly when the status parameter is passed.

--- globus-gridftp-server.orig  2018-08-07 22:56:34.217826950 +0000
+++ globus-gridftp-server       2018-08-07 22:58:17.035903704 +0000
@@ -139,6 +139,7 @@
        ;;
     status)
        status
+       rc=$?
        ;;
     restart | force-reload)
        restart

Duplicate files warning in compilation time

Hi, I got the warning below when compile the latest release https://github.com/gridcf/gct/tree/v6.2.20190906

rm -rf doc
/home/user/app/gct-6.2.1567772254/common/source/test/globus_test_tap.h:5: warning: the name `globus_test_tap.h' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/common/source/test/globus_test_tap.h
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/test/globus_test_tap.h
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gsi/gssapi/source/library/read_vhost_cred_dir.c:18: warning: the name `read_vhost_cred_dir.c' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/gsi/gssapi/source/library/read_vhost_cred_dir.c
   /home/user/app/gct-6.2.1567772254/gsi/gss_assist/source/read_vhost_cred_dir.c
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gsi/gss_assist/source/read_vhost_cred_dir.c:18: warning: the name `read_vhost_cred_dir.c' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/gsi/gssapi/source/library/read_vhost_cred_dir.c
   /home/user/app/gct-6.2.1567772254/gsi/gss_assist/source/read_vhost_cred_dir.c
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gridftp/net_manager/attr/destroy.c:18: warning: the name `destroy.c' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/attr/destroy.c
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/context/destroy.c
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gridftp/net_manager/attr/init.c:18: warning: the name `init.c' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/gsi/gss_assist/source/init.c
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/attr/init.c
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/context/init.c
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gridftp/net_manager/context/destroy.c:18: warning: the name `destroy.c' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/attr/destroy.c
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/context/destroy.c
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gridftp/net_manager/context/init.c:18: warning: the name `init.c' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/gsi/gss_assist/source/init.c
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/attr/init.c
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/context/init.c
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gridftp/net_manager/test/globus_test_tap.h:5: warning: the name `globus_test_tap.h' supplied as the second argument in the \file statement matches the following input files:
   /home/user/app/gct-6.2.1567772254/common/source/test/globus_test_tap.h
   /home/user/app/gct-6.2.1567772254/gridftp/net_manager/test/globus_test_tap.h
Please use a more specific name by including a (larger) part of the path!
/home/user/app/gct-6.2.1567772254/gridftp/server/src/globus_gridftp_server.h:1551: warning: Member globus_i_gfs_error_system(int ftp_code, int system_errno, const char *fmt,...) (function) of file globus_gridftp_server.h is not documented.
make[2]: Leaving directory `/home/user/app/gct-6.2.1567772254'
make[1]: Leaving directory `/home/user/app/gct-6.2.1567772254'

Do you have any idea?

configure issue in ubuntu 16.04

After installing
autoconf automake make libtool libltdl-dev gcc g++ patch openssl libssl-dev pkg-config
following the install instructions,
configure gets:
.......
checking for netinet/tcp.h... yes
./configure: line 12398: syntax error near unexpected token GLOBUS_COMMON,' ./configure: line 12398: PKG_CHECK_MODULES(GLOBUS_COMMON, $PACKAGE_DEPS)'
configure: error: ./configure failed for xio/src

globus-gssapi-gsi and TLS 1.3

The upcoming openssl 1.1.1 adds support for TLS 1.3. However globus-gssapi-gsi is incompatible with TLS 1.3, as can be seen from the results of "make check".

See globus/globus-toolkit#123 for details.

Openssl 1.1.1 is available in Debian experimental.

Any TLS experts available to investigate?

globus-url-copy always delegates the X.509 credential

GSI is distinct from TLS in that it supports optional X.509 delegation as part of the handshake. Whether or not delegation takes place is controlled by the client. The globus-url-copy command is the client. By default, it delegates its credential to the server and there does not appear to be any (documented) way to disable this delegation.

At least for dCache (and likely other GridFTP servers, too), the delegated credential is just thrown away. Delegation is useless for GridFTP.

Beyond being pointless, delegation is actually problematic for a number of reasons:

  • It creates unnecessary load on the server, which must "generate" large prime numbers when the client requests delegation.
  • Delegation is a potential security risk, so should only be done if needed
  • The extra communication between the client and server also slows down the handshake process, making the protocol seem slower.

My suggestion would be to modify globus-url-copy so that either:

  • it never delegates,
  • or expose/document how the delegation decision may be controlled, and update globus-url-copy so it does not delegate by default.

External dependency on Globus GSI-OpenSSH

GCT has an external dependencies on Globus GSI-OpenSSH based on OpenSSH 7.5p1 dating from 2017-06-27. These patches are pulled in by default if a manual source build is performed. See "prep-gsissh" in the source tarball.

Is there a plan to include up to date GCT supported GSI-OpenSSH versions of these patches? Or to change the build process to remove these patches?

gsi-openssh for Debian

For 7.5 I managed to compile a debian package for gsi-openssh by omitting part of the patches given in packaging/debian/gsi-openssh/debian/patches/series (because they were redundant anyway). I see those patches are still there and
make gsi-openssh-deb
still doesn't work straight away.
Maybe someone feels like fixing this..

Documentation about config files is confusing

Hello,

The docs (e.g., https://gridcf.org/gct-docs/6.2/gridftp/admin/index.html#gridftp-config-overview), but also the man page says:

The configuration file for the GridFTP server is read from the following locations, in the given order. Only the first file found will be loaded:

* Path specified with the -c <configfile> command line option.
* $GLOBUS_LOCATION/etc/gridftp.conf
* /etc/grid-security/gridftp.conf

Which creates a false impression that if $GLOBUS_LOCATION is not defined, /etc/gridftp.conf will be read. But in fact it isn't the case:

tmp_gl = getenv("GLOBUS_LOCATION");
if(tmp_gl)
{
rc = snprintf(tmp_str, PATH_MAX, "%s/etc/gridftp.conf", tmp_gl);
if(rc > 0)
{
local_config_file = tmp_str;
}
}

Later, local_config_file does become (typically) /etc/gridftp.conf:

if(local_config_file == NULL && !argv_only)
{
globus_eval_path("${sysconfdir}/gridftp.conf", &local_config_file);
}

However, this is only used for setting environment

rc = globus_l_gfs_config_load_envs_from_file(local_config_file);

But contrary to global_config_file, it is NOT parsed by globus_l_gfs_config_load_config_file().

Most confusing, in the log gridftp then happily reports that /etc/gridftp.conf was used...

Regards,
Evgeny

Add instructions on how to make a release

We should have instructions on the procedure to make a GCT release including:

  • Policy for how to decide when to make the release (ask the list?)
  • Tagging
  • Making builds for downstream distributions:
    • Debian
    • EPEL, Fedora
    • SUSE
  • Release vote for the PMC
  • Which files to update (autoconf files?)

Issue with log trasfer file GCT 6.2

Dear support,

in our cluster we are using version 6.2 of GCT. Even if we have configured both the "log_single" and "log_transfer" files, and, the "log_level" is ALL, when a transfer is performed, the log_transfer file remains empty.
Could you please help us to solve this issue?
Do you need other info?

Best regards,

Francesco

gct fails to build with Python 3.8

Currently on Fedora we are testing rebuilding the distro against Python 3.8 and the net manager is one of the packages that failed to build from source.

This happens when the --enable-python option is given, due to python3-config --libs invocation requiring also the --embed flag, with Python 3.8, in order to link the application to libpython.

As this is applicable only for 3.8, using the same flag on lesser versions will make the compilation fail as well, so a conditional would be required there. More info.

Full build log attached
build.log.gz

`guc -dcpriv` does not work when talking to dCache

Globus Toolkit has a security vulnerability: when globs-url-copy -dcpriv is specified, and connecting to a dCache instance (which does not support data channel privacy), globus-url-copy silently decides to send the data in plain text anyway. The user is not warned and may assume the data is transferred privately while in fact it is not.

A bug report is here: https://github.com/globus/globus-toolkit/issues/121

Is this bug present in GCT too?

Kind regards,
Onno

Can't install gct-toolkit release gct-6.2.20210826

I tried to install the GCT following this guide for Ubuntu 20.04 and I downloaded the package from here because the given link in the guide doesn't work.

So, I installed it and then I ran:

sudo apt-get update
sudo apt-get install globus-gridftp globus-gram5 globus-gsi myproxy myproxy-server myproxy-admin

But it shows:

E: Failed to locate package globus-gridftp
E: Failed to locate package globus-gram5
E: Failed to locate globus-gsi package

So, I tried to install the toolkit from the source, I did the following steps:

  1. Download the source
  2. Run tar -xzvf gct-6.2.20210826.tar.gz
  3. Run autoreconf -i

I already installed all the prerequisites described in the INSTALL.md file.
But when I run the step 3, it shows a big error such as:

/usr/bin/m4:configure.ac:23: cannot open `globus-version.inc': No such file or directory
Unable to update dirt.sh
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
./packaging/git-dirt-filter: 8: cannot open /branch.def: No such file
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or no parent at mount point /)
...
...
...
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
./packaging/git-dirt-filter: 8: cannot open /branch.def: No such file
fatal: not a git repository (or no parent at mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
+ cat
/usr/bin/m4:configure.ac:34: cannot open `gct-current-tag.inc': No such file or directory
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

What am I doing wrong?
I really appreciate any help.

tarballs on repo.gridcf.org

Wrong content type

All tarballs seem to have a wrong content type:

wrong-content-type-for-tarballs

...which makes the web browser trying to display them instead of downloading them. I think this also makes a problem when downloading them via "Save link as...", as the SHA512 hash for the resulting downloaded file differs from the hash value that is served from repo.gridcf.org:

$ sha512sum globus_authz-4.1.tar.gz 
bed65b664a0b00d24753a78ab7a088dd100d0b4db8c6a6be75b22f063f0c9706c200894557f409b2e63af4afef46bd5747ec37b59efda09b1de02e355f7fc04a  globus_authz-4.1.tar.gz

$ cat globus_authz-4.1.tar.gz.sha512 
b86a6f897e75b5389dea6b080bb7b01e78014a2a57b17f4793a6a34e0634e344c259cbe9a8bf0bf8411f747c9b429b6a92c3581e4a9fd0049a1653217c2b76e0  globus_authz-4.1.tar.gz

$ sha512sum -c globus_authz-4.1.tar.gz.sha512
globus_authz-4.1.tar.gz: FAILED
sha512sum: WARNING: 1 computed checksum did NOT match

HTTP version of download site

Is there still a need for the HTTP version, because if not, I'd recommend to redirect to the HTTPS version instead to avoid any unwanted insecure downloads.

globus-gridftp-server authentication broken?

Hello,

On September 17 yum installed a globus gridftp server update:
globus-gridftp-server-13.20-1.el6.x86_64
Since then, all transfers fail with
530 530-Login incorrect. : globus_gss_assist: Error invoking callout
530-globus_callout_module: The callout returned an error
530-an unknown error occurred
530 End.

There is no information whatsoever in the logs (and the logs don't rotate anymore). The start of the log doesn't say anything about trying to read the gridmap-file. (I cannot tell if this was in the old version as that had run for too long for things to still be in the logs.)

I don't even know where to start. This is rather urgent.

Thanks,

Gustaaf

[BUG] GRAM job manager error because of the non-standard installation path "\"

Description

Hello dear developers,

This is a bug that occurs when use the non-standard installation path (not \).

I tried to compile and install GCT on a custom path (not standard path \) but I got errors when running globus-job-run. The error looks like below:

GRAM Job failed because the job manager detected an invalid script status (error code 25)

Reproduction

Just compile and install GCT to a custom path and run globus-job-run after proper configuration.

Research

After referring the official doc I found more details:

Error Code Reason Possible Solutions
25 the job manager detected an invalid script status Check job manager logs. This is likely a bug in the LRM script.

I followed the doc to diagnose LRM error. When I run the command globus-job-manager-script.pl -h, I got nothing on Installed managers.

According to the globus-job-manager-script.pl perl script, -h option should have listed all install LRM managers but I got nothing. The relative code is as below:

if ($help)
{
    my $managers;
    print "USAGE: $0 -m MANAGER -f FILE -c COMMAND\n";
    print "Installed managers:";
    foreach (<$perlmoduledir/Globus/GRAM/JobManager/*.pm>)
    {
        my $manager = $_;
        chomp($manager);
        $manager =~ s|.*/||;
        $manager =~ s|\.pm$||;
        print " $manager";
    }
    print "\n";
    exit(0);
}

After more review of the script, I found the reason was the $perlmoduledir variable which should have correct path but not (the value was just /perl). That's because the initialization of $perlmoduledir needs to contain the value of $libdir` as the code below.

$perlmoduledir = "${libdir}/perl";

However, the $libdir is defined but a value is never assigned to it. So the $perlmoduledir would never get correct path to locate LRM scripts.

Reason

$perlmoduledir not properly assigned because of un-assigned variable $libdir.

I checked line 49 in the source file and the code is $perlmoduledir = "@perlmoduledir@";. This mighit be fixed in the initialization of GCT installation.

Solution

For now my workaround is manually assigning the lib directory to $libdir before the assignment of $perlmoduledir in the file globus-job-manager-script.pl. Just like below:

...
$libdir = "/path/to/globus/lib";
$perlmoduledir = "${libdir}/perl";
...

Hope this could help~

Logging each transfer info into separated file no longer supported?

We were used to keep separated all the gridftp server's transfer info with -log-transfer option.
But it seems that latest releases have removed this feature because the transfer log file remains empty.
Can you confirm this or -log-transfer option should it still work?

[Discussion] Confused about the mechanism of LRM adapter

Hi, everyone. I'm confused about the mechanism of LRM adapter.

As we know, Local Resource Manager(LRM) adapter is the bridge between GCT and local batch system such as PBS, Slurm, etc.. When I tried to use PBS batch system with Globus LRM for PBS in a grid, I found
the globus-job-get-output cmd didn't work after the job was done. Below is the output:

/var/spool/pbs/mom_priv/jobs/128.pbsserver.SC: line 30: /home/globususer/.globus/.gass_cache/local/md5/b0/1977efe2641d7d7125768fae62a986/md5/8e/68009ac6a0caf05dc69d88b3884d51/data: No such file or directory

My cluster environment is
1 PBS master node with Globus LRM adapter (only managing and scheduling jobs)
8 PBS computing nodes (only executing jobs)
All of them are running on CentOS7

Why it happenned? I thought it was just a bug. But it turned out a 'feature' of LRM Adapter after my research. XD

The reason why I got errors is because when I run globus-job-get-output, the LRM Adapter would submit a new fetch job to LRM such as PBS to fetch the output file, which would be executed on computing node. So that is the problem. My master node holding the job output files was set not to execute jobs and the computing node executing the fetch job didn't hold any output files...

So I am wondering why the mechanism of Globus LRM Adapter is like that (by submitting new fetch job) ? Why not just read the local output files on master node? Is there an elegant way to use the mechanism?

Thank you.

fail to globus-job-run becasue of no permission to access tmp directory on execution node

I tried command “”globus-job-run node100/jobmanager-fork-poll -np 1 /bin/hostname “ and get an error .

I tried add "export TMPDIR=/home/puser3/tmp" to .bashrc /script for globus-gatekeepr /config file for globus-gatekeeper ,
but it didn't work .
How to fix it ? Hope to get your help.

##error
GRAM Job submission failed because the gatekeeper failed to run the job manager (error code 47)

##user to do the job
puser3

##globus-gatekeepr.log on node100
PID: 26461 -- Notice: 5: Authorized as local user: puser3
TIME: Thu Mar 17 09:32:00 2022
PID: 26461 -- Notice: 5: Authorized as local uid: 1002
TIME: Thu Mar 17 09:32:00 2022
PID: 26461 -- Notice: 5: and local gid: 1002
TIME: Thu Mar 17 09:32:00 2022
PID: 26461 -- Notice: 0: executing /usr/sbin/globus-job-manager
Failure: Unable to create http body tmpfile
TIME: Thu Mar 17 09:32:00 2022
PID: 26461 -- Failure: Unable to create http body tmpfile

globus-url-copy ignores GLOBUS_HOSTNAME; request to document GLOBUS_FTP_CLIENT_DATA_IP

On a machine behind NAT, GLOBUS_HOSTNAME can normally be used to indicate the external IP to connect to. But globus-url-copy is sending the wrong IP to the server:

/usr/local/globus-6/bin/globus-url-copy -vb -fast ftp://sunn-dtn.es.net:2811/data1/10G.dat file:///tmp/test.out
Source: ftp://sunn-dtn.es.net:2811/data1/
Dest: file:///tmp/
10G.dat -> test.out

        0 bytes         0.00 MB/sec avg         0.00 MB/sec inst

error: globus_ftp_client: the server responded with an error
500 500-Command failed. : globus_gridftp_server_file.c:globus_l_gfs_file_server_write_cb:3163:
500-callback failed.
500-globus_xio_tcp_driver.c:globus_l_xio_tcp_system_connect_cb:2022:
500-Unable to connect to 192.168.128.90:35309
500-globus_xio_system_select.c:globus_l_xio_system_handle_write:1108:
500-System error in connect: Network is unreachable
500-globus_xio: A system call failed: Network is unreachable
500 End.

export GLOBUS_HOSTNAME=138.246.234.17
/usr/local/globus-6/bin/globus-url-copy -vb -fast ftp://sunn-dtn.es.net:2811/data1/10G.dat file:///tmp/test.out
Source: ftp://sunn-dtn.es.net:2811/data1/
Dest: file:///tmp/
10G.dat -> test.out

        0 bytes         0.00 MB/sec avg         0.00 MB/sec inst

error: globus_ftp_client: the server responded with an error
500 500-Command failed. : globus_gridftp_server_file.c:globus_l_gfs_file_server_write_cb:3163:
500-callback failed.
500-globus_xio_tcp_driver.c:globus_l_xio_tcp_system_connect_cb:2022:
500-Unable to connect to 192.168.128.90:53139
500-globus_xio_system_select.c:globus_l_xio_system_handle_write:1108:
500-System error in connect: Network is unreachable
500-globus_xio: A system call failed: Network is unreachable
500 End.

/usr/local/globus-6/bin/globus-hostname
138.246.234.17

globus-gridftp, globus-gram5 and globus-gsi not found

I follow the quick start to install globus toolkit, and find that link http://www.globus.org/ftppub/gt6/installers/repo/globus-toolkit-repo-latest.noarch.rpm does not exist any more. so I download it from https://downloads.globus.org/toolkit/gt6/stable/installers/repo/rpm/globus-toolkit-repo-latest.noarch.rpm, but when I run

yum install globus-gridftp globus-gram5 globus-gsi myproxy myproxy-server myproxy-admin

it shows error.
...
No match for argument: globus-gridftp
No match for argument: globus-gram5
No match for argument: globus-gsi

Does any one can tell me what's wrong? thanks in advance.

Issue with frontend/backend daemon setup. Connection and authorization OK but transfer pending forever..

Hi Grid community,

I'm trying to install Gridtfp on a dedicated server for the Euxdat H2020 research project.

I have a configuration with a frontend and a backend running on the same server. The frontend daemon (running as globus) is exposed to the outside on port udp:2811. The backend (running as root) accepts connections on localhost:2813 from the frontend. All inbound connections are allowed by the host over TCP:20000-25000.

When I try to list from an outside client with a registered user "euxdat_user"
globus-url-copy -dbg -list gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/

The client connects, authorizes but is pending forever when trying to execute the data transfer or list the folder.

At the server level we see that the frontend received the request, forked, and established connection with the client and the backend. The backend has opened a tcp port to receive the data to the outside.

[root@gridftp-s1 grid-security]# netstat -apnt | grep globus

tcp 0 0 0.0.0.0:2811 0.0.0.0:* LISTEN 3657/globus-gridftp
tcp 0 0 0.0.0.0:21795 0.0.0.0:* LISTEN 9279/globus-gridftp
tcp 0 0 192.168.1.101:2811 80.158.4.251:44832 ESTABLISHED 9278/globus-gridftp
tcp6 0 0 ::1:2813 :::* LISTEN 3649/globus-gridftp
tcp6 0 0 ::1:20688 ::1:2813 ESTABLISHED 9278/globus-gridftp
tcp6 0 0 ::1:2813 ::1:20688 ESTABLISHED 9279/globus-gridftp

server

And nothing happens. I do not have additional info in the logs. Have you ever seen this kind of problem? Where can I go from there for further debugging?

Thanks you in advance for any help,
Ugo

Full client log:

globus-url-copy -dbg -list gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/

gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/
debug: starting to feat gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/
debug: connecting to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/
debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
220 gridftp-s1.euxdat.eu GridFTP Server 13.20 (gcc64, 1566483868-0) [Grid Community Toolkit 6.2] ready.

debug: authenticating with gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/
debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
230 User euxdat_user logged in.

debug: sending command to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
SITE HELP

debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
214-The following commands are recognized:
ALLO APPE REST CWD CDUP DCAU EPSV FEAT
ERET MDTM STAT ESTO HELP LIST MODE NLST
MLSC MLSD PASV RNFR MLSR MLST NOOP OPTS
STOR PASS PBSZ PORT PROT SITE EPRT RETR
SPOR MFMT SCKS TREV PWD QUIT SBUF SIZE
SPAS STRU SYST RNTO TYPE USER LANG MKD
RMD DELE CKSM DCSC
214 End

debug: sending command to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
FEAT

debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
211-Extensions supported
DSI remote-13.20
STORATTR
HTTP
DCSC P,D
MFMT
WHOAMI
AUTHZ_ASSERT
MLSR
MLSC
UTF8
LANG EN
DCAU
PARALLEL
SIZE
MLST Type*;Size*;Modify*;Perm*;Charset;UNIX.mode*;UNIX.owner*;UNIX.uid*;UNIX.group*;UNIX.gid*;Unique*;UNIX.slink*;X.count;
ERET
ESTO
SPAS
SPOR
REST STREAM
MDTM
PASV AllowDelayed;
211 End.

debug: sending command to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
SITE CLIENTINFO scheme=gsiftp;appname="globus-url-copy";appver="10.5 (gcc64, 1566483868-0) [Grid Community Toolkit 6.2]";
debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
250 OK.

debug: operation complete
debug: starting to machine list gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/
debug: sending command to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
TYPE I
debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
200 Type set to I.

debug: sending command to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
PBSZ 1048576

debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
200 PBSZ=1048576

debug: sending command to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
PASV

debug: response from gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
227 Entering Passive Mode (127,0,0,1,86,255)

debug: sending command to gsiftp://gridftp-s1.euxdat.eu/home/euxdat_user/:
MLSD /home/euxdat_user/

Frontend log:

[9278] Tue Mar 3 13:49:00 2020 :: GFork functionality not enabled.:
globus_gfork: GFork error: Env not set

[9278] Tue Mar 3 13:49:00 2020 :: Configuration read from /etc/gridftpd/gridftpd_frontend.conf.
[9278] Tue Mar 3 13:49:00 2020 :: Server started in inetd mode.
[9278] Tue Mar 3 13:49:00 2020 :: New connection from: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: USER :globus-mapping:
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 331 Password required for :globus-mapping:.
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: PASS
[9278] Tue Mar 3 13:49:00 2020 :: [globus_l_gfs_default_brain_select_nodes
] enter[9278] Tue Mar 3 13:49:00 2020 :: DN /O=Grid/OU=GlobusTest/OU=gridftp-s1.euxdat.eu/OU=Euxdat Cloud GridFTP CA/CN=Euxdat User successfully authorized.
[9278] Tue Mar 3 13:49:00 2020 :: User euxdat_user successfully authorized.
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: PASS
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 230 User euxdat_user logged in.
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: SITE HELP
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 214-The following commands are recognized:
ALLO APPE REST CWD CDUP DCAU EPSV FEAT
ERET MDTM STAT ESTO HELP LIST MODE NLST
MLSC MLSD PASV RNFR MLSR MLST NOOP OPTS
STOR PASS PBSZ PORT PROT SITE EPRT RETR
SPOR MFMT SCKS TREV PWD QUIT SBUF SIZE
SPAS STRU SYST RNTO TYPE USER LANG MKD
RMD DELE CKSM DCSC
214 End
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: FEAT
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 211-Extensions supported
DSI remote-13.20
STORATTR
HTTP
DCSC P,D
MFMT
WHOAMI
AUTHZ_ASSERT
MLSR
MLSC
UTF8
LANG EN
DCAU
PARALLEL
SIZE
MLST Type*;Size*;Modify*;Perm*;Charset;UNIX.mode*;UNIX.owner*;UNIX.uid*;UNIX.group*;UNIX.gid*;Unique*;UNIX.slink*;X.count;
ERET
ESTO
SPAS
SPOR
REST STREAM
MDTM
PASV AllowDelayed;
211 End.
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: SITE CLIENTINFO scheme=gsiftp;appname="globus-url-copy";appver="10.5 (gcc64, 1566483868-0) [Grid Community Toolkit 6.2]";
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 250 OK.
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: TYPE I
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 200 Type set to I.
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: PBSZ 1048576
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 200 PBSZ=1048576
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: PASV
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [SERVER]: 227 Entering Passive Mode (127,0,0,1,85,35)
[9278] Tue Mar 3 13:49:00 2020 :: ecs-80-158-4-251.reverse.open-telekom-cloud.com:44832: [CLIENT]: MLSD /home/euxdat_user/

Backend log:

[9279] Tue Mar 3 13:49:00 2020 :: GFork functionality not enabled.:
globus_gfork: GFork error: Env not set

[9279] Tue Mar 3 13:49:00 2020 :: Configuration read from /etc/gridftpd/gridftpd_backend_#1.conf.
[9279] Tue Mar 3 13:49:00 2020 :: Server started in inetd mode.
[9279] Tue Mar 3 13:49:00 2020 :: New connection from: localhost:20688

OS version:

CentOS Linux release 7.7.1908 (Core)

Package versions:

globus-authz.x86_64 4.3-1.el7 @epel
globus-authz-callout-error.x86_64 4.1-1.el7 @epel
globus-callout.x86_64 4.2-1.el7 @epel
globus-common.x86_64 18.5-1.el7 @epel
globus-common-devel.x86_64 18.5-1.el7 @epel
globus-common-progs.x86_64 18.5-1.el7 @epel
globus-ftp-client.x86_64 9.2-1.el7 @epel
globus-ftp-control.x86_64 9.4-1.el7 @epel
globus-gass-copy.x86_64 10.5-1.el7 @epel
globus-gass-copy-progs.x86_64 10.5-1.el7 @epel
globus-gass-transfer.x86_64 9.1-1.el7 @epel
globus-gfork.x86_64 5.0-1.el7 @epel
globus-gridftp-server.x86_64 13.20-1.el7 @epel
globus-gridftp-server-control.x86_64
globus-gridftp-server-progs.x86_64 13.20-1.el7 @epel
globus-gsi-callback.x86_64 6.1-1.el7 @epel
globus-gsi-cert-utils.x86_64 10.3-1.el7 @epel
globus-gsi-credential.x86_64 8.1-1.el7 @epel
globus-gsi-openssl-error.x86_64 4.1-1.el7 @epel
globus-gsi-proxy-core.x86_64 9.4-1.el7 @epel
globus-gsi-proxy-ssl.x86_64 6.2-1.el7 @epel
globus-gsi-sysconfig.x86_64 9.2-3.el7 @epel
globus-gss-assist.x86_64 12.2-1.el7 @epel
globus-gssapi-error.x86_64 6.1-1.el7 @epel
globus-gssapi-gsi.x86_64 14.11-1.el7 @epel
globus-io.x86_64 12.2-1.el7 @epel
globus-openssl-module.x86_64 5.1-1.el7 @epel
globus-xio.x86_64 6.2-1.el7 @epel
globus-xio-gsi-driver.x86_64 5.2-1.el7 @epel
globus-xio-pipe-driver.x86_64 4.1-1.el7 @epel
globus-xio-popen-driver.x86_64 4.1-1.el7 @epel
globus-xio-udt-driver.x86_64 2.2-1.el7 @epel

GSI configuration:

MIN_TLS_PROTOCOL=TLS1_VERSION_DEPRECATED
MAX_TLS_PROTOCOL=0
NAME_COMPATIBILITY=STRICT_RFC2818
CIPHERS=HIGH
SERVER_CIPHER_ORDER=true
BACKWARD_COMPATIBLE_MIC=true
ACCEPT_BACKWARD_COMPATIBLE_MIC=true
VHOST_CRED_OWNER=root

Frontend started as "globus" with:

/usr/sbin/globus-gridftp-server -c /etc/gridftpd/gridftpd_frontend.conf -C /etc/gridftpd/gridftpd_frontend.conf.d -exec /usr/sbin/globus-gridftp-server -pidfile /var/run/gridftpd/gridftpd_frontend.pid -hostname gridftp-s1.euxdat.eu -port 2811 -remote-nodes gridftp-s1.euxdat.eu:2813 -logfile /var/log/gridftpd/gridftpd_frontend.log -log-transfer /var/log/gridftpd/gridftpd_frontend.netlog -no-detach -config-base-path /

Frontend configuration:

daemon 1
auth_level 0
log_filemode 0644
disable_usage_stats 1
blocksize 16M
control_interface 0.0.0.0
ipc_interface 127.0.0.1

Backend started as "root" with:

/usr/sbin/globus-gridftp-server -c /etc/gridftpd/gridftpd_backend_#1.conf -C /etc/gridftpd/gridftpd_backend_#1.conf.d -exec /usr/sbin/globus-gridftp-server -pidfile /var/run/gridftpd/gridftpd_backend_#1.pid -hostname gridftp-s1.euxdat.eu -port 2813 -ipc-allow-from gridftp-s1.euxdat.eu -logfile /var/log/gridftpd/gridftpd_backend_#1.log -log-transfer /var/log/gridftpd/gridftpd_backend_#1.netlog -no-detach -config-base-path /

Backend configuration:

daemon 1
auth_level 2
log_level ALL
log_filemode 0644
disable_usage_stats 1
data_node 1
blocksize 16M

System level config:

GRIDFTPD_BIN="/usr/sbin/globus-gridftp-server"
GRIDFTPD_LD_LIBRARY_PATH="/usr/sbin/../lib"
GLOBUS_LOCATION="/usr/sbin/.."
GRIDFTPD_PIDFILES_PATH="/var/run/gridftpd"
GRIDFTPD_CONFIG_BASE_PATH="/etc/gridftpd"

GRIDFTPD_HOST_FQDN="gridftp-s1.euxdat.eu"
GRIDFTPD_TCP_PORT_RANGE="20000,25000"
GRIDFTPD_TCP_SOURCE_RANGE="20000,25000"

GRIDFTPD_GSI_CONFIG_BASE_PATH="/etc/grid-security"
GRIDFTPD_GRIDMAPFILE="/etc/grid-security/grid-mapfile"
GRIDFTPD_X509_CERT_DIR="/etc/grid-security/certificates"

Compiling on ArchLinux?

Did anyone manage to compile the toolkit on ArchLinux? The autoreconf -i is stuck in an infinite loop of these message:

libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:12: installing 'build-aux/compile'
configure.ac:12: installing 'build-aux/config.guess'
configure.ac:12: installing 'build-aux/config.sub'
configure.ac:11: installing 'build-aux/install-sh'
configure.ac:11: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
parallel-tests: installing 'build-aux/test-driver'

and I am not able to produce a configure script.

GSI-enabled OpenSSH 7.6p1

To Whom It May Concern,

I am Eisaku Sakane, a researcher of National Institute of Informatics (NII), Japan.
I submit an issue according to an advice that I took from Dr. Jim Basney at 2019 Intetnet2 Global Summit in Washington DC.

NII supports the GSI middleware because HPCI project that is a distributed high-performance computing infrastructure in Japan uses the GSI for single sign-on to supercomputers and storages.

As a result of the GSI support, we have GSI-enabled OpenSSH 7.6p1. This includes:

  • included the HPN-SSH patch (openssh-7_6_P1-hpn-14.14.diff)
  • fixed a connection failure problem if multi-thread AES-CTR ciphers used
  • fixed an inappropriate path problem of gsiscp (it may be useful for developers)
  • fixed errors in test scripts caused by setting "null" as hostkey algorithm
  • modified multiplex.sh to skip the transfer test when a system-installed gsiscp does not found (it also may be useful for developers)

We would like to share our gsi-openssh-7.6p1 among the Grid Community.
What do you think of this?

Thank you in advance.

GRAM Job failed because the job manager failed to open stdout

I deployed a cluster with gct-6.2.

No matter on the slave node or the master node,
I met the error "GRAM Job failed because the job manager failed to open stdout (error code 73) Details:",
when executing the command " globus-job-run slave-node/jobmanager-fork-poll -np 1 /bin/hostnamee" .

image

Now I try parameter "-stdout /tmp/1.log",
likely "globus-job-run slave-node/jobmanager-fork-poll -np 1 -stdout /tmp/1.log /bin/hostnamee" ,
I get right result in /tmp/1.log ,
but the error above still appears in the terminal .

How to fix ti ?

how XIO works with tar?

I downloaded gct and tried to enable XIO with tar using the following settings:

  1. globus-gridftp-server -aa -fs-whitelist popen,file,ordering -popen-whitelist tar:/usr/bin/tar

  2. globus-url-copy -pipe /usr/bin/tar

But I got the following error:

error: globus_ftp_client: the server responded with an error
500 500-Command failed. : globus_xio: popened program exited with an error (exit code: 2):
500-/usr/bin/tar: You must specify one of the -Acdtrux' or --test-label' options
500-Try /usr/bin/tar --help' or /usr/bin/tar --usage' for more information.
500-
500 End.

Wondering how to set XIO for using tar?

Thanks

"gcc: error: @GLOBUS_CFLAGS@: No such file or directory" when "make" gct

Hello, I encountered an fatal error as below when I "make" GCT from the source code of latest release GCT 6.2.20190226 (maintenance release)

 make[4]: Entering directory /home/globus/gct-6.2.1550507116/gsi_openssh/source/openbsd-compat
 make[4]: Nothing to be done for all.
 make[4]: Leaving directory \/home/globus/gct-6.2.1550507116/gsi_openssh/source/openbsd-compat\'
 gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE  @GLOBUS_CFLAGS@ -I. -I.  -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/globus/globus/libexec/ssh-askpass\" -DGSISSHDIR="\"/home/globus/globus/etc/gsissh\"" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c ssh_api.c -o ssh_api.o
 gcc: error: @GLOBUS_CFLAGS@: No such file or directory
 make[3]: *** [ssh_api.o] Error 1
 make[3]: Leaving directory /home/globus/gct-6.2.1550507116/gsi_openssh/source'
 make[2]: *** [gsi-openssh-stamp] Error 1
 make[2]: Leaving directory /home/globus/gct-6.2.1550507116'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory /home/globus/gct-6.2.1550507116'
 make: *** [all] Error 2

Please pay attention to line 5:

gcc: error: @GLOBUS_CFLAGS@: No such file or directory

Below is my "./configure" command:

./configure --prefix=/home/globus/globus --enable-myproxy --enable-gram5-server --pdfdir=/home/globus/ --with-openssl 2>&1 | tee log.txt

I run all commands in user "globus" but I got the error above. I tried the same on another server but the error occurred still.

I also searched "GLOBUS_CFLAGS" in this GitHub Repo but got no word totally same.

Attached with my server environment:

\ machine 1 VM 1
OS RedHat 5.3 CentOS 7.6
Arch x86_64 x86_64
Compiler gcc gcc
Openssl Version 1.1.1b 1.1.1b

Could you please help me work out?

Replace toolkit.globus.org refs w/ refs to our own doc fork

References to the original Globus documentation should be replaced to point to our documentation. From Mattias Ellert:

There are lots of
references to the toolkit.globus.org website and the Globus Alliance
that need to be changed in the specfiles. For example, each package has
a README file providing links to the globus documentation. I know the
sources for the documentation were forked, but do we have a new
location?

== This is the README in the globus-common package ==
$ cat /usr/share/doc/globus-common/README
This package is part of the C Common Libraries component
of the Globus Toolkit. For more information visit:

http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/

Developer's Guide:
http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/developer/

Release Notes:
http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/rn/

Public Interface Guide:
http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/pi/

Quality Profile:
http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/qp/

Migrating Guide:
http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/mig/
== End of file ==

gsissh and hpn

Hey there,

First, I wanted to let you know that I put out a new patch set for OpenSSH 8.7p1 at github/rapier1/openssh-portable.

Second, I'm working on some debian packaging. The default deb packages include the gssapi extension which, as far as I can tell, are these patches with the hpnssh code stripped out. Since I'm trying to recreate their setup do you have a version of gsissh without the hpn patch applied? If so can you point it out to me?

Thanks!

Chris

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.